Re: [ESS] [External] [R-win] Difficulty installing R packages under Windows 11 / Cygwin

2023-12-02 Thread Richard M. Heiberger via ESS-help
my initial reaction is that you are trying to hard.  I haven't paid serious 
attention to Windows since
I switched to Mac about 10 years ago.

What I recall is that all the unix utilities (sh, awk, grep, etc) that you need 
are included in the
Rtools collection.  Indeed they are exactly the cygwin utilities.  I know that 
I stopped bothering
with cygwin itself once I meade that realization.  Then, since all the unix 
functions are distributed by
R, you know that they are fully compatible.  I used the CRAN distibuted Windows 
binary for R.

Rich

> On Dec 2, 2023, at 12:59, Sparapani, Rodney via ESS-help 
>  wrote:
>
> Hi Robert:
>
> Would they allow dual-booting?  I’m not saying that you can’t get ESS
> to work under Cygwin.  On the contrary, it did work at one time so
> it certainly can be done.  However, that is not currently supported
> so you are on your own.  But, perhaps there are others in the same
> straight-jacket here on ess-help that might be willing to help?
> Please speak up if so!
>
> In regards to WSL, that came out after I permanently switched
> to macOS.  But, I think it is worth a try too.  Since you will be
> running pure Linux binaries, then it might work out of the box.
> And maybe there are more people here interested in WSL than
> Cygwin.  Also, the more recent WSL 2 (released in 2019) sounds
> like it is more compatible than WSL 1 (released in 2016).
>
> --
> Rodney Sparapani, Associate Professor of Biostatistics, He/Him/His
> Vice President, Wisconsin Chapter of the American Statistical Association
> Institute for Health and Equity, Division of Biostatistics
> Medical College of Wisconsin, Milwaukee Campus
>
> From: Robert Lerche 
> Date: Saturday, December 2, 2023 at 11:40 AM
> To: Sparapani, Rodney , Tomas Kalibera 
> 
> Subject: RE: [R-win] Difficulty installing R packages under Windows 11 / 
> Cygwin
> ATTENTION: This email originated from a sender outside of MCW. Use caution 
> when clicking on links or opening attachments.
> 
> Thanks for your thoughtful reply.  Alas, I am using a company-provided 
> laptop.  I would much prefer to run Linux as I do on my personal system but 
> that is not in the cards.  I have plenty of access to Linux servers and of 
> course I can run things there but it’s a bit inconvenient.
>
> I thought about using WSL (Windows Subsystem for Linux). I have some 
> experience with early versions of that [which leads me to avoid it  ].
>
> It is my fate to cope with legacy junk on projects that were late when I 
> joined. Ah well it’s a living.
>
> From: Sparapani, Rodney 
> Sent: Saturday, December 2, 2023 9:28 AM
> To: Robert Lerche ; Tomas Kalibera 
> ; ess-help (ess-help@r-project.org) 
> 
> Subject: Re: [R-win] Difficulty installing R packages under Windows 11 / 
> Cygwin
>
>
> [EXTERNAL MESSAGE] Be mindful when clicking links or attachments
> Hi Robert:
>
> There was a time when we supported ESS under Cygwin.
> In other words, run elisp code assuming UNIX/Linux rather
> than Windows even though Windows is the OS.  However,
> that was a long time ago: at least 10 years since I last tried it.
> Cygwin has largely fallen out of fashion since you can now so
> easily install Ubuntu on typical hardware: something that
> has markedly improved since 2013.  Therefore, I would not
> expect Cygwin support to work out of the box since there
> has been no recent testing.  Also, Windows is not very
> popular with R users since there is no forking support
> for the parallel package.  So switching to Linux is well
> worth it.  I used to run Windows inside VirtualBox when
> I needed to do PC stuff like Office and iTunes
> (before switching to macOS and never looking back ;o)
>
> --
> Rodney Sparapani, Associate Professor of Biostatistics, He/Him/His
> Vice President, Wisconsin Chapter of the American Statistical Association
> Institute for Health and Equity, Division of Biostatistics
> Medical College of Wisconsin, Milwaukee Campus
>
> From: ESS-bugs 
> mailto:mailman-boun...@stat.ethz.ch>> on behalf 
> of Robert Lerche 
> mailto:rler...@pacificbiosciences.com>>
> Date: Saturday, December 2, 2023 at 11:04 AM
> To: Tomas Kalibera 
> mailto:tomas.kalib...@gmail.com>>, 
> ess-b...@r-project.org 
> mailto:ess-b...@r-project.org>>
> Cc: ess-bugs-ow...@r-project.org 
> mailto:ess-bugs-ow...@r-project.org>>, 
> r-wind...@r-project.org 
> mailto:r-wind...@r-project.org>>
> Subject: RE: [R-win] Difficulty installing R packages under Windows 11 / 
> Cygwin
> ATTENTION: This email originated from a sender outside of MCW. Use caution 
> when clicking on links or opening attachments.
> 
>
> Let me try raw text:
>
> Tomas, my thanks for your prompt and useful response. I followed your 
> instructions and the Windows (MinGW/MSYS2) R and ggplot2 of course work 
> perfectly well launched from a Cygwin bash shell.  Alas, 

Re: [ESS] [External] R Transcript opens in readonly buffer

2023-11-25 Thread Richard M. Heiberger via ESS-help
Yes, that is the designed behavior.  A transcript is the history of a previous 
session.  Normally you
would not want to change it.

What you might want to do is open a new .r file and copy the source code from 
the transcript into
the new file.  Pick up the entire section of transcript (input with prompts, 
and output) and then
paste it into a new .r buffer with the command C-u C-u C-y for  
‘ess-yank-cleaned-commands’.

pick up three lines from oldfile.rout or from *R*
> 5 + 4
[1] 9
>

