[Rd] Can configure.ac detect 64 bit R?
My fame package has to link to the libchli.so that comes with FAME. However, FAME is now supplying both 32 and 64 bit versions of the library. The 32-bit version is $FAME/hli/libchli.so while the 64-bit version is $FAME/hli/64/libchli.so. To set the right flags, it seems that I need to know, from within configure.ac, whether the R installation is 32 bit or 64 bit. Is there a way to detect this? Jeff __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Can configure.ac detect 64 bit R?
On Tue, 5 Jun 2007, [EMAIL PROTECTED] wrote:
> My fame package has to link to the libchli.so that comes with FAME.
> However, FAME is now supplying both 32 and 64 bit versions of the
> library. The 32-bit version is $FAME/hli/libchli.so while the 64-bit
> version is $FAME/hli/64/libchli.so. To set the right flags, it seems
> that I need to know, from within configure.ac, whether the R
> installation is 32 bit or 64 bit. Is there a way to detect this?
That sort of differentiation is highly OS-specific. If FAME is indeed
doing this on all OSes it will cause considerable confusion. It is more
normal to have the 'standard' version in .../lib and the others in
.../lib/32 or .../lib/sparcv9, or to use lib and lib64 or
And I will assume from now on that you mean a Unix-alike.
Next, on any decent OS you don't need to know, as it will choose the
appropriate DSO from those it can find of that name. So just having
-L$FAME/hli/64 -L$FAME/hli should suffice.
However, if despite all that you want to know, yes of course configure.ac
can detect it. Several possibilities include:
- Ensure that you can compiling in exactly the same way as R way built,
and test a C program outputting sizeof(void *) == 8.
- ${R_HOME}/bin/Rscript -e 'cat(.Machine$sizeof.pointer)'
gives the pointer size in bytes.
- file ${R_HOME}/bin/exec/${r_arch}R will have '64-bit' in on a 64-bit
build on all OSes I know of.
Of these the second is most direct (and the slowest and needs R >= 2.5.0).
--
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] Quick notes on R with F7
Hi all, Just a quick heads up that I made the plunge into F7 this week. R version 2.5.0 Patched (2007-06-05 r41831) compiles and passes make check-all. F7 is using: [EMAIL PROTECTED] ~]$ gcc --version gcc (GCC) 4.1.2 20070502 (Red Hat 4.1.2-12) Some quick F7 notes: 1. Do a clean install rather than an 'in place' upgrade from FC6 or a prior version. There are a lot of changes, not the least of which is the consolidation of Extras and Core into a single release. 2. There will be some '.fc6' suffixed RPMS installed if there were no changes from the FC6 versions. I have 91 of them, out of a total of 1545 installed RPMS. Note that the F7 version RPM suffix is 'fc7', not 'f7' ... 3. There are some issues with SELinux and policies, so I have reverted to running in 'Permissive' mode for the time being. 4. Do not use 'rhgb' (the Red Hat Graphical Boot) on the kernel boot parameters in grub.conf. Especially if (like me) there are boot time prompts (such as dmcrypt-LUKS passphrases) that need to be input during boot. This interaction requires going from graphical to text mode and back, presumably switching virtual terminals. This may be unique to nVidia based video hardware, but there seems to be some issues with VT switching, which also seems to cause problems for the 'Fast User Switching' features new to F7. The symptoms include partially drawn windows, incomplete logins and X freezes. 5. Emacs 22 has been released and is part of F7. From a quick look, it would appear that the 'xft/anti-aliasing' font support available from the CVS branch of 22 is not part of the formal stable release tree. Thus I will continue to use the version 23 Unicode branch from CVS, along with the latest ECB (cvs snap) and CEDET (1.0pre4 was just released today) tool versions. 6. The rumors/intentions of TeXLive being part of F7 were premature and teTeX is still in place. This is apparently due to the decision on the part of the Fedora leadership folks that TeXLive is not yet ready for prime time. Other than that, things seem to be well, but I suspect that there will be many updates coming in the first 30 days or so...the Fedora lists have been quite busy... HTH, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Quick notes on R with F7
Marc, Thanks for the report. We had noted the release date for F7 as one of the milestones to take account of in scheduling 2.5.1, and thought we might just know an early adopter. Unfortunately the other milestone (the release of gcc 4.2.0 for MinGW has not happened on the promised date, June 1, AFAICS). [Before anyone asks, 2.5.1 is not yet scheduled.] Brian On Wed, 6 Jun 2007, Marc Schwartz wrote: > Hi all, > > Just a quick heads up that I made the plunge into F7 this week. > > R version 2.5.0 Patched (2007-06-05 r41831) compiles and passes make > check-all. F7 is using: > > [EMAIL PROTECTED] ~]$ gcc --version > gcc (GCC) 4.1.2 20070502 (Red Hat 4.1.2-12) > > > Some quick F7 notes: > > 1. Do a clean install rather than an 'in place' upgrade from FC6 or a > prior version. There are a lot of changes, not the least of which is the > consolidation of Extras and Core into a single release. > > 2. There will be some '.fc6' suffixed RPMS installed if there were no > changes from the FC6 versions. I have 91 of them, out of a total of 1545 > installed RPMS. Note that the F7 version RPM suffix is 'fc7', not > 'f7' ... > > 3. There are some issues with SELinux and policies, so I have reverted > to running in 'Permissive' mode for the time being. > > 4. Do not use 'rhgb' (the Red Hat Graphical Boot) on the kernel boot > parameters in grub.conf. Especially if (like me) there are boot time > prompts (such as dmcrypt-LUKS passphrases) that need to be input during > boot. This interaction requires going from graphical to text mode and > back, presumably switching virtual terminals. This may be unique to > nVidia based video hardware, but there seems to be some issues with VT > switching, which also seems to cause problems for the 'Fast User > Switching' features new to F7. The symptoms include partially drawn > windows, incomplete logins and X freezes. > > 5. Emacs 22 has been released and is part of F7. From a quick look, it > would appear that the 'xft/anti-aliasing' font support available from > the CVS branch of 22 is not part of the formal stable release tree. Thus > I will continue to use the version 23 Unicode branch from CVS, along > with the latest ECB (cvs snap) and CEDET (1.0pre4 was just released > today) tool versions. > > 6. The rumors/intentions of TeXLive being part of F7 were premature and > teTeX is still in place. This is apparently due to the decision on the > part of the Fedora leadership folks that TeXLive is not yet ready for > prime time. > > > Other than that, things seem to be well, but I suspect that there will > be many updates coming in the first 30 days or so...the Fedora lists > have been quite busy... > > HTH, > > Marc Schwartz > > __ > 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
[Rd] C function with unknown output length
Hi all, Could anyone point me to one or more examples in the R sources of a C function that is called without knowing in advance what will be the length (say) of the output vector? To make myself clearer, we have a C function that computes probabilities until their sum gets "close enough" to 1. Hence, the number of probabilities is not known in advance. I would like to have an idea what is the best way to handle this situation in R. Thanks in advance! --- Vincent Goulet, Associate Professor École d'actuariat Université Laval, Québec [EMAIL PROTECTED] http://vgoulet.act.ulaval.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C function with unknown output length
Salut Vincent,
On 6 June 2007 at 13:17, Vincent Goulet wrote:
| Could anyone point me to one or more examples in the R sources of a C
| function that is called without knowing in advance what will be the
| length (say) of the output vector?
|
| To make myself clearer, we have a C function that computes
| probabilities until their sum gets "close enough" to 1. Hence, the
| number of probabilities is not known in advance.
|
| I would like to have an idea what is the best way to handle this
| situation in R.
I haven't been on the 'Dirk tells everybody to use RcppTemplate' soapbox
lately, so let me (drumroll) suggest to use RcppTemplate.
So if you were to consider C++, which can be done incrementally relative to
C, then you could collect your data in a self-growing, autonagically
managemed STL Vector, pass it to RcppTemplate, and you're done. I have a
local .deb package for r-cran-rcpptemplate I can send you (and which I should
upload to Debian), or you can just use it from source on CRAN. You want the
source for the examples anyway.
If C++ is not an option, then I typically just hunt for decent examples that
do similar stuff. BDR's RODBC is usually a good source -- he also does not
know ex ante how long the return sets are. It's not _that_ hard, just
tedious. You examine the length of your vector, assign a new one for results
of that length, and copy elements.
As an example, see the following from my rdieharder package (that is pending
an upload to CRAN) where C as opposed to C++ was a given constraint. I wrote
this in a hurry and I may well have missed something to make it a tad better
-- but as indicated above, I'd rather be doing it in C++ anyway.
In the code, element [1] is a vector of possibly varying size:
/* vector of size three: [0] is scalar ks_pv, [1] is pvalues vec, [2] name */
PROTECT(result = allocVector(VECSXP, 3));
/* alloc scalar, and set it */
PROTECT(pv = allocVector(REALSXP, 1));
REAL(pv)[0] = testptr->ks_pvalue;
/* vector and set it */
PROTECT(vec = allocVector(REALSXP, testptr->psamples));
for (i = 0; i < testptr->psamples; i++) {
REAL(vec)[i] = testptr->pvalues[i];
}
PROTECT(name = allocVector(STRSXP, 1));
SET_STRING_ELT(name, 0, mkChar(dtestptr->name));
/* insert scalar and vector */
SET_VECTOR_ELT(result, 0, pv);
SET_VECTOR_ELT(result, 1, vec);
SET_VECTOR_ELT(result, 2, name);
UNPROTECT(4);
return result;
and testptr->psamples has the unknonw 'N' of vector length.
And yes, we need better cookbook examples for all this.
Hth, Dirk
--
Hell, there are no rules here - we're trying to accomplish something.
-- Thomas A. Edison
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Quick notes on R with F7
On Wed, 2007-06-06 at 17:58 +0100, Prof Brian Ripley wrote: > Marc, > > Thanks for the report. We had noted the release date for F7 as one of the > milestones to take account of in scheduling 2.5.1, and thought we might > just know an early adopter. Unfortunately the other milestone (the > release of gcc 4.2.0 for MinGW has not happened on the promised date, June > 1, AFAICS). > > [Before anyone asks, 2.5.1 is not yet scheduled.] > > Brian In case it is of any additional use, over and above Marc's post, I installed F7 on my laptop at the weekend, and built R2.5.0-patched (version as of sometime on Saturday afternoon - sorry my laptop is at home and I'm still at work). Passed make check-all for me as well. All seems to be well with R and F7 thus far. G > > On Wed, 6 Jun 2007, Marc Schwartz wrote: > > > Hi all, > > > > Just a quick heads up that I made the plunge into F7 this week. > > > > R version 2.5.0 Patched (2007-06-05 r41831) compiles and passes make > > check-all. F7 is using: > > > > [EMAIL PROTECTED] ~]$ gcc --version > > gcc (GCC) 4.1.2 20070502 (Red Hat 4.1.2-12) > > > > > > Some quick F7 notes: > > > > 1. Do a clean install rather than an 'in place' upgrade from FC6 or a > > prior version. There are a lot of changes, not the least of which is the > > consolidation of Extras and Core into a single release. > > > > 2. There will be some '.fc6' suffixed RPMS installed if there were no > > changes from the FC6 versions. I have 91 of them, out of a total of 1545 > > installed RPMS. Note that the F7 version RPM suffix is 'fc7', not > > 'f7' ... > > > > 3. There are some issues with SELinux and policies, so I have reverted > > to running in 'Permissive' mode for the time being. > > > > 4. Do not use 'rhgb' (the Red Hat Graphical Boot) on the kernel boot > > parameters in grub.conf. Especially if (like me) there are boot time > > prompts (such as dmcrypt-LUKS passphrases) that need to be input during > > boot. This interaction requires going from graphical to text mode and > > back, presumably switching virtual terminals. This may be unique to > > nVidia based video hardware, but there seems to be some issues with VT > > switching, which also seems to cause problems for the 'Fast User > > Switching' features new to F7. The symptoms include partially drawn > > windows, incomplete logins and X freezes. > > > > 5. Emacs 22 has been released and is part of F7. From a quick look, it > > would appear that the 'xft/anti-aliasing' font support available from > > the CVS branch of 22 is not part of the formal stable release tree. Thus > > I will continue to use the version 23 Unicode branch from CVS, along > > with the latest ECB (cvs snap) and CEDET (1.0pre4 was just released > > today) tool versions. > > > > 6. The rumors/intentions of TeXLive being part of F7 were premature and > > teTeX is still in place. This is apparently due to the decision on the > > part of the Fedora leadership folks that TeXLive is not yet ready for > > prime time. > > > > > > Other than that, things seem to be well, but I suspect that there will > > be many updates coming in the first 30 days or so...the Fedora lists > > have been quite busy... > > > > HTH, > > > > Marc Schwartz > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > -- %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% 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] C function with unknown output length
Vincent Goulet wrote:
> Hi all,
>
> Could anyone point me to one or more examples in the R sources of a C
> function that is called without knowing in advance what will be the
> length (say) of the output vector?
>
> To make myself clearer, we have a C function that computes
> probabilities until their sum gets "close enough" to 1. Hence, the
> number of probabilities is not known in advance.
>
Hi Vincent,
Let's say you want to write a function get_matches(const char * pattern, const
char * x)
that will find all the occurrences of string 'pattern' in string 'x' and
"return"
their positions in the form of an array of integers.
Of course you don't know in advance how many occurrences you're going to find.
One possible strategy is to:
- Add an extra arg to 'get_matches' for storing the positions and make
'get_matches' return the number of matches (i.e. the length of *pos):
int get_matches(int **pos_ptr, const char * pattern, const char * x)
Note that pos_ptr is a pointer to an int pointer.
- In get_matches(): use a local array of ints and start with an arbitrary
initial size for it:
int get_matches(...)
{
int *tmp_pos, tmp_size, npos = 0;
tmp_size = some initial guess of the number of matches
tmp_pos = (int *) S_alloc((long) tmp_size, sizeof(int));
...
Then start searching for matches and every time you find one, store its
position in tmp_pos[npos] and increase npos.
When tmp_pos is full (npos == tmp_size), realloc with:
...
old_size = tmp_size;
tmp_size = 2 * old_size; /* there are many different strategies for
this */
tmp_pos = (int *) S_realloc((char *) tmp_pos, (long) tmp_size,
(long) old_tmp_size, sizeof(int));
...
Note that there is no need to check that the call to S_alloc() or
S_realloc()
were successful because these functions will raise an error and end the call
to .Call if they fail. In this case they will free the memory currently
allocated
(and so will do on any error or user interrupt).
When you are done, just return with:
...
*pos_ptr = tmp_pos;
return npos;
}
- Call get_matches with:
int *pos, npos;
npos = get_matches(&pos, pattern, x);
Note that memory allocation took place in 'get_matches' but now you need
to decide how and when the memory pointed by 'pos' will be freed.
In the R environment, this can be addressed by using exclusively transient
storage allocation
(http://cran.r-project.org/doc/manuals/R-exts.html#Transient)
as we did in get_matches() so the allocated memory will be automatically
reclaimed at the end of the call to .C or .Call.
Of course, the integers stored in pos have to be moved to a "safe" place
before .Call returns. Typically this will be done with something like:
SEXP Call_get_matches(...)
{
...
npos = get_matches(&pos, pattern, x);
PROTECT(pos_sxp = NEW_INTEGER(npos));
memcpy(INTEGER(pos_sxp), pos, npos * sizeof(int));
UNPROTECT(1);
return pos_sxp; /* end of call to .Call */
}
There are many variations around this. One of them is to "share" pos and npos
between
get_matches and its caller by making them global variables (in this case it is
recommended to use 'static' in their declarations but this requires that
get_matches
and its caller are in the same .c file).
Hope this helps.
H.
> I would like to have an idea what is the best way to handle this
> situation in R.
>
> Thanks in advance!
>
> ---
>Vincent Goulet, Associate Professor
>École d'actuariat
>Université Laval, Québec
>[EMAIL PROTECTED] http://vgoulet.act.ulaval.ca
>
> __
> 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] Quick notes on R with F7
FWIW, I did an in-place upgrade via Yum (http://fedoraproject.org/wiki/YumUpgradeFaq) and it is viable - in fact I did the upgrade+reboot remotely; R and mingw-cross both seem to survive the upgrade. $ rpm -qa |wc -l 2050 $ rpm -qa |grep 'fc6' |wc -l 149 $ rpm -qa |grep 'fc7' |wc -l 1295 Before upgrade I had 1984 rpm's. One strangeness I noticed about emacs is that it stays at the splash screen and doesn't display the specified file to be edited until control-L. HTL Prof Brian Ripley wrote: > Marc, > > Thanks for the report. We had noted the release date for F7 as one of the > milestones to take account of in scheduling 2.5.1, and thought we might > just know an early adopter. Unfortunately the other milestone (the > release of gcc 4.2.0 for MinGW has not happened on the promised date, June > 1, AFAICS). > > [Before anyone asks, 2.5.1 is not yet scheduled.] > > Brian > > On Wed, 6 Jun 2007, Marc Schwartz wrote: > >> Hi all, >> >> Just a quick heads up that I made the plunge into F7 this week. >> >> R version 2.5.0 Patched (2007-06-05 r41831) compiles and passes make >> check-all. F7 is using: >> >> [EMAIL PROTECTED] ~]$ gcc --version >> gcc (GCC) 4.1.2 20070502 (Red Hat 4.1.2-12) >> >> >> Some quick F7 notes: >> >> 1. Do a clean install rather than an 'in place' upgrade from FC6 or a >> prior version. There are a lot of changes, not the least of which is the >> consolidation of Extras and Core into a single release. >> >> 2. There will be some '.fc6' suffixed RPMS installed if there were no >> changes from the FC6 versions. I have 91 of them, out of a total of 1545 >> installed RPMS. Note that the F7 version RPM suffix is 'fc7', not >> 'f7' ... >> >> 3. There are some issues with SELinux and policies, so I have reverted >> to running in 'Permissive' mode for the time being. >> >> 4. Do not use 'rhgb' (the Red Hat Graphical Boot) on the kernel boot >> parameters in grub.conf. Especially if (like me) there are boot time >> prompts (such as dmcrypt-LUKS passphrases) that need to be input during >> boot. This interaction requires going from graphical to text mode and >> back, presumably switching virtual terminals. This may be unique to >> nVidia based video hardware, but there seems to be some issues with VT >> switching, which also seems to cause problems for the 'Fast User >> Switching' features new to F7. The symptoms include partially drawn >> windows, incomplete logins and X freezes. >> >> 5. Emacs 22 has been released and is part of F7. From a quick look, it >> would appear that the 'xft/anti-aliasing' font support available from >> the CVS branch of 22 is not part of the formal stable release tree. Thus >> I will continue to use the version 23 Unicode branch from CVS, along >> with the latest ECB (cvs snap) and CEDET (1.0pre4 was just released >> today) tool versions. >> >> 6. The rumors/intentions of TeXLive being part of F7 were premature and >> teTeX is still in place. This is apparently due to the decision on the >> part of the Fedora leadership folks that TeXLive is not yet ready for >> prime time. >> >> >> Other than that, things seem to be well, but I suspect that there will >> be many updates coming in the first 30 days or so...the Fedora lists >> have been quite busy... >> >> HTH, >> >> 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] C function with unknown output length
On Wed, 6 Jun 2007, Vincent Goulet wrote:
> Could anyone point me to one or more examples in the R sources of a C
> function that is called without knowing in advance what will be the
> length (say) of the output vector?
>
> To make myself clearer, we have a C function that computes
> probabilities until their sum gets "close enough" to 1. Hence, the
> number of probabilities is not known in advance.
>
> I would like to have an idea what is the best way to handle this
> situation in R.
I think you will want to use the .Call(), not .C(),
interface. Then you can expand the output vector
as you see fit. E.g., the following sets the output
vector length to 0 and adds 1 to it each time it
needs to. This works in both R and Splus 8.0.
In Splus SET_LENGTH(vec, len) reserves some extra
space (above the 'len' requested items) so that
future calls to expand it a bit don't always copy
it. In R, each call to SET_LENGTH appears to copy
the input vector, so you probably want to add extra
logic to reserve some extra space and finally trim
it down to the precise size you want.
#include
#include
/* .Call("unknownReturnLength", 0.02) : return
* sequence of random uniforms, quitting when
* you see the first one below 0.02.
*/
SEXP unknownReturnLength(SEXP prob_p)
{
int retval_length ; /* long preferred in S-PLUS */
double prob, r ;
SEXP retval ;
retval_length = 0 ;
/* how does PROTECT interact with SET_LENGTH? */
PROTECT(retval = NEW_NUMERIC(retval_length)) ;
prob = asReal(prob_p);
GetRNGstate();
while((r=unif_rand()) >= prob) {
double *oldptr = NUMERIC_POINTER(retval) ;
retval_length++ ;
SET_LENGTH(retval, retval_length) ;
if (oldptr != NUMERIC_POINTER(retval))
Rprintf("expanding retval from %d to %d moved it\n", retval_length-1,
retval_length) ;
NUMERIC_POINTER(retval)[retval_length-1] = r ;
}
PutRNGstate();
return retval ;
}
Bill Dunlap
Insightful Corporation
bill at insightful dot com
360-428-8146
"All statements in this message represent the opinions of the author and do
not necessarily reflect Insightful Corporation policy or position."
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Quick notes on R with F7
I did that from 5 to 6, using the DVD ISO file (mounted as a loopback device) as a local yum repo. It worked quickly, since it was HD to HD. It was hairy however and as noted in the FAQ, left things to be cleaned up after the upgrade. I was less comfortable doing it again from 6 to 7. Figured that I was tempting fate... BTW, on the use of grep below, you don't need to pipe the output to 'wc'. You can use: [EMAIL PROTECTED] ~]$ rpm -qa | grep . -c 1546 [EMAIL PROTECTED] ~]$ rpm -qa | grep fc6 -c 91 [EMAIL PROTECTED] ~]$ rpm -qa | grep fc7 -c 1115 Also on emacs: 1. If you click on the splash screen with a mouse, it will also clear. It seems to also eventually clear on it's own after a bit (~30 seconds), at least in 23. 2. You can append '--no-splash' to the emacs command line to disable it. See 'emacs --help'. ...And in case anyone is wondering (because somebody asked), yes my system name is a reference to my all-time favorite 1956 SciFi movie, "Forbidden Planet"... :-) Regards, Marc On Wed, 2007-06-06 at 21:09 +0100, Hin-Tak Leung wrote: > FWIW, I did an in-place upgrade via Yum > (http://fedoraproject.org/wiki/YumUpgradeFaq) and it is viable - > in fact I did the upgrade+reboot remotely; R and mingw-cross both > seem to survive the upgrade. > $ rpm -qa |wc -l > 2050 > $ rpm -qa |grep 'fc6' |wc -l > 149 > $ rpm -qa |grep 'fc7' |wc -l > 1295 > > Before upgrade I had 1984 rpm's. > > One strangeness I noticed about emacs is that it stays at the splash > screen and doesn't display the specified file to be edited until control-L. > > HTL > > Prof Brian Ripley wrote: > > Marc, > > > > Thanks for the report. We had noted the release date for F7 as one of the > > milestones to take account of in scheduling 2.5.1, and thought we might > > just know an early adopter. Unfortunately the other milestone (the > > release of gcc 4.2.0 for MinGW has not happened on the promised date, June > > 1, AFAICS). > > > > [Before anyone asks, 2.5.1 is not yet scheduled.] > > > > Brian > > > > On Wed, 6 Jun 2007, Marc Schwartz wrote: > > > >> Hi all, > >> > >> Just a quick heads up that I made the plunge into F7 this week. > >> > >> R version 2.5.0 Patched (2007-06-05 r41831) compiles and passes make > >> check-all. F7 is using: > >> > >> [EMAIL PROTECTED] ~]$ gcc --version > >> gcc (GCC) 4.1.2 20070502 (Red Hat 4.1.2-12) > >> > >> > >> Some quick F7 notes: > >> > >> 1. Do a clean install rather than an 'in place' upgrade from FC6 or a > >> prior version. There are a lot of changes, not the least of which is the > >> consolidation of Extras and Core into a single release. > >> > >> 2. There will be some '.fc6' suffixed RPMS installed if there were no > >> changes from the FC6 versions. I have 91 of them, out of a total of 1545 > >> installed RPMS. Note that the F7 version RPM suffix is 'fc7', not > >> 'f7' ... > >> > >> 3. There are some issues with SELinux and policies, so I have reverted > >> to running in 'Permissive' mode for the time being. > >> > >> 4. Do not use 'rhgb' (the Red Hat Graphical Boot) on the kernel boot > >> parameters in grub.conf. Especially if (like me) there are boot time > >> prompts (such as dmcrypt-LUKS passphrases) that need to be input during > >> boot. This interaction requires going from graphical to text mode and > >> back, presumably switching virtual terminals. This may be unique to > >> nVidia based video hardware, but there seems to be some issues with VT > >> switching, which also seems to cause problems for the 'Fast User > >> Switching' features new to F7. The symptoms include partially drawn > >> windows, incomplete logins and X freezes. > >> > >> 5. Emacs 22 has been released and is part of F7. From a quick look, it > >> would appear that the 'xft/anti-aliasing' font support available from > >> the CVS branch of 22 is not part of the formal stable release tree. Thus > >> I will continue to use the version 23 Unicode branch from CVS, along > >> with the latest ECB (cvs snap) and CEDET (1.0pre4 was just released > >> today) tool versions. > >> > >> 6. The rumors/intentions of TeXLive being part of F7 were premature and > >> teTeX is still in place. This is apparently due to the decision on the > >> part of the Fedora leadership folks that TeXLive is not yet ready for > >> prime time. > >> > >> > >> Other than that, things seem to be well, but I suspect that there will > >> be many updates coming in the first 30 days or so...the Fedora lists > >> have been quite busy... > >> > >> HTH, > >> > >> 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
