Re: [Rd] One possible cause for incorrect symbols in X11() output

[Jari Oksanen]

On 19/08/10 09:55 AM, "Prof Brian Ripley"  wrote:

> There have been spasmodic reports of symbols such as pi and infinity
> in plotmath being reproduced incorrectly on the X11 device on some
> Linux systems (at least Ubuntu 10 and Fedora 12/13), and we've managed
> to track down one cause whilst investigating PR#14355.
> 
> Some systems have Wine and hence the Wine symbol font installed.
> 'fontconfig', which is used by cairographics in X11(type='cairo') and
> many other applications, prefers the Wine symbol font to the standard
> Type 1 URW font, and seems to misinterpret its encoding.
> 
> You may well have Wine installed without realizing it (as I did) -- it
> is increasingly common as a dependency of other software. The best
> test is to run
> 
> % fc-match symbol
> s05l.pfb: "Standard Symbols L" "Regular"
> 
> This is the result on a system without Wine: if you see
> 
> % fc-match symbol
> symbol.ttf: "Symbol" "Regular"
> 
This seems to be the case with MacOS (10.6.4):

$ uname -a
Darwin lettu-2.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23
18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386
$ fc-match symbol
Symbol.ttf: "Symbol" "標準體"

The X11(type = 'cairo') shows the problem with example(points);
TestChars(font=5). However, there is no problem with the default device
(quartz), nor with the default X11() which has type = 'Xlib' (unlike
documented in ?X11: 'cairo' is available but 'Xlib' still used).

What ever this is worth of (if this is worthless, I'll surely hear about
it).

Cheers, Jari Oksanen

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

Re: [Rd] One possible cause for incorrect symbols in X11() output

[peter dalgaard]

On Aug 19, 2010, at 9:15 AM, Jari Oksanen wrote:


> 
> The X11(type = 'cairo') shows the problem with example(points);
> TestChars(font=5). However, there is no problem with the default device
> (quartz), nor with the default X11() which has type = 'Xlib' (unlike
> documented in ?X11: 'cairo' is available but 'Xlib' still used).
> 
> What ever this is worth of (if this is worthless, I'll surely hear about
> it).

Well, maybe not worthless, but the X11 setup on Mac is poor in general. 
type="Xlib" appears plainly not to work, and even disregarding the pi issue, 
the rotated y-axis labels come out pretty ugly. This is why quartz is now the 
default on OSX. 

BTW, it seems that the standard X11 "Symbol","Regular" font is simply absent on 
OSX. I can't get fc-match to list it, anyway.

-- 
Peter Dalgaard
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [Rd] Automatically retrieve correct collation

[Janko Thyson]

> -Ursprüngliche Nachricht-
> Von: baptiste auguie [mailto:baptiste.aug...@googlemail.com]
> Gesendet: Donnerstag, 19. August 2010 07:41
> An: Janko Thyson
> Cc: r-de...@r-project. org
> Betreff: Re: [Rd] Automatically retrieve correct collation
> 
> Hi,
> 
> roxygen can create the collate field for you, if you specify the
> dependencies in the commented code. I've never tested it with S4
> classes though.
> 
> HTH,
> 
> baptiste

Thanks Baptiste,

I will have a look at Roxygen.

Janko

> 
> On 18 August 2010 22:28, Janko Thyson 
> wrote:
> > Dear List,
> >
> > consider the following scenario:
> >
> > setClass(Class = "A", representation = representation(B = "B", C =
> "C"))
> > setClass(Class = "B", representation = representation(C = "C"))
> > setClass(Class = "C", representation = representation(something =
> > "character"))
> >
> > Obviously, the collation for sourcing these defs needs to be: C, B,
> A. Which
> > doesn't correspond to the default collation of R (alphabetically).
> >
> > I've tried to pick up on how to ensure the right collation when
> building R
> > Packages by reading some previous posts and as far as I understand
> I've
> > basically got two options here:
> > 1) Put all class defs in one script, e.g. allClasses.R.
> > 2) Manually specify the collation via the "Collate" field in the
> DESCRIPTION
> > file.
> >
> > I'm used to organizing my classes, generics, methods etc. on a
> > "one-per-script" basis in various subdirectories (e.g. R/classes,
> R/methods
> > etc.) and try automate manual steps wherever possible (not sure if
> that's
> > the way most of you guys code, but it definitely helped me stay on
> top of
> > things). But this doesn't really go well with my two options above,
> does it?
> > ;-)
> >
> > So I thought about setting up a routine that
> > - investigates the source code of all classes (via parsing and
> looking into
> > the "representation" argument)
> > - finds out the valid collation by itself based on all classes that
> it found
> > in the representation argument of the respective class defs
> > - and then writes all the class defs to one R script, e.g.
>  allClasses.R, so
> > I can bundle all my code in an R Package without worrying about the
> > collation.
> >
> > This way I could stick to my old habits while automating the process
> of
> > building a package a bit ;-)
> >
> > Now, I managed to get this done for "simple" class defs like the ones
> above
> > but haven't looked into more complex class defs (e.g. including
> "contains"
> > etc.) yet.
> >
> > Has anyone tried and succeeded in doing something similar or are all
> of you
> > into the "one-script-contains-all" paradigm? If anyone is interested,
> I'd be
> > glad to share code. Likewise I'd be interested in hearing about other
> "best
> > practices" in this respect.
> >
> > Best regards,
> > Janko
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> 
> 
> 
> --
> 
> 
> Dr. Baptiste Auguié
> 
> Departamento de Química Física,
> Universidade de Vigo,
> Campus Universitario, 36310, Vigo, Spain
> 
> tel: +34 9868 18617
> http://webs.uvigo.es/coloides
> 

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

[Rd] C or Java code generation

[Vyacheslav Karamov]

Hi All!

I'm new to R and I need to know is it possible for R to generate C/C++ 
source code, Java byte code or native Win32 DLL like MatLab?


---
WBR,
Vyacheslav.

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

Re: [Rd] C or Java code generation

[Vyacheslav Karamov]

Daniel Cegiełka пишет:

http://www.rforge.net/r2c/

regards,
daniel


2010/8/19 Vyacheslav Karamov >


Hi All!

I'm new to R and I need to know is it possible for R to generate
C/C++ source code, Java byte code or native Win32 DLL like MatLab?

---
WBR,
Vyacheslav.

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


"Currently it is very experimantal and limited, intended for experiments 
with the language rather than real use"


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

Re: [Rd] C or Java code generation

[Daniel Cegiełka]

2010/8/19 Vyacheslav Karamov 

> Daniel Cegiełka пишет:
>
>> http://www.rforge.net/r2c/
>>
>> regards,
>> daniel
>>
>>
>> 2010/8/19 Vyacheslav Karamov > ubuntul...@yandex.ru>>
>>
>>
>>Hi All!
>>
>>I'm new to R and I need to know is it possible for R to generate
>>C/C++ source code, Java byte code or native Win32 DLL like MatLab?
>>
>>---
>>WBR,
>>Vyacheslav.
>>
>>__
>>R-devel@r-project.org  mailing list
>>
>>https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>>  "Currently it is very experimantal and limited, intended for experiments
> with the language rather than real use"


приветствуй ;)

exactly .. but Simon usually
has high quality of code.
regards,
daniel



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

[[alternative HTML version deleted]]

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

Re: [Rd] C or Java code generation

[Vyacheslav Karamov]

Daniel Cegiełka пишет:



2010/8/19 Vyacheslav Karamov >


Daniel Cegiełka пишет:

http://www.rforge.net/r2c/

regards,
daniel


2010/8/19 Vyacheslav Karamov mailto:ubuntul...@yandex.ru> >>


   Hi All!

   I'm new to R and I need to know is it possible for R to
generate
   C/C++ source code, Java byte code or native Win32 DLL like
MatLab?

   ---
   WBR,
   Vyacheslav.

   __
   R-devel@r-project.org 
>
mailing list

   https://stat.ethz.ch/mailman/listinfo/r-devel


"Currently it is very experimantal and limited, intended for
experiments with the language rather than real use"