and paste them with C-u C-u C-y into file tmp.r or, perhaps directly into *R*
5 + 4

Note that all prompts and responses have been removed.

And in the rare case that you actually want to edit history, you can
always use C-x C-q to toggle read-only mode.

Rich

> On Nov 25, 2023, at 00:02, Ishe Chinyoka via ESS-help 
>  wrote:
>
> Hi,
>
> I am having a problem whereby if I save a .Rout transcript,
> when I try to open it next time, I cannot edit it. It opens the buffer
> in readonly mode. What could be the cause of opening in readonly mode? I
> wnat to continue working on some transcript in a new session.
>
> I am using emacs 29 and ESS version 18.10.3snapshot on Archlinux.
>
> TIA,
>
> Ishe
>
> __
> ESS-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/ess-help

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help


Re: [ESS] [External] Re: ESS confused about newest R

2022-07-13 Thread Richard M. Heiberger via ESS-help
The change in date format makes sense.  The short term workaround is to set the 
specific R you want.

In general, that ESS code on Windows was designed to find R in any of a number 
of standard places.   The list of what
those standard places are is also a variable you can set.  The details have 
been changed since I wrote it, so someone
more current will need to verify and modify the code.

Rich

From: ESS-help  on behalf of Kevin R. Coombes 
via ESS-help 
Date: Wednesday, July 13, 2022 at 11:16
To: Shreyas Ragavan 
Cc: ess-help@r-project.org 
Subject: [External] Re: [ESS] ESS confused about newest R
*Latest Follow-up*

I think I have found the offending code in "ess-r-mode.el". The critical
function appears to be "ess-r-version-date". This function actually runs
the Rterm.exe for each version of R (who knew?) that it located, using
the "--version" command line argument. It then parses the version line
to find the actual release date. Starting with R-4.2.0 (at least on
Windows), that line has changed from the previous form:
   R version 4.1.0 (2021-05-18) -- "Camp Pontanezen"
to something like:
   R version 4.2.0 (2022-04-22 ucrt) -- "Vigorous Calisthenics"
Note in particular the extra " ucrt" in the parenthetical display of the
date. I strongly suspect that the regexp being used to parse the date
fails to recognize this new form.

I am also 100% certain that I cannot rewrite the regexp to work in this
setting without breaking something else, since it is carefully and
complexly designed to parse *all* of the version-date lines going back
to R 1.0.1.

To whom and where should I report this as a bug in order to encourage
one of the ESS gurus to see if my conjectured explanation of the bug is
correct and (I hope) manage to fix it?

Best,
   Kevin

