R help - Sep 2022 - Error Running arules

Hi Ivan,


Thanks for the response.

I added the line to the top of my script:
traceback()

I ran my script with my arules code today. Now, there are no errors. I 
am now getting the expected output from my install, the same output as 
the arules package maintainer is getting per his email to me on his 
findings.

I looked over my notes from the past few days. I did get a kernel update 
from my distribution repository after posting to the help list. I have 
not had the time over the weekend to run the arules script again to 
determine if things are working as expected. I also wanted to take the 
time and think about the problem from a distance to gain perspective.

I can only conclude at this point the kernel used when running the code 
last week was not compatible with r-base 4.2.

I will be grateful for the little things in life being resolved without 
the pain of doing a rinse-and-repeat exercise of uninstalling and 
installing R.


Kindest Regards,
*Stephen Dawson, DSL*
/Executive Strategy Consultant/
Business & Technology
+1 (865) 804-3454
http://www.shdawson.com


On 9/6/22 13:15, Ivan Krylov wrote:
> On Sun, 4 Sep 2022 12:14:23 -0400
> "Stephen H. Dawson, DSL via R-help" <r-help at
r-project.org> wrote:
>
>> The problem he estimates is a version mismatch within my R packages,
>> although all packages I am using come from R repositories.
>> Specifically, something is off on the r-base version I am running.
> Could you provide a small example (including a small, anonymised
> version of ./input/DataSet.csv) that would reproduce the problem? In my
> opinion, there's debugging to be done, but that's relatively
> complicated. I would start with options(error = recover), browse the
> variables at the point of the crash (who's calling eval()? what's
the
> expression being evaluated? what's in the environment?) and try to
> figure out why the expectations of the expression aren't met by the
> environment.
>
> What's suspicious is that I can't find any mention of a variable
named
> "Insert" or a piece of code saying eval(ei, envir) in the code of
the
> "arules" package, and it doesn't have any non-core or
recommended hard
> dependencies except "generics". The reason I asked for a
traceback() is
> to clarify where exactly the error happens and perhaps uncover a reason
> for the failure through that.
>

On Tue, 6 Sep 2022 15:47:20 -0400
"Stephen H. Dawson, DSL" <service at shdawson.com> wrote:
> I added the line to the top of my script:
> traceback()
The best way to use traceback() is to run it immediately after getting
an error:

f <- function() g()
g <- function() h()
h <- function() stop("I'm causing an error")
f()
# Error in h() : I'm causing an error
traceback()
# 4: stop("I'm causing an error") at #1
# 3: h() at #1
# 2: g() at #1
# 1: f()

Depending on how you run scripts, placing a traceback() right after the
line that crashes may be not enough: R stops the whole execution
process, requiring you to type traceback() manually. Alternatively,
options(error = traceback) will run it for you every time an unhandled
error happens, including interrupts (which is annoying).

options(error = recover) will let you interactively inspect the values
of the variables at the time of the crash. Using dump.frames (see its
help page) will save the variables into file or global variable to
inspect them later. I haven't seen them shared on the mailing list (too
large?), but it could be an option. options(error = NULL) restores the
default behaviour.

When debugging is unavoidable, R Inferno
<https://www.burns-stat.com/documents/books/the-r-inferno/> is one of
good resources on how to do it with R code.
> I ran my script with my arules code today. Now, there are no errors.
Congratulations on having it solve itself! Let's hope the error won't
return.

-- 
Best regards,
Ivan