приветствуй ;)

exactly .. but Simon 
usually has high quality of code.

regards,
daniel

Is there any posibility to use R without installing?
I mean that I have my own application written in MS Visual C++ and I 
need to use R script in this app. I can install R and use it via DCOM, 
but it's not convenient for  the end users of my  program.


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

Re: [Rd] C or Java code generation

[Daniel Cegiełka]

Is there any posibility to use R without installing?

> I mean that I have my own application written in MS Visual C++ and I need
> to use R script in this app. I can install R and use it via DCOM, but it's
> not convenient for  the end users of my  program.
>
>
Dirk Eddelbuettel love R/C++ combination. Rinside could be usefull for you.

http://dirk.eddelbuettel.com/code.html

regards

[[alternative HTML version deleted]]

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

Re: [Rd] One possible cause for incorrect symbols in X11() output

[Prof Brian Ripley]

On Thu, 19 Aug 2010, peter dalgaard wrote:



On Aug 19, 2010, at 9:15 AM, Jari Oksanen wrote:




The X11(type = 'cairo') shows the problem with example(points);
TestChars(font=5). However, there is no problem with the default device
(quartz), nor with the default X11() which has type = 'Xlib' (unlike
documented in ?X11: 'cairo' is available but 'Xlib' still used).

What ever this is worth of (if this is worthless, I'll surely hear about
it).


Well, maybe not worthless, but the X11 setup on Mac is poor in 
general. type="Xlib" appears plainly not to work, and even 
disregarding the pi issue, the rotated y-axis labels come out pretty 
ugly. This is why quartz is now the default on OSX.


The even more serious issue under cairo of confusing style and weight 
is discussed on ?X11.


BTW, it seems that the standard X11 "Symbol","Regular" font is 
simply absent on OSX. I can't get fc-match to list it, anyway.


R's X11(type='cairo') device is using a version of cairographics 
compiled by Simon which includes a static build of fontconfig.  So it 
is not really 'OSX'!  I'm guessing you are using 
/usr/local/bin/fc-match which AFAIK also Simon's.


It is also not using pango, and so not selecting fonts the same way as 
on Linux.




--
Peter Dalgaard
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk  Priv: pda...@gmail.com

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



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
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] One possible cause for incorrect symbols in X11() output

[Jari Oksanen]

On 19/08/10 14:04 PM, "Prof Brian Ripley"  wrote:
 OSX. I can't get fc-match to list it, anyway.
> 
> R's X11(type='cairo') device is using a version of cairographics
> compiled by Simon which includes a static build of fontconfig.  So it
> is not really 'OSX'!  I'm guessing you are using
> /usr/local/bin/fc-match which AFAIK also Simon's.
>
$ which fc-match
/usr/X11/bin/fc-match

There seems to be no fc-match in /usr/local/bin/ in my Mac, so no Simon's
utilities. (But this is, of course, pretty irrelevant for the main subject,
and it seems that my installation of Ubuntu 10.04 is not affected by the
problem but has quite regular fonts -- no Wine today. Better that I shut
up).

Cheers, Jari Oksanen
> It is also not using pango, and so not selecting fonts the same way as
> on Linux.
>

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

Re: [Rd] One possible cause for incorrect symbols in X11() output

[Gavin Simpson]

On Thu, 2010-08-19 at 07:55 +0100, Prof Brian Ripley wrote:
> There have been spasmodic reports of symbols such as pi and infinity 
> in plotmath being reproduced incorrectly on the X11 device on some 
> Linux systems (at least Ubuntu 10 and Fedora 12/13), and we've managed 
> to track down one cause whilst investigating PR#14355.
> 
> Some systems have Wine and hence the Wine symbol font installed. 
> 'fontconfig', which is used by cairographics in X11(type='cairo') and 
> many other applications, prefers the Wine symbol font to the standard 
> Type 1 URW font, and seems to misinterpret its encoding.
> 
> You may well have Wine installed without realizing it (as I did) -- it 
> is increasingly common as a dependency of other software. The best 
> test is to run
> 
> % fc-match symbol
> s05l.pfb: "Standard Symbols L" "Regular"
> 
> This is the result on a system without Wine: if you see
> 
> % fc-match symbol
> symbol.ttf: "Symbol" "Regular"
> 
> you at least potentially have the problem.  A good test is to look at 
> ?points and run the function TestChars() defined there as
> 
> TestChars(font=5)
> 
> If you do have the problem, a workaround is to add the following lines 
> to ~/.fonts.conf or /etc/fonts/local.conf (which you may need to 
> create):
> 
> 
>Symbol
>
>  Standard Symbols L
>
> 
> 
> and repeat the fc-match test to check that it worked.

Hi,

I tried the suggested change to ~/.fonts.conf but am getting an error
from fontconfig:

$ fc-match symbol
Fontconfig error: "~/.fonts.conf", line 10: junk after document element
s05l.pfb: "Standard Symbols L" "Regular"
$ cat ~/.fonts.conf


Symbol


Standard Symbols L




   ZapfDingbats
   Dingbats


I have an alias in there to solve the "q" symbol being used in Evince
etc in place of pch == 1.

Am I inserting this incorrectly?

Many thanks,

G

> 
> (This workaround was culled from
> https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/551977
> )
> 

-- 
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
 Dr. Gavin Simpson [t] +44 (0)20 7679 0522
 ECRC, UCL Geography,  [f] +44 (0)20 7679 0565
 Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
 Gower Street, London  [w] http://www.ucl.ac.uk/~ucfagls/
 UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%

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

Re: [Rd] One possible cause for incorrect symbols in X11() output

[Prof Brian Ripley]

If you have more than one element in a fonts.conf file you need to 
group them, e.g.




  Symbol
  
Standard Symbols L
  



   ZapfDingbats
   Dingbats




On Thu, 19 Aug 2010, Gavin Simpson wrote:


On Thu, 2010-08-19 at 07:55 +0100, Prof Brian Ripley wrote:

There have been spasmodic reports of symbols such as pi and infinity
in plotmath being reproduced incorrectly on the X11 device on some
Linux systems (at least Ubuntu 10 and Fedora 12/13), and we've managed
to track down one cause whilst investigating PR#14355.

Some systems have Wine and hence the Wine symbol font installed.
'fontconfig', which is used by cairographics in X11(type='cairo') and
many other applications, prefers the Wine symbol font to the standard
Type 1 URW font, and seems to misinterpret its encoding.

You may well have Wine installed without realizing it (as I did) -- it
is increasingly common as a dependency of other software. The best
test is to run

% fc-match symbol
s05l.pfb: "Standard Symbols L" "Regular"

This is the result on a system without Wine: if you see

% fc-match symbol
symbol.ttf: "Symbol" "Regular"

you at least potentially have the problem.  A good test is to look at
?points and run the function TestChars() defined there as

TestChars(font=5)

If you do have the problem, a workaround is to add the following lines
to ~/.fonts.conf or /etc/fonts/local.conf (which you may need to
create):


   Symbol
   
 Standard Symbols L
   


and repeat the fc-match test to check that it worked.


Hi,

I tried the suggested change to ~/.fonts.conf but am getting an error
from fontconfig:

$ fc-match symbol
Fontconfig error: "~/.fonts.conf", line 10: junk after document element
s05l.pfb: "Standard Symbols L" "Regular"
$ cat ~/.fonts.conf

   
   Symbol
   
   
   Standard Symbols L
   



  ZapfDingbats
  Dingbats


I have an alias in there to solve the "q" symbol being used in Evince
etc in place of pch == 1.

Am I inserting this incorrectly?

Many thanks,

G



(This workaround was culled from
https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/551977
)



--
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Dr. Gavin Simpson [t] +44 (0)20 7679 0522
ECRC, UCL Geography,  [f] +44 (0)20 7679 0565
Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
Gower Street, London  [w] http://www.ucl.ac.uk/~ucfagls/
UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
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] One possible cause for incorrect symbols in X11() output

[Gavin Simpson]