On 6/29/2022 1:24 PM, Kevin R. Coombes wrote:
> Follow-up:
>
> I just installed the latest emacs (28.1) and used MELPA to install the
> latest version of ESS (20220621). With this new setup, I still have
> the same problem. ESS/R finds all versions of R on my system, and
> generates separate commands for each one (including the newest,
> R-4.2.1-64bit. However, R-newest thinks that the newest version I have
> is R-4.1.0, and so the command "M-x R" starts the 64bit version of
> R-4.1.0.
>
> To test my hypothesis that this has something to do with 32-bit vs
> 64-bit, I tried the following experiment. I created a folder
> "bin/i386" inside my R 4.2.1 installation, and copied R.exe and
> Rterm.exe from the R-4.1.0 installation into that folder. Now when I
> try to run R, it finds both the real R-4.2.1-64bit and my fake
> R-4.2.1-32bit. But (damnit) it still runs R-4.1.0 as though it were
> the newest version. So, I have no idea if 32bit is a red herring or
> not, and I am mightily confused about why ESS doesn't seem to like
> R-4.2.1.
>
> On 6/29/2022 11:18 AM, Kevin R. Coombes wrote:
>> To clarify, I don't ever start R (as Rterm) from a  command line
>> prompt on Windows. As a result, I really don't bother to put the R
>> installation location into the PATH environment variable, since I
>> don't want to have to update it every time a new version is released.
>> (For the same reason, I don't want to have to manually set
>> "inferior-ess-r-program" and have to remember to update it with new
>> releases.)
>>
>> I have desktop icons for the RGui. I can see the version number and
>> name on those icons if I want to start R that way; those all work. I
>> also have no problem using RStudio, which continues to be successful
>> in automatically finding the newest versions. The only problem is
>> with ESS inside of emacs, and it started with version 4.2.0, which
>> coincided with dropping the creation of 32-bit R versions on Windows.
>>
>> Further, ESS/R does *find *all versions of R on my system. I know
>> this because it creates separate startup commands (such as
>> R-4.2.0-64bit). That part that fails is the code in the file
>> "ess-r-mode.el" that is supposed to find the newest R from the list
>> of all available versions.
>>
>> On 6/29/2022 9:57 AM, Shreyas Ragavan wrote:
>>> I wanted to add a suggestion here that when or if you add multiple R 
>>> versions from non-standard paths to your PATH environment variable in 
>>> Windows (to enable Emacs or any program to find the R executable) - it is 
>>> important to make sure the desired version of R is the First path. Programs 
>>> will stop looking for the executable once it is found, and if an earlier R 
>>> version is found before the desired version - that is what would start up.
>>>
 Your (from description) Windows system appears confused about where to find
 R, and doubly so as a 32/64 bit convention is dead, and there is only 
 64bit.

 On operating systems that use $PATH you can _always_ just point to a 
 working
 R by pointing RHOME/bin so that the right R is found. It has been years 
 since
 I worked on Windows but it got the R I wanted when I told ESS in no 
 uncertain
 

Re: [ESS] [External] ESS Annoying "Feature"

2021-06-16 Thread Richard M. Heiberger via ESS-help
this looks like the issue I reported in February.  Here is the response Lionel 
sent the list at that time (feb 18, 02:55)
I choose to ignore the nuisance.

Rich




Hello,

This is a known issue with ESS 18.10 and Emacs 27. Either dowgrade
Emacs or install dev ESS to fix this. A new release is much needed but
there's still a bunch of problems to solve. We're aiming for an April
release.

As a workaround you can add this to your config:

```
(setq ess-can-eval-in-background nil)
```

You won't get the parasite output as you type. Unfortunately this
disables all contextual help (eldoc, completions, ...).

Best,
Lionel


On 2/18/21, Richard M. Heiberger via ESS-help  wrote:


> On Jun 16, 2021, at 11:38, Bassett Jr,Roland L via ESS-help 
>  wrote:
> 
> Greetings to all.  At some point, my ESS developed the following feature: 
> when I am editing an .Rnw file with R running in another frame, and the 
> cursor is in the middle of a function, it provides a list of possible 
> completions in the R window.  This takes the form of:
> 
> (list "" etc.)
> 
> It does this multiple times.  How can I turn this off?  Thanks for any help!
> 
> Roland Bassett
> 
> The information contained in this e-mail message may be ...{{dropped:14}}
> 
> __
> ESS-help@r-project.org mailing list
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fess-helpdata=04%7C01%7Crmh%40temple.edu%7C33cb0d517ef24e2d173508d930dcd132%7C716e81efb52244738e3110bd02ccf6e5%7C0%7C0%7C637594547229252748%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ihXTG3XLogFg7wfJNc54SLZ8KUinvIv6mjr5khVWS3Y%3Dreserved=0

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help


Re: [ESS] [External] Re: ESS M-x R failing in a Windows installation

2021-03-10 Thread Richard M. Heiberger via ESS-help
The relevant question is what version of ess are you using?
more specifically which version of ess is included with VIncent Goulet's 
emacs-26.1?

the "bin/x64/Rterm.exe" construction is not in ess-16.10
It is in ess-18.10

the /x64/ wasn't meaningful until R stsarted releasing both 32-bit versions and 
64-bit versions.


I don't remember ever using the Windows directory.
U introduced ess-rterm-version-paths at some point.  It has been rewritten
since then, but should still be working as long as you have a recent enough ess.


From: ESS-help  on behalf of Sparapani, Rodney 
via ESS-help 
Sent: Wednesday, March 10, 2021 10:40
To: ess-help@r-project.org
Subject: [External] Re: [ESS] ESS M-x R failing in a Windows installation

Hi Jeremie:

As you say, Windows installs do depend on the user’s preferences.
However, in ancient ESS (circa 2004), we coded around this by
going to the Windows registry.  However, I have rarely used
Windows since so I can’t say how that approach might be
used today (or if it is, how it might be failing).  I think a big
issue is that few (if any) ESS developers are using Windows.
Rich was probably the rear guard and he switched to Mac.

PS. the old registry discussions are probably in the archives
https://stat.ethz.ch/pipermail/ess-help/

--
Rodney Sparapani, Associate Professor of Biostatistics
Chair ISBA Section on Biostatistics and Pharmaceutical Statistics
Institute for Health and Equity, Division of Biostatistics
Medical College of Wisconsin, Milwaukee Campus


[[alternative HTML version deleted]]

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help


Re: [ESS] [External] Re: [External] Re: [External] Re: emacs 27.1 crashes regularly on Mac M1

2021-03-05 Thread Richard M. Heiberger via ESS-help
I am out of my depth.  I downloaded
https://emacsformacosx.com/emacs-builds/Emacs-27.1-1-universal.dmg
When I unpacked it, it has the same files as vincent's distribution.
download
  -rwxr-xr-x   1 rmh  staff   7308192 Aug 12  2020 Emacs-x86_64-10_10
  -rw-r--r--@  1 rmh  staff  15484072 Aug 12  2020 Emacs-x86_64-10_10.pdmp
  -rwxr-xr-x   1 rmh  staff   7418304 Aug 12  2020 Emacs-x86_64-10_14
  -rw-r--r--@  1 rmh  staff  15484336 Aug 12  2020 Emacs-x86_64-10_14.pdmp
  -rw-r--r--@  1 rmh  staff  15484072 Aug 12  2020 Emacs.pdmp
   lrwxr-xr-x   1 rmh  staff16 Aug 12  2020 bin -> bin-x86_64-10_10
  drwxr-xr-x   6 rmh  staff   204 Aug 12  2020 bin-x86_64-10_10
  drwxr-xr-x   6 rmh  staff   204 Aug 12  2020 bin-x86_64-10_14
 
Vincent
  -rwxr-xr-x@  1 rmh  admin   7308192 Sep 16 10:09 Emacs-x86_64-10_10
  -rw-r--r--@  1 rmh  admin  15484072 Aug 12  2020 Emacs-x86_64-10_10.pdmp
  -rwxr-xr-x@  1 rmh  admin   7418304 Sep 16 10:09 Emacs-x86_64-10_14
  -rw-r--r--@  1 rmh  admin  15484336 Aug 12  2020 Emacs-x86_64-10_14.pdmp
  -rw-r--r--@  1 rmh  admin  15484072 Aug 12  2020 Emacs.pdmp
   lrwxr-xr-x   1 rmh  admin16 Sep 16 10:09 bin -> bin-x86_64-10_10
  drwxr-xr-x@  6 rmh  admin   192 Sep 16 10:09 bin-x86_64-10_10
  drwxr-xr-x@  6 rmh  admin   192 Sep 16 10:09 bin-x86_64-10_14

My March 1 crash report said
> Process:   Emacs-x86_64-10_14 [1112]
> Path:  
> /Applications/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14
> Identifier:org.gnu.Emacs
> Version:   Version 27.1 (9.0)
> Code Type: X86-64 (Translated)
> Parent Process:??? [1]
> Responsible:   Emacs-x86_64-10_14 [1112]

Which looks to be translated (Code Type: X86-64 (Translated))

Why is it running Emacs-x86_64-10_14 when the redirection
  lrwxr-xr-x   1 rmh  admin16 Sep 16 10:09 bin -> bin-x86_64-10_10
suggests it should be running 
Emacs-x86_64-10_10


I will not finish the installation (by dragging the newly downloaded Emacs to 
the Appliations folder)
until I hear further.

Rich


From: Richard M. Heiberger 
Sent: Friday, March 5, 2021 12:18
To: ess-help@r-project.org; Sparapani, Rodney
Subject: Re: [External] Re: [ESS]  [External] Re: [External] Re: emacs 27.1 
crashes regularly on Mac M1

good idea. i am now downloading a universal build instead of the x86-64 that 
Vincent Goulet distributed.
I will report back in a few days.


From: ESS-help  on behalf of Sparapani, Rodney 
via ESS-help 
Sent: Friday, March 5, 2021 09:17
To: ess-help@r-project.org
Subject: [External] Re: [ESS]  [External] Re: [External] Re: emacs 27.1 crashes 
regularly on Mac M1

Hi Rich:

To me, it seems unlikely that this is an emacs issue.
I think you should be sending your crash reports to
Apple.  Especially if this is a Rosetta issue as you
suspect.  My 2 cents ;o)

