On Fri, 26 Mar 2021 14:49:56 +0100
Martin Maechler wrote:
> I concluded I liked the first [patch] because it would achieve
> what's considered "uniformly better" in the sense that it makes
> R graphics behave like "all other" desktop applications *and* it
> would do so for all possible window m
> Duncan Murdoch
> on Thu, 25 Mar 2021 10:41:46 -0400 writes:
> On 25/03/2021 9:18 a.m., Dirk Eddelbuettel wrote:
>>
>> On 24 March 2021 at 10:30, Martin Maechler wrote:
>> | For this reason I've committed to R (the trunk, i.e., R-devel,
>> | for R 4.1.0 in a mont
On 25/03/2021 9:18 a.m., Dirk Eddelbuettel wrote:
On 24 March 2021 at 10:30, Martin Maechler wrote:
| For this reason I've committed to R (the trunk, i.e., R-devel,
| for R 4.1.0 in a month or so) in svn rev 80110.
I just saw that via the (still extremely helpful) RSS feed of SVN changes and
t
On 24 March 2021 at 10:30, Martin Maechler wrote:
| For this reason I've committed to R (the trunk, i.e., R-devel,
| for R 4.1.0 in a month or so) in svn rev 80110.
I just saw that via the (still extremely helpful) RSS feed of SVN changes and
then pulled.
You may have missed that Ivan conclude
> Dirk Eddelbuettel
> on Tue, 23 Mar 2021 12:36:47 -0500 writes:
> It all works now, thanks mostly to some very detailed reading of the
specs by
> Ivan. In short, I made the following changes:
> - add the missing WM hint to the .desktop file we install
> - add the s
With that change to the .desktop file, both the existing rgl and the rgl
with a group_leader set behave the same: all x11() and rgl windows are
collected together into the same R icon.
If I don't make that change, then setting the group_leader causes all
rgl windows from one process to group
It all works now, thanks mostly to some very detailed reading of the specs by
Ivan. In short, I made the following changes:
- add the missing WM hint to the .desktop file we install
- add the svg logo as 'scalable'
- create a new (square) 48x48 default png logo from the new one
- deactiv
Duncan Murdoch writes:
> On 28/03/2014, 7:01 AM, Rainer M Krug wrote:
>> Hi
>>
>> I would like to use namespaces outside packages, but I could not find
>> any references on how to do it (only a thread [1] which says "use a
>> package"). Using a package is not possible in my case, as I am passing
Duncan Murdoch writes:
> On 07/10/2013 10:29 AM, Rainer M Krug wrote:
>> Hi
>>
>> First, sorry if I get the terminology wrong, I am still quite new to the
>> concept of using environments and workspaces.
>>
>> Say I have a statement in a package SIM like
>>
>> sim <- TYPE
>>
>> where the variable
Thanks John and Dirk for your input.
I solved the problem by importing the package "simecol" which defines
the superclass simEcol in the NAMESPACE file with import(simEcol) and to
leave it in the DESCRIPTION file in the Depends section (as the
functions have to be available for the end user).
I r
Thank you very much Peter. That did the trick.
Frank
Peter Dalgaard-2 wrote
> On Apr 24, 2013, at 15:59 , Frank Harrell wrote:
>
>> I found that package quantreg has created a new generic for latex() [I
>> wish
>> it hadn't; this has been a generic in Hmisc for almost 2 decades]. When
>> I
>> r
On Apr 24, 2013, at 15:59 , Frank Harrell wrote:
> I found that package quantreg has created a new generic for latex() [I wish
> it hadn't; this has been a generic in Hmisc for almost 2 decades]. When I
> require(quantreg) after loading rms, latex(anova.rms object) dispatches
> latex.default, bu
I found that package quantreg has created a new generic for latex() [I wish
it hadn't; this has been a generic in Hmisc for almost 2 decades]. When I
require(quantreg) after loading rms, latex(anova.rms object) dispatches
latex.default, but everything is fine if I don't load quantreg. rms has
imp
Dear list,
Prof Ripley has replied with the solution - I /was/ doing something
patently stupid.
The offending line:
mf[[names(dots)]] <- NULL
should have been
mf[names(dots)] <- NULL
That the offending line worked in R 2.9.x was the result of bug, which
has been fixed in the current version,
Todays (03/20/2009) update of FreeBSD 8.0-CURRENT solved the problem.
The two pathes are resolving again. So building and installing R on
CURRENT works again :-)
Thanks for your patience,
Rainer
On 17.03.2009 16:11 (UTC+1), Rainer Hurling wrote:
On a recent FreeBSD 8.0-CURRENT (i386) building
On Fri, 7 Nov 2008, Corrado wrote:
Dear friends,
problem solved after talking to the unixODBC maintainer.
The problem is that the odbc driver (not unixODBC). The standard Mandriva
installation uses the old default postgresql driver, which was embedded in
the unixODBC, and not the newer odbc dr
Dear friends,
problem solved after talking to the unixODBC maintainer.
The problem is that the odbc driver (not unixODBC). The standard Mandriva
installation uses the old default postgresql driver, which was embedded in
the unixODBC, and not the newer odbc driver.
As long as you update the dri
By removing the data directory (which package.skeleton has created, and where
it has put all my variables in files with .rda extension) and adding one
more file to the R directory, containing the variable assignments.
Vladimir Eremeev wrote:
>
> I do use this function.
> Here is the example ses
While installing software on a new computer, I thought I would try to use
Cygwin to build an R package. (Note: NOT Ripley/Murdoch's Rtools).
I uncovered and solved two issues, one of which appears to be identical to a
problem previously reported (and unsolved) on this list. I offer this
informat
19 matches
Mail list logo