On Thu, 2010-08-19 at 12:36 +0100, Prof Brian Ripley wrote:
> If you have more than one element in a fonts.conf file you need to 
> group them, e.g.

Many thanks, Prof. Ripley. That is working just fine now on my Fedora 12
workstation.

All the best,

G

> 
> 
> 
>Symbol
>
>  Standard Symbols L
>
> 
> 
> 
> ZapfDingbats
> Dingbats
> 
> 
> 
> 
> On Thu, 19 Aug 2010, Gavin Simpson wrote:
> 
> > On Thu, 2010-08-19 at 07:55 +0100, Prof Brian Ripley wrote:
> >> There have been spasmodic reports of symbols such as pi and infinity
> >> in plotmath being reproduced incorrectly on the X11 device on some
> >> Linux systems (at least Ubuntu 10 and Fedora 12/13), and we've managed
> >> to track down one cause whilst investigating PR#14355.
> >>
> >> Some systems have Wine and hence the Wine symbol font installed.
> >> 'fontconfig', which is used by cairographics in X11(type='cairo') and
> >> many other applications, prefers the Wine symbol font to the standard
> >> Type 1 URW font, and seems to misinterpret its encoding.
> >>
> >> You may well have Wine installed without realizing it (as I did) -- it
> >> is increasingly common as a dependency of other software. The best
> >> test is to run
> >>
> >> % fc-match symbol
> >> s05l.pfb: "Standard Symbols L" "Regular"
> >>
> >> This is the result on a system without Wine: if you see
> >>
> >> % fc-match symbol
> >> symbol.ttf: "Symbol" "Regular"
> >>
> >> you at least potentially have the problem.  A good test is to look at
> >> ?points and run the function TestChars() defined there as
> >>
> >> TestChars(font=5)
> >>
> >> If you do have the problem, a workaround is to add the following lines
> >> to ~/.fonts.conf or /etc/fonts/local.conf (which you may need to
> >> create):
> >>
> >> 
> >>Symbol
> >>
> >>  Standard Symbols L
> >>
> >> 
> >>
> >> and repeat the fc-match test to check that it worked.
> >
> > Hi,
> >
> > I tried the suggested change to ~/.fonts.conf but am getting an error
> > from fontconfig:
> >
> > $ fc-match symbol
> > Fontconfig error: "~/.fonts.conf", line 10: junk after document element
> > s05l.pfb: "Standard Symbols L" "Regular"
> > $ cat ~/.fonts.conf
> > 
> >
> >Symbol
> >
> >
> >Standard Symbols L
> >
> > 
> >
> > 
> >   ZapfDingbats
> >   Dingbats
> > 
> >
> > I have an alias in there to solve the "q" symbol being used in Evince
> > etc in place of pch == 1.
> >
> > Am I inserting this incorrectly?
> >
> > Many thanks,
> >
> > G
> >
> >>
> >> (This workaround was culled from
> >> https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/551977
> >> )
> >>
> >
> > -- 
> > %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
> > Dr. Gavin Simpson [t] +44 (0)20 7679 0522
> > ECRC, UCL Geography,  [f] +44 (0)20 7679 0565
> > Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
> > Gower Street, London  [w] http://www.ucl.ac.uk/~ucfagls/
> > UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
> > %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
> >
> 

-- 
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
 Dr. Gavin Simpson [t] +44 (0)20 7679 0522
 ECRC, UCL Geography,  [f] +44 (0)20 7679 0565
 Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
 Gower Street, London  [w] http://www.ucl.ac.uk/~ucfagls/
 UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%

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

Re: [Rd] One possible cause for incorrect symbols in X11() output

[peter dalgaard]

On Aug 19, 2010, at 1:04 PM, Prof Brian Ripley wrote:

> On Thu, 19 Aug 2010, peter dalgaard wrote:
> 
>> 
>> On Aug 19, 2010, at 9:15 AM, Jari Oksanen wrote:
>> 
>> 
>>> 
>>> The X11(type = 'cairo') shows the problem with example(points);
>>> TestChars(font=5). However, there is no problem with the default device
>>> (quartz), nor with the default X11() which has type = 'Xlib' (unlike
>>> documented in ?X11: 'cairo' is available but 'Xlib' still used).
>>> 
>>> What ever this is worth of (if this is worthless, I'll surely hear about
>>> it).
>> 
>> Well, maybe not worthless, but the X11 setup on Mac is poor in general. 
>> type="Xlib" appears plainly not to work, and even disregarding the pi issue, 
>> the rotated y-axis labels come out pretty ugly. This is why quartz is now 
>> the default on OSX.
> 
> The even more serious issue under cairo of confusing style and weight is 
> discussed on ?X11.
> 
>> BTW, it seems that the standard X11 "Symbol","Regular" font is simply absent 
>> on OSX. I can't get fc-match to list it, anyway.
> 
> R's X11(type='cairo') device is using a version of cairographics compiled by 
> Simon which includes a static build of fontconfig.  So it is not really 
> 'OSX'!  I'm guessing you are using /usr/local/bin/fc-match which AFAIK also 
> Simon's.

Actually, it was /opt/local/bin/fc-match (macPorts?). I have _three_ of them:

peter-dalgaards-iMac:~ pd$ ls -l /usr/X11/bin/fc-match 
-rwxr-xr-x  1 root  wheel  64416 Feb 11  2010 /usr/X11/bin/fc-match
peter-dalgaards-iMac:~ pd$ ls -l /usr/local/bin/fc-match 
-rwxr-xr-x@ 1 root  wheel  1476560 Oct 21  2008 /usr/local/bin/fc-match
peter-dalgaards-iMac:~ pd$ ls -l /opt/local/bin/fc-match 
-rwxr-xr-x  2 root  admin  14792 Mar 16 16:52 /opt/local/bin/fc-match

Doesn't look like they are behaving any different, though.


> It is also not using pango, and so not selecting fonts the same way as on 
> Linux.

You're assuming (in fact, correctly) that I was using Simon's build, but my 
locally built version is similar. That doesn't appear to use pango either; I 
have a Portfile for pango-devel, but it must have failed to build.



-- 
Peter Dalgaard
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [Rd] One possible cause for incorrect symbols in X11() output

[peter dalgaard]

On Aug 19, 2010, at 1:55 PM, peter dalgaard wrote:

>> 
>> It is also not using pango, and so not selecting fonts the same way as on 
>> Linux.
> 
> You're assuming (in fact, correctly) that I was using Simon's build, but my 
> locally built version is similar. That doesn't appear to use pango either; I 
> have a Portfile for pango-devel, but it must have failed to build.
> 

Actually, it builds, but the resulting R crashes on "x11();plot(0)"

-- 
Peter Dalgaard
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [Rd] C or Java code generation

[Dirk Eddelbuettel]

On 19 August 2010 at 13:02, Daniel Cegiełka wrote:
| Is there any posibility to use R without installing?
| 
| > I mean that I have my own application written in MS Visual C++ and I need
| > to use R script in this app. I can install R and use it via DCOM, but it's
| > not convenient for  the end users of my  program.
| >
| >
| Dirk Eddelbuettel love R/C++ combination. Rinside could be usefull for you.
| 
| http://dirk.eddelbuettel.com/code.html