--

Rodney Sparapani, Associate Professor of Biostatistics
Chair ISBA Section on Biostatistics and Pharmaceutical Statistics
Institute for Health and Equity, Division of Biostatistics
Medical College of Wisconsin, Milwaukee Campus


__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help


Re: [ESS] [External] Re: [External] Re: [External] Re: emacs 27.1 crashes regularly on Mac M1

2021-03-05 Thread Richard M. Heiberger via ESS-help
good idea. i am now downloading a universal build instead of the x86-64 that 
Vincent Goulet distributed.
I will report back in a few days.


From: ESS-help  on behalf of Sparapani, Rodney 
via ESS-help 
Sent: Friday, March 5, 2021 09:17
To: ess-help@r-project.org
Subject: [External] Re: [ESS]  [External] Re: [External] Re: emacs 27.1 crashes 
regularly on Mac M1

Hi Rich:

To me, it seems unlikely that this is an emacs issue.
I think you should be sending your crash reports to
Apple.  Especially if this is a Rosetta issue as you
suspect.  My 2 cents ;o)

--

Rodney Sparapani, Associate Professor of Biostatistics
Chair ISBA Section on Biostatistics and Pharmaceutical Statistics
Institute for Health and Equity, Division of Biostatistics
Medical College of Wisconsin, Milwaukee Campus


__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help


Re: [ESS] [External] Re: [External] Re: emacs 27.1 crashes regularly on Mac M1

2021-03-04 Thread Richard M. Heiberger via ESS-help
It has crashed three times in the last hour.  Each time as I was typing into my 
filename.r buffer.

This time the Problem Report message to Apple includes

Exception Type:EXC_BAD_ACCESS (SIGABRT)
Exception Codes:   KERN_INVALID_ADDRESS at 0x015a
Exception Note:EXC_CORPSE_NOTIFY

The previous example I reported here had
Exception Type:EXC_CRASH (SIGABRT)
Exception Codes:   0x, 0x
Exception Note:EXC_CORPSE_NOTIFY

The previous one has
> Assertion failed: (mach_vm_map(mach_task_self(), , size, 0, 
> VM_FLAGS_ANYWHERE | VM_MAKE_TAG(VM_MEMORY_COREGRAPHICS_BACKINGSTORES), port, 
> 0, false, prot, prot, VM_INHERIT_SHARE) == KERN_SUCCESS), function 
> backing_map, file 
> /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/SkyLight/SkyLight-570.7/SkyLight/Services/Windows/CGSBackingStore.c,
>  line 192.

The current crash does not have an equivalent statement.

I will be happy to forward this type of message directly to emacs.  To whom 
should it be sent?

Rich

From: Richard M. Heiberger 
Sent: Wednesday, March 3, 2021 12:04
To: ess-help@r-project.org; Sparapani, Rodney
Subject: Re: [External] Re: [ESS] [External] Re: emacs 27.1 crashes regularly 
on Mac M1

i almost never use those menus.  my fingets know the emacs key-combinations too 
well.
It comes out of the blue and catches me unawares.  The only thing that occurs 
to me is something
similar to Rmpfr error discussed on R-sig-mac list about a week ago.  Simon 
traced it to a rarely used
intel machine command that didn't get handled in rosetta.


From: ESS-help  on behalf of Sparapani, Rodney 
via ESS-help 
Sent: Wednesday, March 3, 2021 08:18
To: ess-help@r-project.org
Subject: [External] Re: [ESS] [External] Re: emacs 27.1 crashes regularly on 
Mac M1

Hi Rich:

Does it happen when you try to use the File, Edit, etc., items
on the Apple menu at the top of the screen?  I have been
experiencing these crashes with 26.3 for a couple years.
I got around it by using the set of binaries listed here...
https://gitlab.com/vigou3/emacs-modified-macos/-/issues/6

--

Rodney Sparapani, Associate Professor of Biostatistics
Chair ISBA Section on Biostatistics and Pharmaceutical Statistics
Institute for Health and Equity, Division of Biostatistics
Medical College of Wisconsin, Milwaukee Campus


__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help


Re: [ESS] [External] Re: [External] Re: emacs 27.1 crashes regularly on Mac M1

2021-03-03 Thread Richard M. Heiberger via ESS-help
i almost never use those menus.  my fingets know the emacs key-combinations too 
well.
It comes out of the blue and catches me unawares.  The only thing that occurs 
to me is something
similar to Rmpfr error discussed on R-sig-mac list about a week ago.  Simon 
traced it to a rarely used
intel machine command that didn't get handled in rosetta.


