similar to: levelplot

Hi, working with R, version 0.63.0, I was successful to dyn.load fortran90 subroutines on a Solaris 2.6, as long as they are more or less in conformity with f77. It was not possible to work with statements like REAL,DIMENSION(:) :: d or x=SUM(y). REAL,DIMENSION(1:10) :: d is possible. We compiled R with f77. Is it possible with real f90 routines or is is in any conflict with the shared

Dear helpers, thanks. Installation of R and packages (like integrate) successful done. The LD_LIBRARY_PATH wasn't set in the correct order: system libs ahead of the compiler lib. Cross checks provided by Brian Ripley, Oxford, helped a lot. Yours Bodo gordon.harrington at uni.edu wrote: > Without tracing the loader system calls and knowing where the functions are > located I can

Dear r-helpers, we have installation problems: Successful installation of R-0.63 base package on Solaris 2.5.1 with the SunSoft compilers f77, c version 4.2. We habe problems with the installation of further packages e.g. integrate from CRAN. R code works but the shared objects built from fortran code do not find the appropriate libs with functions like __pow_ii or __epx at runtime. We tried

Hi, in syslinux-386, I think I've found a problem in com32/lib/syslinux/load_linux.c that leads to cmdline being truncated unnecessarily when e.g. linux.c32 is used. The patch below fixes the problem for me. But I don't know, whether the patch is safe in all cases. I tried to reproduce the logic found in runkernel.inc, but I might have missed something. So, feel free to tell me

Hi, I am using mechanize for a while now. Works great. But at the moment I have a small problem using it. The problematic file is attached. In that PHP-File you will see a formular, but mechanize doesn''t recognize it. Could somebody check this? Thanks, Bodo -- http://www.tvbrowser.org http://www.wannawork.de -------------- next part -------------- An HTML attachment was scrubbed...

Hi! The postscript device in 0.90 does not produce symbols (pch=) as it should. E.g.: postscript(file="test.ps",width=8,height=6.4,horizontal=FALSE) plot(1:10,1:10,pch=1:5) legend(1,9,letters[1:5],pch=1:5) dev.off() The result looks quite different compared to the X-windows version. The symbol 1 (pch=1) is much to small, while the other symbols seem to big. Is it a bug? How can I

----- Original Message ----- From: "Bodo Thiesen" <bothie@gmx.de> To: <ext3-users@redhat.com> Sent: Monday, August 25, 2014 8:15 PM Subject: Re: filesystem > Hello Bill. [snip] > You're trying to understand what exactly? From the user point of view, > dir_index just makes directory accesses on very big directories faster. > When creating a new file, or

Hello (and Moin Moin) ;) I have currently a straith Problem ... I have our IMAP-Server migrated from an old cyrus the the current stable Version of dovecot. In the old configuration we organized many mails (e.g. root-Stuff) in Public Folders. They structure had nearly 5 folderlevels. After the complete migration an syncronize we switch complete to the dovecot setup. At this moment we have

> R code works but the shared objects built from fortran code do not find > the appropriate libs with functions like __pow_ii or __epx at runtime. I used to have endless trouble with __pow_ii which as I recall could be be fixed by the correct incantation of the mix of compiler libraries and LD_LIBRARY_PATH. It seemed to be extremely sensitive and never easy to get right. The problem is

Hi, The method to boot an ISO using memdisk, memdiskfind and phram described in the wiki looks very promising to me. So, I looked into the sources trying to understand, how this works. Up to now, I could not find out how the memory containing the ISO image is preserved from being overwritten by the Linux kernel. Probably I'm missing something, could you please help me? Best regards, Bodo

Hello Bill again. Two things. First. I read this mailing list, so no need to send answers to me personally in copy. Second. I guessed it already, but now it got really obvious, that you didn't do your homework. Please search for your questions in your favorite search engine first. Yes, I know, that there is not much easy to understand information on ext2 (in all flavours) out there, but

Dear R-List, I have a dataframe X containing factor f and numeric variable x1, x2, ... I want to create a new dataframe (or possibly a matrix) that gives statistics (e.g. sum) for the variables x1, x2, ... in each group defined by factor f. What is the simplest way to do this? I tried: attach(X) Z <- data.frame(f=levels(f),x1=as.vector(lapply(split(x1,f),sum))) and stumbled on: Error

* "Theodore Ts'o" <tytso@mit.edu> hat geschrieben: Hi Theodore. > That being said, it's pretty clear that portions of the inode table > and block group descriptor was badly corrupted. [...] Keith is not the first one with problems of this class and he will probably not be the last one. He later told us, that at first, mounting the file system still worked. And that

* Andreas Dilger <adilger@dilger.ca> hat geschrieben: > You can see in the ext4 superblock the amount of data that has been > written to a filesystem over its lifetime: > > Note that this number isn't wholly accurate, but rather a guideline. Is is more like a completely bogus value at best: # LANG=C df -h / | grep root /dev/root 3.7T 3.6T 73G 99% / # grep [0-9]

* Andreas Dilger <adilger@dilger.ca> hat geschrieben: > The "lifetime writes" value has not been around forever, so if the > filesystem was originally created and populated on an older kernel > (e.g. using ext3) it would not contain a record of those writes. It was created as stable ext4 in the first place. So only if there was a stable ext4 release which didn't

On Thu, Oct 16, 2014 at 11:01:35PM +0200, Bodo Thiesen wrote: > > Since it never get's updated unless the file system is unmounted, it can > only be used for a 24 hours test by mounting the file system now, > unmounting it 24 hours from now and then taking the difference. It also gets updated if the file system syncfs(2) or sync(2) system call. But if you crash, any writes since

* "Bill Cunningham" <billcun@suddenlink.net> hat geschrieben: > I hope this is the right list. I have created an ext2 filesystem and > removed the dir_index feature. I don't know if this kind of experimentation > is going to help me learn something about filesystems or not. Well what is > dir_index? Then I ran e2fsck -f -v -pD and the /dev file. Now what did I >

Hi Bodo and Ted, Thank you both for your responses; they confirm what I thought might be the case. Knowing that I can try to proceed with your suggestions. I do have some followup questions for you: On Sun, Jun 01, 2014 at 09:05:09PM -0400, Theodore Ts'o wrote: > Unfortunately, there has been a huge number of bug fixes for ext4's > online resize since 2.6.32 and 1.42.11.

* Keith Keller <kkeller@wombat.san-francisco.ca.us> hat geschrieben: Hi Keith > I have a very similar second server which has undergone a similar chain > of events, an initial ~2.5tb fs followed by a resize later. I believe > that it has been fsck'd since the resize (but don't quote me on that). > Am I likely to run into this issue with this fs? And if I do, what >

Hi all, On Mon, Jun 02, 2014 at 11:04:52PM +0200, Bodo Thiesen wrote: > > Keith is not the first one with problems of this class and he will > probably not be the last one. He later told us, that at first, mounting > the file system still worked. Is there any value in discussing this issue in keeping this broken filesystem available for debugging purposes? I would like at this