Thanks for the plug. We can definitely embed R inside C++ on operating
systems containing an x somewhere in their name. But note that the RInside
page (http://dirk.eddelbuettel.com/code/rinside.html) clearly states the
following:

   Status   
   

 
   Version 0.2.3 should build and install on just about any Linux and OS X
   system, and even on Windows machines that have the Rtools compiled by
   Duncan Murdoch as detailed in the The Windows Toolset appendix to the R
   Installation manual. Do not report an error if you fail to build this with
   another compiler as this is not supported. (However, the examples which
   built and run under 0.2.1 currently build but segfault. This is probably
   fixable but we just haven't had the time or focus to do it. Linux and OS X
   work well enough for us.)

so for someone hell-bent on using MS Visual Whatever this is not a solution.

Dirk

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com

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

Re: [Rd] c.POSIXct

[Paul Gilbert]

I used to get caught by this c() behaviour often, but now I do expect it to 
drop attributes. I think it would break many things if you change it, and force 
people to write different code when they really do want to drop attributes. 
When you want new behaviour it is usually better to define a new function, ca() 
maybe?

Paul

>-Original Message-
>From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
>project.org] On Behalf Of Gabor Grothendieck
>Sent: August 18, 2010 6:23 PM
>To: r-devel@r-project.org
>Subject: Re: [Rd] c.POSIXct
>
>No one answered this so I submitted it to the bugs system and there I
>got the response that it is documented behavior; however, whether its
>documented or not is hardly the point -- its undesirable that tzone is
>lost when using c.
>
>On Thu, Aug 12, 2010 at 11:33 AM, Gabor Grothendieck
> wrote:
>> Currently if x1 and x2 are POSIXct then c(x1, x2) will not have a
>> tzone attribute even if x1 or x2 or both do but it should.
>>
>> This could be fixed with the following c.POSIXct:
>>
>> c.POSIXct <- function (..., recursive = FALSE) {
>>        tzones <- lapply(list(...), attr, which = "tzone")
>>        lengths <- sapply(tzones, length)
>>        if (any(lengths > 1)) stop("tzone cannot have length greater
>than 1")
>>        which <- sapply(tzones, length) == 1
>>        tzone <- unique(unlist(tzones[which]))
>>        if (length(tzone) != 1) tzone <- NULL
>> structure(c(unlist(lapply(list(...), unclass))), class = c("POSIXt",
>>    "POSIXct"), tzone = tzone)
>> }
>>
>> # test
>> x1 <- Sys.time()
>> x2 <- structure(x1, tzone = "UTC")
>> x3 <- structure(x1, tzone = "other")
>>
>> # these all currently give NULL but with
>> # above give indicated value
>>
>> attr(c(x1, x1), "tzone") # NULL
>> attr(c(x2, x2), "tzone") # "UTC"
>> attr(c(x1, x2), "tzone") # "UTC"
>> attr(c(x2, x1), "tzone") # "UTC"
>> attr(c(x1, x2, x3), "tzone") # NULL
>>
>
>__
>R-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-devel


La version française suit le texte anglais.



This email may contain privileged and/or confidential in...{{dropped:26}}

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

Re: [Rd] c.POSIXct

[Gabor Grothendieck]

On Thu, Aug 19, 2010 at 10:16 AM, Paul Gilbert
 wrote:
> I used to get caught by this c() behaviour often, but now I do expect it to 
> drop attributes. I think it would break many things if you change it, and 
> force people to write different code when they really do want to drop 
> attributes. When you want new behaviour it is usually better to define a new 
> function, ca() maybe?
>

That would work if ca defaulted to c for those classes that did not
supply a ca method.

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

Re: [Rd] c.POSIXct

[Spencer Graves]

 Hi, Gabor, Paul, et al.:


  For classes that did not supply a "ca" method, I'd rather see the 
default being to start with the corresponding  "c" method followed by an 
effort to preserve attributes to the maximum extent feasible.  I'm not 
sure the best defaults, but at the moment, I would expect that 
attributes like "dim" and "dimnames" should always be dropped.  The 
current default "c" method preserves "names" appropriately.



  What do you think about including another argument to 
"checkAttributes"?  I'm not sure what the options should be nor what 
should be the default, but one option should throw and error if any 
contradiction was found while another would take all attributes from the 
first argument and ignore others.



  Best Wishes,
  Spencer Graves


On 8/19/2010 7:32 AM, Gabor Grothendieck wrote:

On Thu, Aug 19, 2010 at 10:16 AM, Paul Gilbert
  wrote:

I used to get caught by this c() behaviour often, but now I do expect it to 
drop attributes. I think it would break many things if you change it, and force 
people to write different code when they really do want to drop attributes. 
When you want new behaviour it is usually better to define a new function, ca() 
maybe?


That would work if ca defaulted to c for those classes that did not
supply a ca method.

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




--
Spencer Graves, PE, PhD
President and Chief Operating Officer
Structure Inspection and Monitoring, Inc.
751 Emerson Ct.
San José, CA 95126
ph:  408-655-4567

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

Re: [Rd] c.POSIXct

[Gabor Grothendieck]

On Thu, Aug 19, 2010 at 11:43 AM, Spencer Graves
 wrote:
>  Hi, Gabor, Paul, et al.:
>
>
>      For classes that did not supply a "ca" method, I'd rather see the
> default being to start with the corresponding  "c" method followed by an
> effort to preserve attributes to the maximum extent feasible.  I'm not sure
> the best defaults, but at the moment, I would expect that attributes like
> "dim" and "dimnames" should always be dropped.  The current default "c"
> method preserves "names" appropriately.
>
>
>      What do you think about including another argument to
> "checkAttributes"?  I'm not sure what the options should be nor what should
> be the default, but one option should throw and error if any contradiction
> was found while another would take all attributes from the first argument
> and ignore others.
>
>

I think ca is easier to use.  It would work consistently and simply
across classes whereas fixing up c with checkAttribues is harder to
use.

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

Re: [Rd] C or Java code generation

[Dirk Eddelbuettel]

On 19 August 2010 at 17:06, Vyacheslav Karamov wrote:
| Dirk Eddelbuettel пишет:
| > On 19 August 2010 at 13:02, Daniel Cegiełka wrote:
| > | Is there any posibility to use R without installing?
| > | 
| > | > I mean that I have my own application written in MS Visual C++ and I 
need
| > | > to use R script in this app. I can install R and use it via DCOM, but 
it's
| > | > not convenient for  the end users of my  program.
| > | >
| > | >
| > | Dirk Eddelbuettel love R/C++ combination. Rinside could be usefull for 
you.
| > | 
| > | http://dirk.eddelbuettel.com/code.html
| >
| > Thanks for the plug. We can definitely embed R inside C++ on operating
| > systems containing an x somewhere in their name. But note that the RInside
| > page (http://dirk.eddelbuettel.com/code/rinside.html) clearly states the
| > following:
| >
| >Status   
   
| > 
 
| >Version 0.2.3 should build and install on just about any Linux and OS X
| >system, and even on Windows machines that have the Rtools compiled by
| >Duncan Murdoch as detailed in the The Windows Toolset appendix to the R
| >Installation manual. Do not report an error if you fail to build this 
with
| >another compiler as this is not supported. (However, the examples which
| >built and run under 0.2.1 currently build but segfault. This is probably
| >fixable but we just haven't had the time or focus to do it. Linux and OS 
X
| >work well enough for us.)
| >
| > so for someone hell-bent on using MS Visual Whatever this is not a solution.
| >
| > Dirk
| >
| >   
| I tried to compile it using MinGW:

No, what you describe in the next few hundred lines would _build the examples
if the package is already installed_ 

Also, building these examples (once you have the package is installed) does
"Work For Me (TM)" in the sense that the compiles and linking steps succeed
(WinXP, Rtools with gcc/g++ 4.2.x, R 2.11.0) yet it, as noted above, leads to
a seg.fault which Romain and I have found neither time nor motivation to fix.

You would be very welcome to help out -- our discussions around Rcpp and
RInside take place on the rcpp-devel list off R-Forge.


| 1) First I added R_HOME environment variable.
| 2) Then modified c:\Program 
| Files\R\R-2.11.1\library\RInside\examples\standard\Makefile.win by 
| surrounding "$(R_HOME)/bin/R" with the quotation marks.
| 3) And finally
| C:\Program Files\R\R-2.11.1\library\RInside\examples\standard>make -f 
| Makefile.win
| g++ -Ic:/PROGRA~1/R/R-211~1.1/include 
| -Ic:/PROGRA~1/R/R-211~1.1/library/Rcpp/include 
| -I"c:/PROGRA~1/R/R-211~1.1/library/RInside/include" -O2 -Wall -Wall  -s  
| rinside_callbacks0.cpp  -Lc:/PROGRA~1/R/R-211~1.1/bin -lR 
| -Lc:/PROGRA~1/R/R-211~1.1/bin -lRblas -Lc:/PROGRA~1/R/R-211~1.1/bin 
| -lRlapack "c:/PROGRA~1/R/R-211~1.1/library/RInside/lib/libRInside.a" 
| c:/PROGRA~1/R/R-211~1.1/library/Rcpp/lib/libRcpp.a  -o rinside_callbacks0
| 
c:/PROGRA~1/R/R-211~1.1/library/RInside/lib/libRInside.a(RInside.o):RInside.cpp:(.text+0x10b):
 