From: ESS-help  on behalf of Sparapani, Rodney 
via ESS-help 
Sent: Wednesday, March 3, 2021 08:18
To: ess-help@r-project.org
Subject: [External] Re: [ESS] [External] Re: emacs 27.1 crashes regularly on 
Mac M1

Hi Rich:

Does it happen when you try to use the File, Edit, etc., items
on the Apple menu at the top of the screen?  I have been
experiencing these crashes with 26.3 for a couple years.
I got around it by using the set of binaries listed here...
https://gitlab.com/vigou3/emacs-modified-macos/-/issues/6

--

Rodney Sparapani, Associate Professor of Biostatistics
Chair ISBA Section on Biostatistics and Pharmaceutical Statistics
Institute for Health and Equity, Division of Biostatistics
Medical College of Wisconsin, Milwaukee Campus


__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help


Re: [ESS] [External] Re: emacs 27.1 crashes regularly on Mac M1

2021-03-02 Thread Richard M. Heiberger via ESS-help
I have not tried anything at this point.  I don't have any sense of what 
specific causes the
crash.  I just notice that it crashes about twice a week, and that I have not 
seen that type of
behavior previously with the Mac Intel.

Rich


From: Vincent Goulet 
Sent: Tuesday, March 2, 2021 14:51
To: Richard M. Heiberger
Cc: ess-h...@stat.math.ethz.ch
Subject: [External] Re: emacs 27.1 crashes regularly on Mac M1

Hi Richard,

I can't test as I don't have an M1 Mac available.

Did you try David Caldwell's "bare" binaries: https://emacsformacosx.com. Those 
are the binaries my distribution is based on.

HTH

v.

> Le 1 mars 2021 à 23:32, Richard M. Heiberger  a écrit :
>
> I don't know if this is emacs issue or an emacs plus ESS issue.
> I am using Vincent Goulet's
> "Emacs Modified for macOS is a distribution of GNU Emacs 27.1 (released 
> August 10, 2020) bundled with a few select packages for R developers and 
> LaTeX users."
>
> Process:   Emacs-x86_64-10_14 [1112]
> Path:  
> /Applications/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14
> Identifier:org.gnu.Emacs
> Version:   Version 27.1 (9.0)
> Code Type: X86-64 (Translated)
> Parent Process:??? [1]
> Responsible:   Emacs-x86_64-10_14 [1112]
> User ID:   501
>
> Date/Time: 2021-03-01 23:25:38.949 -0500
> OS Version:macOS 11.2.1 (20D74)
> Report Version:12
> Anonymous UUID:CD05A40D-F8F8-8D66-467F-B3BD97895B44
>
> Sleep/Wake UUID:   DB08A8C9-1154-4E41-AC03-5301812DB8E1
>
> Time Awake Since Boot: 28000 seconds
> Time Since Wake:   9400 seconds
>
>
>
> System Integrity Protection: enabled
>
> Crashed Thread:0  Dispatch queue: com.apple.main-thread
>
> Exception Type:EXC_CRASH (SIGABRT)
> Exception Codes:   0x, 0x
> Exception Note:EXC_CORPSE_NOTIFY
>
> Application Specific Information:
> Assertion failed: (mach_vm_map(mach_task_self(), , size, 0, 
> VM_FLAGS_ANYWHERE | VM_MAKE_TAG(VM_MEMORY_COREGRAPHICS_BACKINGSTORES), port, 
> 0, false, prot, prot, VM_INHERIT_SHARE) == KERN_SUCCESS), function 
> backing_map, file 
> /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/SkyLight/SkyLight-570.7/SkyLight/Services/Windows/CGSBackingStore.c,
>  line 192.

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help


[ESS] emacs 27.1 crashes regularly on Mac M1

2021-03-01 Thread Richard M. Heiberger via ESS-help
I don't know if this is emacs issue or an emacs plus ESS issue.
I am using Vincent Goulet's
"Emacs Modified for macOS is a distribution of GNU Emacs 27.1 (released August 
10, 2020) bundled with a few select packages for R developers and LaTeX users."

Process:   Emacs-x86_64-10_14 [1112]
Path:  /Applications/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14
Identifier:org.gnu.Emacs
Version:   Version 27.1 (9.0)
Code Type: X86-64 (Translated)
Parent Process:??? [1]
Responsible:   Emacs-x86_64-10_14 [1112]
User ID:   501

Date/Time: 2021-03-01 23:25:38.949 -0500
OS Version:macOS 11.2.1 (20D74)
Report Version:12
Anonymous UUID:CD05A40D-F8F8-8D66-467F-B3BD97895B44

Sleep/Wake UUID:   DB08A8C9-1154-4E41-AC03-5301812DB8E1

Time Awake Since Boot: 28000 seconds
Time Since Wake:   9400 seconds



System Integrity Protection: enabled

Crashed Thread:0  Dispatch queue: com.apple.main-thread

Exception Type:EXC_CRASH (SIGABRT)
Exception Codes:   0x, 0x
Exception Note:EXC_CORPSE_NOTIFY

Application Specific Information:
Assertion failed: (mach_vm_map(mach_task_self(), , size, 0, 
VM_FLAGS_ANYWHERE | VM_MAKE_TAG(VM_MEMORY_COREGRAPHICS_BACKINGSTORES), port, 0, 
false, prot, prot, VM_INHERIT_SHARE) == KERN_SUCCESS), function backing_map, 
file 
/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/SkyLight/SkyLight-570.7/SkyLight/Services/Windows/CGSBackingStore.c,
 line 192.
 
__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help


Re: [ESS] unexpected behavior for Emacs-27.1-1-modified-1 for two MacBooks.

2021-01-27 Thread Richard M. Heiberger via ESS-help
For completeness:
I decided to stay with aspell. simply because that (60.6 from 2014) is what I 
had been using,.
I downloaded hombrew and had it install the newer aspell 60.8 (2019).
Just four lines and now M-x ispell works.
  /bin/bash -c "$(curl -fsSL 
https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
  /usr/local/bin/brew update
  /usr/local/bin/brew install aspell
  /usr/local/bin/brew link --overwrite aspell


From: ESS-help  on behalf of Richard M. 
Heiberger via ESS-help 
Sent: Tuesday, January 26, 2021 8:38 PM
To: Stephen Berman; Richard M. Heiberger via ESS-help
Subject: Re: [ESS] unexpected behavior for Emacs-27.1-1-modified-1 for two 
MacBooks.

Thank you Stephen.

The two emacs repairs (find-dired-refine-function and find-dired-filter) you 
sent worked for me.

The aspell I pushed a bit farther.  In 2015 I replaced the aspell (dated 2009) 
in /usr/local/bin with something from homebrew.
I remember no details.  When I installed the new M1, the Apple installation 
process automatically copied everything from the old machine,
including the homebrew aspell and my subdirectory containing the 2009 files.
If there had been an Apple M1 aspell, it was overridden.  Based on Vincent 
Goulet's notes, there might
not have been one, and in any case he recommends hunspell.  I will address the 
spelling problem soon, but not today.

Rich


From: Stephen Berman 
Sent: Tuesday, January 26, 2021 4:07 PM
To: Richard M. Heiberger via ESS-help
Cc: Richard M. Heiberger
Subject: Re: unexpected behavior for Emacs-27.1-1-modified-1 for two MacBooks.

On Tue, 26 Jan 2021 18:49:57 +0000 "Richard M. Heiberger via ESS-help" 
 wrote:

> I just downloaded Emacs-27.1-1-modified-1 for two MacBooks.
> I have been using the previous 25.1.1 successfully on both machines.
> 1. My new MacBook Air M1, running Big Sur
> 2. My old MacBook Air mid 2012, running Catalina (it is too old for Big Sur)
>
> I have three unexpected behaviors, and they are not identical on the two 
> machines.
> Has anyone seen these before?  Do you have idea about what is happening?
>
> Thank you,
> Rich
>
>
> I. Both machines report in *Messages*
>Package cl is deprecated

The NEWS file in Emacs 27 says:

  ** The 'cl' package is now officially deprecated in favor of 'cl-lib'.

> II. When I search find-dired in
> /Applications.Emacs.app/Contents/Resources/site-lisp with the command
> I have been using for many years
> -name \*.el -exec grep 'cl-' {} ";"
> new machine:
>   searches normally with instances found in each followed by the
>   file's dired information.  Then before stopping, it sorts all
>   instances together, followed by all dired entries together.
>   Essentialy useless.
> old machine:
>   same as above

The NEWS file in Emacs 27 says:

  *** New user option 'find-dired-refine-function'.
  The default value is 'find-dired-sort-by-filename'.

So you can prevent the resorting by setting find-dired-refine-function
to nil (by setq in your init file or by `M-x customize-option').

> On both machines, when I pick one of my own directories and do a similar 
> search,
> old machine:
>   behaves normally but reports:
>   error in process sentinel: Wrong type argument: integer-or-marker-p, nil
> new machine:
>   did the useless re-sort as described above.

When I try your find-dired string in emacs-27 (and also in emacs-28) I
also get an error in process sentinel, but a different one:
"find-dired-filter: Invalid use of ‘\’ in replacement text".  This
appears to be due to this change:

commit fb20043b2fec8e8aff6354ec1396fd5ba688b76b
Author: Sebastian Reuße 
AuthorDate: Sat Dec 30 12:41:23 2017 +0200
Commit: Eli Zaretskii 
CommitDate: Sat Dec 30 12:41:23 2017 +0200

Fix output alignment in 'find-dired' for "ls -h"

* lisp/find-dired.el (find-dired-filter): Fix alignment of
the file size column when the -h ls option is used in
'find-ls-option'.  (Bug#29803)

index 3b0613b280..bf815d500d 100644
--- a/lisp/find-dired.el
+++ b/lisp/find-dired.el
@@ -295,7 +295,7 @@ find-dired-filter
(l-opt (and (consp find-ls-option)
(string-match "l" (cdr find-ls-option
(ls-regexp (concat "^ +[^ \t\r\n]+\\( +[^ \t\r\n]+\\) +"
-  "[^ \t\r\n]+ +[^ \t\r\n]+\\( 
+[0-9]+\\)")))
+  "[^ \t\r\n]+ +[^ \t\r\n]+\\( 
+[^[:space:]]+\\)")))
(goto-char beg)
(insert string)
(goto-char beg)

When I revert this change (by replacing `^[:space:]' by `0-9' in the
above code excerpt), I don't get the error anymore.  Since the error
message you got is different, it may have a differe

Re: [ESS] unexpected behavior for Emacs-27.1-1-modified-1 for two MacBooks.

2021-01-26 Thread Richard M. Heiberger via ESS-help
That was the intent of my search for 'cl-'.
There are many instances found, now that the find-dired behaves sensibly again.

There are many files 
/Applications/Emacs.app/Contents/Resources/lisp/emacs-lisp/cl-*.el.gz

Since deprecated doesn't mean defunct, I will not pursue this further.

Rich


From: Dirk Eddelbuettel 
Sent: Tuesday, January 26, 2021 7:59 PM
To: Stephen Berman
Cc: ess-help@r-project.org; Richard M. Heiberger
Subject: Re: [ESS] unexpected behavior for Emacs-27.1-1-modified-1 for two 
MacBooks.


On 26 January 2021 at 22:07, Stephen Berman via ESS-help wrote:
| > I. Both machines report in *Messages*
| >Package cl is deprecated
|
| The NEWS file in Emacs 27 says:
|
|   ** The 'cl' package is now officially deprecated in favor of 'cl-lib'.