| undefined reference to `__gxx_personality_sj0'

[ Hundreds of similar lines removed. ]


Thanks, Dirk

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com

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

Re: [Rd] c.POSIXct

[Spencer Graves]

 Hi, Gabor, et al.:


  I'm suggesting adding "checkAttributes" to "ca", NOT to "c".


  Spencer


On 8/19/2010 8:50 AM, Gabor Grothendieck wrote:

On Thu, Aug 19, 2010 at 11:43 AM, Spencer Graves
  wrote:

  Hi, Gabor, Paul, et al.:


  For classes that did not supply a "ca" method, I'd rather see the
default being to start with the corresponding  "c" method followed by an
effort to preserve attributes to the maximum extent feasible.  I'm not sure
the best defaults, but at the moment, I would expect that attributes like
"dim" and "dimnames" should always be dropped.  The current default "c"
method preserves "names" appropriately.


  What do you think about including another argument to
"checkAttributes"?  I'm not sure what the options should be nor what should
be the default, but one option should throw and error if any contradiction
was found while another would take all attributes from the first argument
and ignore others.



I think ca is easier to use.  It would work consistently and simply
across classes whereas fixing up c with checkAttribues is harder to
use.




--
Spencer Graves, PE, PhD
President and Chief Operating Officer
Structure Inspection and Monitoring, Inc.
751 Emerson Ct.
San José, CA 95126
ph:  408-655-4567

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

Re: [Rd] c.POSIXct

[Gabor Grothendieck]

On Thu, Aug 19, 2010 at 12:15 PM, Spencer Graves
 wrote:
>  Hi, Gabor, et al.:
>
>
>      I'm suggesting adding "checkAttributes" to "ca", NOT to "c".
>

Yes, that would be a good idea.

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

Re: [Rd] perl.exe has stopped working: Fixed.

[Spencer Graves]

   To complete this thread for anyone encountering a similar 
problem, the fix I said I'd try (below) worked.  Specifically, I 
installed the latest Strawberry Perl, modified the path so the first 
reference points to the new Perl, and R CMD build, check, INSTALL, and 
"INSTALL -build" all seemed to work properly.  Of course, there is 
always a chance of some deeply hidden problem, but the obvious first 
tests seemed to function exactly as I have come to expect.



  Best Wishes,
  Spencer Graves


On 8/18/2010 6:00 PM, Spencer Graves wrote:

 Hello:


  I just installed 14 security updates for Vista x64, and now "R 
CMD build packagename" terminates, saying, "perl.exe has stopped 
working".  I reinstalled Rtools211 using the latest version after 
uninstalling the version I installed on 4/3/2010.



  What do you suggest?  I can install the latest version of perl 
from "www.perl.org" (5.12.1), but I thought I'd ask here first.



  Thanks,
  Best Wishes,
  Spencer Graves

__
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

[Rd] Can you share a working example of R program aided by fast BLAS?

[Paul Johnson]

Can one of you give me an R program that displays the benefits an
accelerated BLAS in R?

Here's why I ask, in case you wonder:

In a linux cluster, I've hit some bumps in the road.  The worst one by
far was that I installed R, then GotoBLAS2 with default settings, and
after that, jobs using Rmpi were *really* *really* slow.  I mean
horrible.  If a job took 15 minutes when run by itself, outside of
MPI, it took 1 full day when run inside MPI. Literally the same job.

I learned later that GotoBLAS2 defaults to allow threads equal to the
number of cores, and that the threads are not compatible with MPI.
This latter point not clearly stated in the GotoBLAS2 documents, so
far as I can find, but after I realized that was the problem, I did
find one other cluster website that mentioned the same problem. "If
your application uses GotoBLAS and all cores as MPI threads, setting
GOTO_NUM_THREADS larger than one will usually result in drastically
slower performance."
(http://hpc.uark.edu/hpc/support/software/numerical.html#gotoblas).
In the GotoBLAS2 documentation, it warns of weird thread related
delays, but it implies that the slowdown--if it happens--is a result
of bad user code, rather than this more fundamental mismatch between
OpenMPI (or MPI in general) and GotoBLAS2.

In the process of diagnosing the big slowdown, I've been making many
time comparisons. When I installed GotoBLAS2 in the first place, it
was because so many people (and the R admin manual) said that R's
ordinary BLAS is rudimentary/slow.  In the test cases I've tried,  R's
BLAS is not that bad. In fact, in the test programs we run, the time
is not substantially different with GotoBLAS2 and R's BLAS.  I also
compared the Intel Kernel Math Library BLAS and didn't notice a huge
difference.

So, well, I think that means I'm running bad test cases for R and GotoBLAS2.

Oh, and one more thing. I have not been able to find an example R
program that benefitted at all from allowing threads > 1 in GotoBLAS2
environment settings.  In fact, if a one-thread job takes15 minutes,
the one that allows 2 or more threads is 21 minutes.  And the more
threads allowed causes a job to take longer. This is literally the
same job, same cluster node, the only difference is changing the
environment variable that adjusts the GotoBLAS2 threads allowed.

So if you know whether your example depends on threads or not, I would
appreciate the warning.

pj

-- 
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas

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

[Rd] Does anyone use Sweave (RweaveLatex) option "expand=FALSE"?

[Duncan Murdoch]

I am trying to improve the error reporting in Sweave documents, so that 
if you have a syntax error in a code chunk, it will tell you which line 
of your input file contained the error.


For example, currently you get this:

Error:  chunk 1 (label=named)
Error in parse(text = chunk) : unexpected symbol in "x <- foo bar"
Execution halted

and I'd like errors to be more like this:

Error:  chunk 1 (label=named)
Error in parse(text = chunk, srcfile = srcfile) :
 test.Rnw:9:10: unexpected symbol
9: x <- foo bar
   ^
Execution halted

It turns out that this requires changes that make the "expand=FALSE" 
option quite hard to implement.  Is anyone using it?  For those who 
don't know it, "expand=FALSE" means that a code chunk like


<>=
z <- 3
<>
@

will be displayed as

> z <- 3
> <>

rather than expanding the named chunk.  I'd like to drop the option, so 
that the default behaviour (which has always been equivalent to "expand 
= TRUE") would be the only behaviour.


Duncan Murdoch

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

Re: [Rd] Does anyone use Sweave (RweaveLatex) option "expand=FALSE"?

[Marc Schwartz]

On Aug 19, 2010, at 2:07 PM, Duncan Murdoch wrote:

> I am trying to improve the error reporting in Sweave documents, so that if 
> you have a syntax error in a code chunk, it will tell you which line of your 
> input file contained the error.
> 
> For example, currently you get this:
> 
> Error:  chunk 1 (label=named)
> Error in parse(text = chunk) : unexpected symbol in "x <- foo bar"
> Execution halted
> 
> and I'd like errors to be more like this:
> 
> Error:  chunk 1 (label=named)
> Error in parse(text = chunk, srcfile = srcfile) :
> test.Rnw:9:10: unexpected symbol
> 9: x <- foo bar
>   ^
> Execution halted
> 
> It turns out that this requires changes that make the "expand=FALSE" option 
> quite hard to implement.  Is anyone using it?  For those who don't know it, 
> "expand=FALSE" means that a code chunk like
> 
> <>=
> z <- 3
> <>
> @
> 
> will be displayed as
> 
> > z <- 3
> > <>
> 
> rather than expanding the named chunk.  I'd like to drop the option, so that 
> the default behaviour (which has always been equivalent to "expand = TRUE") 
> would be the only behaviour.
> 
> Duncan Murdoch


I don't. So 1 "go ahead and drop it" vote...

You may want to post this to R-Help though Duncan, as I suspect there may be 
more Sweave users there than here...

Thanks and regards,

Marc Schwartz

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

Re: [Rd] Does anyone use Sweave (RweaveLatex) option "expand=FALSE"?

[Kasper Daniel Hansen]

I have read a significant number of vignettes from Bioconductor
packages and I have never seen it used.

Kasper

On Thu, Aug 19, 2010 at 3:17 PM, Marc Schwartz  wrote:
> On Aug 19, 2010, at 2:07 PM, Duncan Murdoch wrote:
>
>> I am trying to improve the error reporting in Sweave documents, so that if 
>> you have a syntax error in a code chunk, it will tell you which line of your 
>> input file contained the error.
>>
>> For example, currently you get this:
>>
>> Error:  chunk 1 (label=named)
>> Error in parse(text = chunk) : unexpected symbol in "x <- foo bar"
>> Execution halted
>>
>> and I'd like errors to be more like this:
>>
>> Error:  chunk 1 (label=named)
>> Error in parse(text = chunk, srcfile = srcfile) :
>> test.Rnw:9:10: unexpected symbol
>> 9: x <- foo bar
>>           ^
>> Execution halted
>>
>> It turns out that this requires changes that make the "expand=FALSE" option 
>> quite hard to implement.  Is anyone using it?  For those who don't know it, 
>> "expand=FALSE" means that a code chunk like
>>
>> <>=
>> z <- 3
>> <>
>> @
>>
>> will be displayed as
>>
>> > z <- 3
>> > <>
>>
>> rather than expanding the named chunk.  I'd like to drop the option, so that 
>> the default behaviour (which has always been equivalent to "expand = TRUE") 
>> would be the only behaviour.
>>
>> Duncan Murdoch
>
>
> I don't. So 1 "go ahead and drop it" vote...
>
> You may want to post this to R-Help though Duncan, as I suspect there may be 
> more Sweave users there than here...
>
> Thanks and regards,
>
> Marc Schwartz
>
> __
> 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

Re: [Rd] Does anyone use Sweave (RweaveLatex) option "expand=FALSE"?

[Duncan Murdoch]

On 19/08/2010 3:17 PM, Marc Schwartz wrote:

On Aug 19, 2010, at 2:07 PM, Duncan Murdoch wrote:

> I am trying to improve the error reporting in Sweave documents, so that if 
you have a syntax error in a code chunk, it will tell you which line of your input 
file contained the error.
> 
> For example, currently you get this:
> 
> Error:  chunk 1 (label=named)

> Error in parse(text = chunk) : unexpected symbol in "x <- foo bar"
> Execution halted
> 
> and I'd like errors to be more like this:
> 
> Error:  chunk 1 (label=named)

> Error in parse(text = chunk, srcfile = srcfile) :
> test.Rnw:9:10: unexpected symbol
> 9: x <- foo bar
>   ^
> Execution halted
> 
> It turns out that this requires changes that make the "expand=FALSE" option quite hard to implement.  Is anyone using it?  For those who don't know it, "expand=FALSE" means that a code chunk like
> 
> <>=

> z <- 3
> <>
> @
> 
> will be displayed as
> 
> > z <- 3

> > <>
> 
> rather than expanding the named chunk.  I'd like to drop the option, so that the default behaviour (which has always been equivalent to "expand = TRUE") would be the only behaviour.
> 
> Duncan Murdoch



I don't. So 1 "go ahead and drop it" vote...

You may want to post this to R-Help though Duncan, as I suspect there may be 
more Sweave users there than here...
  


I probably will before I go ahead with this, but I may as well start on 
this group.


Duncan

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

Re: [Rd] Does anyone use Sweave (RweaveLatex) option "expand=FALSE"?

[Claudia Beleites]

I never used it.

I got curious, though. What would be a situation that benefits of this option?

Maybe a use case could be found by "brute force" (grep all .Rnw files on CRAN 
for the option?


Claudia

--
Claudia Beleites
Dipartimento dei Materiali e delle Risorse Naturali
Università degli Studi di Trieste
Via Alfonso Valerio 6/a
I-34127 Trieste

phone: +39 0 40 5 58-37 68
email: cbelei...@units.it

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

Re: [Rd] Does anyone use Sweave (RweaveLatex) option "expand=FALSE"?

[Duncan Murdoch]

On 19/08/2010 4:29 PM, Claudia Beleites wrote:

I never used it.

I got curious, though. What would be a situation that benefits of this option?
  


When I put it in, I thought it would be for people who were writing 
about Sweave.


Duncan Murdoch

Maybe a use case could be found by "brute force" (grep all .Rnw files on CRAN 
for the option?


Claudia




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

Re: [Rd] Does anyone use Sweave (RweaveLatex) option "expand=FALSE"?

[Kevin Coombes]

I use it, frequently. The idea for it goes back to some of Knuth's 
original literate programming ideas for developing weave and tangle when 
he was writing TeX (the program).  I want to be able to document the 
pieces of some complex algorithm without having to see all of the gory 
details.  For instance, I have code that looks like the following.  
(Note that this is typed on the fly rather than copied from actual 
source, so there may be typos.)


<>=
for (i in 1:nSamples) {
<>
for (j in 1:nChromosomes) {
<>
<>
<>
<>
<>
}
}
@

Each of the <> is itself a fairly long piece of code defined and 
documented somewhere else.  (Some of them may themselves be written in 
the same form to reduce the final size of a chunk to something a human 
has a chance of understanding. That's the difference between weave and 
tangle in the original implementation.)   By blocking expansion, I can 
focus on the main steps without having them lost in pages and pages of code.


So I vote strongly for retaining "expand=FALSE".

Best,
   Kevin

Duncan Murdoch wrote:

On 19/08/2010 4:29 PM, Claudia Beleites wrote:

I never used it.

I got curious, though. What would be a situation that benefits of 
this option?
  


When I put it in, I thought it would be for people who were writing 
about Sweave.


Duncan Murdoch

Maybe a use case could be found by "brute force" (grep all .Rnw files 
on CRAN for the option?


Claudia




__
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

Re: [Rd] Does anyone use Sweave (RweaveLatex) option "expand=FALSE"?

[Duncan Murdoch]

On 19/08/2010 5:07 PM, Kevin Coombes wrote:
I use it, frequently. The idea for it goes back to some of Knuth's 
original literate programming ideas for developing weave and tangle when 
he was writing TeX (the program).  I want to be able to document the 
pieces of some complex algorithm without having to see all of the gory 
details.  For instance, I have code that looks like the following.  
(Note that this is typed on the fly rather than copied from actual 
source, so there may be typos.)


Okay, thanks.  I'll keep it in.  So now I have a question:  suppose
you have an error (syntax error at this point, maybe some other kinds of 
error in the future) in the <> chunk, but that 
chunk wasn't eval'd, mainloop was eval'd.  So the error is going to be 
reported as occurring in chunk mainloop, but with a line number from 
somewhere else in the file.  Is that a problem?


Duncan Murdoch




<>=
for (i in 1:nSamples) {
<>
 for (j in 1:nChromosomes) {
<>
<>
<>
<>
<>
 }
}
@

Each of the <> is itself a fairly long piece of code defined and 
documented somewhere else.  (Some of them may themselves be written in 
the same form to reduce the final size of a chunk to something a human 
has a chance of understanding. That's the difference between weave and 
tangle in the original implementation.)   By blocking expansion, I can 
focus on the main steps without having them lost in pages and pages of code.


So I vote strongly for retaining "expand=FALSE".

Best,
Kevin

Duncan Murdoch wrote:

On 19/08/2010 4:29 PM, Claudia Beleites wrote:

I never used it.

I got curious, though. What would be a situation that benefits of 
this option?
  
When I put it in, I thought it would be for people who were writing 
about Sweave.


Duncan Murdoch

Maybe a use case could be found by "brute force" (grep all .Rnw files 
on CRAN for the option?


Claudia



__
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

Re: [Rd] Does anyone use Sweave (RweaveLatex) option "expand=FALSE"?

[Matt Shotwell]

On Thu, 2010-08-19 at 17:07 -0400, Kevin Coombes wrote:
> I use it, frequently. The idea for it goes back to some of Knuth's 
> original literate programming ideas for developing weave and tangle when 
> he was writing TeX (the program).  I want to be able to document the 
> pieces of some complex algorithm without having to see all of the gory 
> details.  For instance, I have code that looks like the following.  
> (Note that this is typed on the fly rather than copied from actual 
> source, so there may be typos.)
> 
> <>=
> for (i in 1:nSamples) {
> <>
>  for (j in 1:nChromosomes) {
> <>
> <>
> <>
> <>
> <>
>  }
> }
> @
> 
> Each of the <> is itself a fairly long piece of code defined and 
> documented somewhere else.  (Some of them may themselves be written in 
> the same form to reduce the final size of a chunk to something a human 
> has a chance of understanding. That's the difference between weave and 
> tangle in the original implementation.)   By blocking expansion, I can 
> focus on the main steps without having them lost in pages and pages of code.
> 

Couldn't you achieve the same amount of abstraction using function
calls, rather than embedded code chunks? The reader can then see real
code, rather than non-code, or meta-code, or whatever. Alternatively,
represent the code chunks as R expressions, then evaluate the
expressions at the appropriate points.

-Matt

> So I vote strongly for retaining "expand=FALSE".
> 
> Best,
> Kevin
> 
> Duncan Murdoch wrote:
> > On 19/08/2010 4:29 PM, Claudia Beleites wrote:
> >> I never used it.
> >>
> >> I got curious, though. What would be a situation that benefits of 
> >> this option?
> >>   
> >
> > When I put it in, I thought it would be for people who were writing 
> > about Sweave.
> >
> > Duncan Murdoch
> >
> >> Maybe a use case could be found by "brute force" (grep all .Rnw files 
> >> on CRAN for the option?
> >>
> >> Claudia
> >>
> >>
> >
> > __
> > 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

-- 
Matthew S. Shotwell
Graduate Student 
Division of Biostatistics and Epidemiology
Medical University of South Carolina

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

Re: [Rd] Does anyone use Sweave (RweaveLatex) option "expand=FALSE"?

[Kevin Coombes]

I can certainly live with the line number matching some other part of 
the code.


Duncan Murdoch wrote:

On 19/08/2010 5:07 PM, Kevin Coombes wrote:
I use it, frequently. The idea for it goes back to some of Knuth's 
original literate programming ideas for developing weave and tangle 
when he was writing TeX (the program).  I want to be able to document 
the pieces of some complex algorithm without having to see all of the 
gory details.  For instance, I have code that looks like the 
following.  (Note that this is typed on the fly rather than copied 
from actual source, so there may be typos.)


Okay, thanks.  I'll keep it in.  So now I have a question:  suppose
you have an error (syntax error at this point, maybe some other kinds 
of error in the future) in the <> chunk, but 
that chunk wasn't eval'd, mainloop was eval'd.  So the error is going 
to be reported as occurring in chunk mainloop, but with a line number 
from somewhere else in the file.  Is that a problem?


Duncan Murdoch




<>=
for (i in 1:nSamples) {
<>
 for (j in 1:nChromosomes) {
<>
<>
<>
<>
<>
 }
}
@

Each of the <> is itself a fairly long piece of code defined 
and documented somewhere else.  (Some of them may themselves be 
written in the same form to reduce the final size of a chunk to 
something a human has a chance of understanding. That's the 
difference between weave and tangle in the original 
implementation.)   By blocking expansion, I can focus on the main 
steps without having them lost in pages and pages of code.


So I vote strongly for retaining "expand=FALSE".

Best,
Kevin

Duncan Murdoch wrote:

On 19/08/2010 4:29 PM, Claudia Beleites wrote:

I never used it.

I got curious, though. What would be a situation that benefits of 
this option?
  
When I put it in, I thought it would be for people who were writing 
about Sweave.


Duncan Murdoch

Maybe a use case could be found by "brute force" (grep all .Rnw 
files on CRAN for the option?


Claudia



__
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

Re: [Rd] c.POSIXct

[Vitaly S.]

Spencer Graves  writes:

>I'm with Gabor on this.  I naively would not expect c() to strip 
> attributes generally, and I've been
> surprise more than once to find the time zone attribute stripped when I did 
> not expect that.
>
>
>   Might it make sense to add an argument like "keepAttributes=FALSE" to 
> the "c" function?  Then people like
> Gabor and me would know that we would have to specify "keepAttributes = TRUE" 
> if we wanted attributes to be kept.

I often find myself using c() just to strip attributes when manipulating arrays
in simulation. c() is probably already quite complex function,
"keepAttributes=FALSE" would complicate it even more and impact the speed.

Given that, I wonder why there is no dedicated function to strip attributes.
Am I missing anything?

Vitaly.

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

Re: [Rd] Does anyone use Sweave (RweaveLatex) option "expand=FALSE"?

[Kevin Coombes]

I picked the example from segmenting chromosomes for a reason.  I have a 
fair chunk of code that deals with not quite exceeding the amount of RAM 
available in the machine sitting on my desktop.  If I use functions, 
then the pass-by-value semantics of R will push me beyond the limits at 
some points.  (This is an empirical statement, not a theoretical one.  I 
was bitten by it several times while trying to analyze a couple of these 
datasets. And, yes, I know I can get around this by buying a bigger and 
better machine; it's on order...)  The real point is that using 
functions can be detrimental to the efficiency of the program, in ways 
that have real world consequences.


I haven't thought about doing the same thing with expressions. 
Expressions don't have quite the same semantics as chunks, and you'd 
have to make sure the evaluation was delayed so that you cold use the 
current values of things that were computed in the meantime and I 
already know how to do this with chunks without having to think so hard.


Using expressons would, however, help with the one difficulty that I 
have with reusing <> (independent of whether or not I use 
'expand=FALSE').  I usually work inside emacs, using the 
emacs-speaks-statistics (ESS) package. ESS doesn't know how to evaluate 
the <> call inside another chunk. so if I want to step through 
the code during development, I have to jump around myself to locate the 
source chunks.  With expressions that wouldn't matter.


As I ramble on about this, it occurs to me that the underlying issue is 
that <> are not first class objects either in the LaTeX world or 
in the R world part of Sweave.  If there were a way to promote them to 
first class objects somehow, then it might make my use of ESS easier 
while simultaneously making it easier for Duncan to figure out how to 
report the correct line numbers.  But I only have an extremely vague 
idea of how one might start to do that...


   Kevin

Matt Shotwell wrote:

On Thu, 2010-08-19 at 17:07 -0400, Kevin Coombes wrote:
  
I use it, frequently. The idea for it goes back to some of Knuth's 
original literate programming ideas for developing weave and tangle when 
he was writing TeX (the program).  I want to be able to document the 
pieces of some complex algorithm without having to see all of the gory 
details.  For instance, I have code that looks like the following.  
(Note that this is typed on the fly rather than copied from actual 
source, so there may be typos.)


<>=
for (i in 1:nSamples) {
<>
 for (j in 1:nChromosomes) {
<>
<>
<>
<>
<>
 }
}
@

Each of the <> is itself a fairly long piece of code defined and 
documented somewhere else.  (Some of them may themselves be written in 
the same form to reduce the final size of a chunk to something a human 
has a chance of understanding. That's the difference between weave and 
tangle in the original implementation.)   By blocking expansion, I can 
focus on the main steps without having them lost in pages and pages of code.





Couldn't you achieve the same amount of abstraction using function
calls, rather than embedded code chunks? The reader can then see real
code, rather than non-code, or meta-code, or whatever. Alternatively,
represent the code chunks as R expressions, then evaluate the
expressions at the appropriate points.

-Matt

  

So I vote strongly for retaining "expand=FALSE".

Best,
Kevin

Duncan Murdoch wrote:


On 19/08/2010 4:29 PM, Claudia Beleites wrote:
  

I never used it.

I got curious, though. What would be a situation that benefits of 
this option?
  

When I put it in, I thought it would be for people who were writing 
about Sweave.


Duncan Murdoch

  
Maybe a use case could be found by "brute force" (grep all .Rnw files 
on CRAN for the option?


Claudia




__
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






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

Re: [Rd] Does anyone use Sweave (RweaveLatex) option "expand=FALSE"?

[Gabor Grothendieck]

On Thu, Aug 19, 2010 at 6:21 PM, Kevin Coombes
 wrote:
> I picked the example from segmenting chromosomes for a reason.  I have a
> fair chunk of code that deals with not quite exceeding the amount of RAM
> available in the machine sitting on my desktop.  If I use functions, then
> the pass-by-value semantics of R will push me beyond the limits at some
> points.  (This is an empirical statement, not a theoretical one.  I was
> bitten by it several times while trying to analyze a couple of these
> datasets. And, yes, I know I can get around this by buying a bigger and
> better machine; it's on order...)  The real point is that using functions
> can be detrimental to the efficiency of the program, in ways that have real
> world consequences.
>
> I haven't thought about doing the same thing with expressions. Expressions
> don't have quite the same semantics as chunks, and you'd have to make sure
> the evaluation was delayed so that you cold use the current values of things
> that were computed in the meantime and I already know how to do this
> with chunks without having to think so hard.
>
> Using expressons would, however, help with the one difficulty that I have
> with reusing <> (independent of whether or not I use
> 'expand=FALSE').  I usually work inside emacs, using the
> emacs-speaks-statistics (ESS) package. ESS doesn't know how to evaluate the
> <> call inside another chunk. so if I want to step through the code
> during development, I have to jump around myself to locate the source
> chunks.  With expressions that wouldn't matter.
>
> As I ramble on about this, it occurs to me that the underlying issue is that
> <> are not first class objects either in the LaTeX world or in the R
> world part of Sweave.  If there were a way to promote them to first class
> objects somehow, then it might make my use of ESS easier while
> simultaneously making it easier for Duncan to figure out how to report the
> correct line numbers.  But I only have an extremely vague idea of how one
> might start to do that...
>

You could try a macro instead and see how it performs.  There is an
article by Thomas Lumley in R News 2003-1 and an implementation in the
gtools package.

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

[Rd] No RTFM?

[Spencer Graves]

 What do you think about adding a "No RTFM" policy to the R mailing 
lists? Per, "http://en.wikipedia.org/wiki/RTFM":



The Ubuntu Forums and LinuxQuestions.org, for instance, have instituted 
"no RTFM" policies to promote a welcoming atmosphere.[8][9].


RTFM [and] "Go look on google" are two inappropriate responses to a 
question. If you don't know the answer or don't wish to help, please say 
nothing instead of brushing off someone's question. Politely showing 
someone how you searched or obtained the answer to a question is 
acceptable, even encouraged.

...

If you wish to remind a user to use search tools or other resources when 
they have asked a question you feel is basic or common, please be very 
polite. Any replies for help that contain language disrespectful towards 
the user asking the question, i.e. "STFU" or "RTFM" are unacceptable and 
will not be tolerated. —Ubuntu Forums



Gavin Simpson and I recently provided examples answering a question from 
"r.ookie" that had previously elicited responses, ""You want us to read 
the help page to you?" and "It yet again appears that you are asking us 
to read the help pages for you."



I can appreciate the sentiment in fortunes('rtfm'). In this case, 
however, "r.ookie" had RTFM (and said so), but evidently the manual was 
not sufficiently clear.



Best Wishes,
Spencer Graves

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

Re: [Rd] Does anyone use Sweave (RweaveLatex) option "expand=FALSE"?

[Charles C. Berry]

On Thu, 19 Aug 2010, Kevin Coombes wrote:

I picked the example from segmenting chromosomes for a reason.  I have a fair 
chunk of code that deals with not quite exceeding the amount of RAM available 
in the machine sitting on my desktop.  If I use functions, then the 
pass-by-value semantics of R will push me beyond the limits at some points. 
(This is an empirical statement, not a theoretical one.  I was bitten by it 
several times while trying to analyze a couple of these datasets. And, yes, I 
know I can get around this by buying a bigger and better machine; it's on 
order...)  The real point is that using functions can be detrimental to the 
efficiency of the program, in ways that have real world consequences.


I haven't thought about doing the same thing with expressions. Expressions 
don't have quite the same semantics as chunks, and you'd have to make sure 
the evaluation was delayed so that you cold use the current values of things 
that were computed in the meantime and I already know how to do this with 
chunks without having to think so hard.


Using expressons would, however, help with the one difficulty that I have 
with reusing <> (independent of whether or not I use 'expand=FALSE'). 
I usually work inside emacs, using the emacs-speaks-statistics (ESS) package. 
ESS doesn't know how to evaluate the <> call inside another chunk. so 
if I want to step through the code during development, I have to jump around 
myself to locate the source chunks.  With expressions that wouldn't matter.




emacs org-mode might help.

You can define a chunk, <> (say), then place it in a subsequent 
chunk, <> (say), inside an eval() and refer to <> inside an 
eval() inside another chunk, <>, and so on. The only trick is to 
write the chunk so that the chunk it refers to is on its own line, like 
this:


#+source: ch3
#+begin_src R :session :noweb yes
eval(
<>
)
z <- mean(y)+1
#+end_src

as the noweb expansion will repeat any other text on the line with the 
named chunk for each line of code in the referenced chunk.


You can define a library of chunks separately, which might help you if you 
reuse them in different places.


You can use ess-mode to edit the chunks and execute them with the usual 
ess-eval-* commands, or run them in org-mode with the results optionally 
returned to the edit buffer, but outside the code block.


If you want to debug a bunch of nested chunks and 'step through the code 
during development', you can tangle the chunk you wish to execute to 
produce a *.R file. The nested chunks are expanded into R. Open that *.R 
file and debug away.


With a recent emacs, I think this gets you going:

C-h i m Org Mode RET C-s source RET RET

or Google 'org-babel R' or some such or just go look here:


http://blogisticreflections.wordpress.com/

As I ramble on about this, it occurs to me that the underlying issue is that 
<> are not first class objects either in the LaTeX world or in the R 
world part of Sweave.  If there were a way to promote them to first class 
objects somehow, then it might make my use of ESS easier while simultaneously 
making it easier for Duncan to figure out how to report the correct line 
numbers.  But I only have an extremely vague idea of how one might start to 
do that...


org-mode might be the path of least resistance.

FWIW, the code chunks are objects processed by emacs-lisp before they are 
handed off to R, so there might be a slicker way to handle the nesting 
than dropping chunks inside eval()s in R blocks. If that interests you, 
there is a very active listserv for orgmode, where you might inqure.


HTH,

Chuck






  Kevin

Matt Shotwell wrote:

 On Thu, 2010-08-19 at 17:07 -0400, Kevin Coombes wrote:

>  I use it, frequently. The idea for it goes back to some of Knuth's 
>  original literate programming ideas for developing weave and tangle when 
>  he was writing TeX (the program).  I want to be able to document the 
>  pieces of some complex algorithm without having to see all of the gory 
>  details.  For instance, I have code that looks like the following. 
>  (Note that this is typed on the fly rather than copied from actual 
>  source, so there may be typos.)
> 
>  <>=

>  for (i in 1:nSamples) {
>  <>
>  for (j in 1:nChromosomes) {
>  <>
>  <>
>  <>
>  <>
>  <>
>   }
>  }
>  @
> 
>  Each of the <> is itself a fairly long piece of code defined and 
>  documented somewhere else.  (Some of them may themselves be written in 
>  the same form to reduce the final size of a chunk to something a human 
>  has a chance of understanding. That's the difference between weave and 
>  tangle in the original implementation.)   By blocking expansion, I can 
>  focus on the main steps without having them lost in pages and pages of 
>  code.
> 
> 


 Couldn't you achieve the same amount of abstraction using function
 calls, rather than embedded code chunks? The reader can then see real
 code, rather than non-code, or meta-code, or whatever. Alternative