I know. What I do not know is which of the packages I load tickles this.

Dirk

--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help


Re: [ESS] unexpected behavior for Emacs-27.1-1-modified-1 for two MacBooks.

2021-01-26 Thread Richard M. Heiberger via ESS-help
Thank you Stephen.

The two emacs repairs (find-dired-refine-function and find-dired-filter) you 
sent worked for me.

The aspell I pushed a bit farther.  In 2015 I replaced the aspell (dated 2009) 
in /usr/local/bin with something from homebrew.
I remember no details.  When I installed the new M1, the Apple installation 
process automatically copied everything from the old machine,
including the homebrew aspell and my subdirectory containing the 2009 files.
If there had been an Apple M1 aspell, it was overridden.  Based on Vincent 
Goulet's notes, there might
not have been one, and in any case he recommends hunspell.  I will address the 
spelling problem soon, but not today.

Rich


From: Stephen Berman 
Sent: Tuesday, January 26, 2021 4:07 PM
To: Richard M. Heiberger via ESS-help
Cc: Richard M. Heiberger
Subject: Re: unexpected behavior for Emacs-27.1-1-modified-1 for two MacBooks.

On Tue, 26 Jan 2021 18:49:57 + "Richard M. Heiberger via ESS-help" 
 wrote:

> I just downloaded Emacs-27.1-1-modified-1 for two MacBooks.
> I have been using the previous 25.1.1 successfully on both machines.
> 1. My new MacBook Air M1, running Big Sur
> 2. My old MacBook Air mid 2012, running Catalina (it is too old for Big Sur)
>
> I have three unexpected behaviors, and they are not identical on the two 
> machines.
> Has anyone seen these before?  Do you have idea about what is happening?
>
> Thank you,
> Rich
>
>
> I. Both machines report in *Messages*
>Package cl is deprecated

The NEWS file in Emacs 27 says:

  ** The 'cl' package is now officially deprecated in favor of 'cl-lib'.

> II. When I search find-dired in
> /Applications.Emacs.app/Contents/Resources/site-lisp with the command
> I have been using for many years
> -name \*.el -exec grep 'cl-' {} ";"
> new machine:
>   searches normally with instances found in each followed by the
>   file's dired information.  Then before stopping, it sorts all
>   instances together, followed by all dired entries together.
>   Essentialy useless.
> old machine:
>   same as above

The NEWS file in Emacs 27 says:

  *** New user option 'find-dired-refine-function'.
  The default value is 'find-dired-sort-by-filename'.

So you can prevent the resorting by setting find-dired-refine-function
to nil (by setq in your init file or by `M-x customize-option').

> On both machines, when I pick one of my own directories and do a similar 
> search,
> old machine:
>   behaves normally but reports:
>   error in process sentinel: Wrong type argument: integer-or-marker-p, nil
> new machine:
>   did the useless re-sort as described above.

When I try your find-dired string in emacs-27 (and also in emacs-28) I
also get an error in process sentinel, but a different one:
"find-dired-filter: Invalid use of ‘\’ in replacement text".  This
appears to be due to this change:

commit fb20043b2fec8e8aff6354ec1396fd5ba688b76b
Author: Sebastian Reuße 
AuthorDate: Sat Dec 30 12:41:23 2017 +0200
Commit: Eli Zaretskii 
CommitDate: Sat Dec 30 12:41:23 2017 +0200

Fix output alignment in 'find-dired' for "ls -h"

* lisp/find-dired.el (find-dired-filter): Fix alignment of
the file size column when the -h ls option is used in
'find-ls-option'.  (Bug#29803)

index 3b0613b280..bf815d500d 100644
--- a/lisp/find-dired.el
+++ b/lisp/find-dired.el
@@ -295,7 +295,7 @@ find-dired-filter
(l-opt (and (consp find-ls-option)
(string-match "l" (cdr find-ls-option
(ls-regexp (concat "^ +[^ \t\r\n]+\\( +[^ \t\r\n]+\\) +"
-  "[^ \t\r\n]+ +[^ \t\r\n]+\\( 
+[0-9]+\\)")))
+  "[^ \t\r\n]+ +[^ \t\r\n]+\\( 
+[^[:space:]]+\\)")))
(goto-char beg)
(insert string)
(goto-char beg)

When I revert this change (by replacing `^[:space:]' by `0-9' in the
above code excerpt), I don't get the error anymore.  Since the error
message you got is different, it may have a different cause.  In any
case, it looks like it warrents a bug report (`M-x report-emacs-bug').

> ispell behaves differently (previous ispell, not using the hunspell 
> additional).
> old machine:
>   it works normally
> new machine:
>   ispell-check-version: /usr/local/bin/aspell exited with signal Illegal 
> instruction: 4

I can't help with this one, but maybe it's also worth a bug report.

Steve Berman

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help


[ESS] unexpected behavior for Emacs-27.1-1-modified-1 for two MacBooks.

2021-01-26 Thread Richard M. Heiberger via ESS-help
I just downloaded Emacs-27.1-1-modified-1 for two MacBooks.
I have been using the previous 25.1.1 successfully on both machines.
1. My new MacBook Air M1, running Big Sur
2. My old MacBook Air mid 2012, running Catalina (it is too old for Big Sur)

I have three unexpected behaviors, and they are not identical on the two 
machines.
Has anyone seen these before?  Do you have idea about what is happening?

Thank you,
Rich


I. Both machines report in *Messages*
   Package cl is deprecated

II. When I search find-dired in
/Applications.Emacs.app/Contents/Resources/site-lisp with the command
I have been using for many years
-name \*.el -exec grep 'cl-' {} ";"
new machine:
  searches normally with instances found in each followed by the
  file's dired information.  Then before stopping, it sorts all
  instances together, followed by all dired entries together.
  Essentialy useless.
old machine:
  same as above

On both machines, when I pick one of my own directories and do a similar search,
old machine:
  behaves normally but reports:
  error in process sentinel: Wrong type argument: integer-or-marker-p, nil
new machine:
  did the useless re-sort as described above.


ispell behaves differently (previous ispell, not using the hunspell additional).
old machine:
  it works normally
new machine:
  ispell-check-version: /usr/local/bin/aspell exited with signal Illegal 
instruction: 4

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help


Re: [ESS] [External] Re: R transcript file name suffix

2020-06-01 Thread Richard M. Heiberger via ESS-help
absolutely restore .rt as a valid transcript file name.

.st goes back to at least S-Plus and if my memory serves, to S.
.rt was constructed by analogy.
the .rout and .sout  are excessively verbose, rather recent additions.
Additions, not replacements.

Rich

On Mon, Jun 1, 2020 at 4:47 PM Alex Branham via ESS-help
 wrote:
>
> On Mon 01 Jun 2020 at 14:23, William McCoy via ESS-help 
>  wrote:
>
> > (setq auto-mode-alist (append '(("\\.[Rr]t\\'" . R-transcript-mode))
> >   auto-mode-alist))
> >
> > That line no longer has any effect on ESS and my .Rt suffix no longer
> > works; ESS expects .Rout as the suffix.
> >
> > How can I customize my ESS version 18.10.3snapshot to use .Rt as my
> > transcript file name suffix?
>
> R-transcript-mode was renamed to ess-r-transcript-mode. You'd want to
> use:
>
> (add-to-list 'auto-mode-alist '("\\.[Rr]t" . ess-r-transcript-mode))
>
> Perhaps we should provide the old name as an obsolete alias...
>
> Thanks,
> Alex
>
> __
> ESS-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/ess-help

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help


Re: [ESS] [External] Re: Function to copy command to script?

2020-05-19 Thread Richard M. Heiberger via ESS-help
Yes, your use case is exactly mine.  Since I normally have several buffers
open, sometimes in the same frame, sometimes in different frames,
I don't see that sequence as a big deal.  I just move the mouse and paste.

I just looked at the names of all the ess- commands
  C-h f ess- 
and don't see what you are looking for.

On Tue, May 19, 2020 at 12:35 PM Kevin Wright  wrote:

> Thanks for the comments. I'm not talking about working with a transcript
> file.  Rather, while I'm beta-testing a line of code in the inferior R
> process buffer, and then get a final version that I like, I'd like a single
> function to copy the most-recently-executed command (or the current command
> line) back into the R script and insert it at point, without the need to
> copy, switch-buffer, paste, switch buffer.  I could write this myself with
> some pain, but I find myself doing this type of editing all the time, so I
> figured there must already be a function.  But maybe not.
>
> Kevin
>
> On Tue, May 19, 2020 at 11:27 AM Richard M. Heiberger 
> wrote:
>
>> Hi Kevin,
>>
>> I think Stephen is assuming you do a lot of work in the *R* and then want
>> to recover it into a script.
>> For that case I wouldn't bother saving the *R* buffer, but would just
>> copy the relevant lines (including output)
>> and then save it back into the script file with C-u C-u C-y
>> (ess-yank-cleaned-commands).
>> The C-u C-u C-y strips out the prompts and output and pastes just the
>> input commands.
>>
>> For the way I read your email, you are looking to copy just a single line
>> from *R* to something.r.
>> For that I would just highlight it, then copy and paste.
>>
>> Rich
>>
>> On Tue, May 19, 2020 at 12:14 PM Stephen Eglen via ESS-help <
>> ess-help@r-project.org> wrote:
>>
>>>
>>> On Tue, May 19 2020, Kevin Wright via wrote:
>>>
>>> > Is there a function to copy an inferior-buffer R command back to the R
>>> > script and insert it at point?
>>>
>>> I'm not sure you get it in a single defun, but you can glue the
>>> following bits together:
>>>
>>> https://ess.r-project.org/Manual/ess.html#Transcript-Mode
>>>
>>> so save your *R* buffer as a file.Rout, and then edit that file and run
>>> ess-transcript-clean-region to remove the output and preserve just the
>>> R commands  you sent.
>>>
>>> Stephen
>>>
>>> __
>>> ESS-help@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/ess-help
>>>
>>
>
> --
> Kevin Wright
>

[[alternative HTML version deleted]]

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help


Re: [ESS] [External] Re: Function to copy command to script?

2020-05-19 Thread Richard M. Heiberger via ESS-help
Hi Kevin,

I think Stephen is assuming you do a lot of work in the *R* and then want
to recover it into a script.
For that case I wouldn't bother saving the *R* buffer, but would just copy
the relevant lines (including output)
and then save it back into the script file with C-u C-u C-y
(ess-yank-cleaned-commands).
The C-u C-u C-y strips out the prompts and output and pastes just the input
commands.

For the way I read your email, you are looking to copy just a single line
from *R* to something.r.
For that I would just highlight it, then copy and paste.

Rich

On Tue, May 19, 2020 at 12:14 PM Stephen Eglen via ESS-help <
ess-help@r-project.org> wrote:

>
> On Tue, May 19 2020, Kevin Wright via wrote:
>
> > Is there a function to copy an inferior-buffer R command back to the R
> > script and insert it at point?
>
> I'm not sure you get it in a single defun, but you can glue the
> following bits together:
>
> https://ess.r-project.org/Manual/ess.html#Transcript-Mode
>
> so save your *R* buffer as a file.Rout, and then edit that file and run
> ess-transcript-clean-region to remove the output and preserve just the
> R commands  you sent.
>
> Stephen
>
> __
> ESS-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/ess-help
>

[[alternative HTML version deleted]]

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help