R to table execute failed in Could not parse REXP

I created a workflow in Knime 4.1.3 under Windows7 where it worked fine. I moved to Windows10 recently and installed Knime 4.3.0 and R 3.6.3 and got the connection via Rserve up and running again.

Now I’m stumbling in this workflow on a “R to Table” node which runs in a “Could not parse REXP”. Something which did not happen before the migration to Windows10/Knime 4.3.0.

I found this topic, but there wasn’t a solution found.

In my case the script evaluates okay in the configuration and knime.out is a data.frame.
I added the last line of the script so you can see the contents of the knime.out variable.

When I execute the node the progress bar jumps to 30% after which the error is given.

In the knime.log I found this:

2021-01-22 08:28:20,345 : ERROR : KNIME-Worker-20-R to Table 0:743:0:705 : : Node : R to Table : 0:743:0:705 : Execute failed: Could not parse REXP.
org.knime.r.controller.IRController$RException: Could not parse REXP.
at org.knime.r.controller.RController.importBufferedDataTable(RController.java:765)
at org.knime.r.RSnippetNodeModel.importDataFromR(RSnippetNodeModel.java:320)
at org.knime.r.RSnippetNodeModel.executeSnippet(RSnippetNodeModel.java:223)
at org.knime.r.RSnippetNodeModel.executeSnippet(RSnippetNodeModel.java:180)
at org.knime.r.RSnippetNodeModel.executeInternal(RSnippetNodeModel.java:151)
at org.knime.r.RSnippetNodeModel.execute(RSnippetNodeModel.java:139)
at org.knime.core.node.NodeModel.executeModel(NodeModel.java:576)
at org.knime.core.node.Node.invokeFullyNodeModelExecute(Node.java:1245)
at org.knime.core.node.Node.execute(Node.java:1025)
at org.knime.core.node.workflow.NativeNodeContainer.performExecuteNode(NativeNodeContainer.java:558)
at org.knime.core.node.exec.LocalNodeExecutionJob.mainExecute(LocalNodeExecutionJob.java:95)
at org.knime.core.node.workflow.NodeExecutionJob.internalRun(NodeExecutionJob.java:201)
at org.knime.core.node.workflow.NodeExecutionJob.run(NodeExecutionJob.java:117)
at org.knime.core.util.ThreadUtils$RunnableWithContextImpl.runWithContext(ThreadUtils.java:334)
at org.knime.core.util.ThreadUtils$RunnableWithContext.run(ThreadUtils.java:210)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.knime.core.util.ThreadPool$MyFuture.run(ThreadPool.java:123)
at org.knime.core.util.ThreadPool$Worker.run(ThreadPool.java:246)
Caused by: org.rosuda.REngine.REXPMismatchException: attempt to access org.rosuda.REngine.REXPGenericVector as String
at org.rosuda.REngine.REXP.asStrings(REXP.java:73)
at org.knime.r.controller.RController.importCells(RController.java:851)
at org.knime.r.controller.RController.importBufferedDataTable(RController.java:682)
… 18 more

Any idea why this node worked before, but now runs in an error?

Hi.
In my case it was df$days_count <- work_days_count(…). But in function I typed “return(result[i])” instead of “return(result[[i]])”. It was OK for R data.frame but not OK for KNIME table. Maybe you have similar problem.

Hi @dbolshev,
Thanks for your input! R is less picky on what is allowed. Maybe the data frame which I put in this knime.out is not allowed anymore? As mentioned I used the workflow before in Knime 4.1.3 and there it was all okay.
Maybe it’s the third column in my dataframe which is causing the problems.

I have this “R to Table” node in other places in my workflow and there are “model” and/or “Month” returned without problems.
My bet: this “signal” column is the most likely cause. It is a list.

Let’s see what the Knime-experts think of it.

Edit: I removed this signal column in the knime.out and now the node finishes normally. So it’s the list in a data.frame which is triggering this error.

1 Like

I glad to help you. I also think that problem is in R list. KNIME doesn’t process it correctly.

1 Like

A simple list does work.
Created this basic workflow, which does run normally:

The column in which does fail is a bit more complex list:
afbeelding

@ipazin: do you have an idea why this data.frame can’t be translated anymore into a Knime.table?

1 Like

Hello @JanDuo,

sry but not really a KNIME&R Integration user. Sure someone will take a look. If not a problem example workflow with this error will probably help troubleshoot it.

Br,
Ivan

Hi @ipazin

Took some time to construct one, but here it is. The only interesting node is the right one (with the error). The others are simply there to give it ‘input’ (of which nothing is actually used).

This is the workflow. It does require two packages (and their dependencies): tydiverse and fable.

30123.knwf (13.2 KB)

I cannot run this anymore under Windows7 and Knime 4.1.3, because I don’t have that environment anymore. It did work there though.

1 Like

One very brutal way is to convert your values all to string and deal with the list later.

# https://riptutorial.com/r/example/8815/convert-all-columns-of-a-data-frame-to-character-class
df[] <- lapply(df, as.character)

image

2 Likes

Hi @mlauber71
Indeed very brutal :wink:
Since this all came from a workflow in which timeseries are forecasted, I would definitely have to deal with these strings, the dates and the values contained in the signal are pretty meaningless when they are just strings. I hope a proper solution becomes available too.

1 Like

You mentioned this has worked before. Could you share your sample workflow with the older (?) nodes so we might see what type of data would have been returned to KNIME then.

Hi @mlauber71
The node which worked is the one shown at the top. I cannot share this workflow due to confidentiality, but in essence is it the same as in the example: I calculate a model using ARIMA() and forecast() for the prediction. This result is to be converted to this R to Table node to a Knime table.

well maybe you could use the same example as before but with the node that does work. To see what kind of KNIME format would result.

My desktop is migrated, so I cannot replay the old situation. I used the workflow often before this migration. Whether it’s W7 to W10 or Knime 4.1.3 to 4.3.0 or both I can’t say. I haven’t thought on making a copy first…
Somewhere I hope there had been a change in Knime which can explain this. Maybe I have to change my ARIMA forecast component and split this signal column into separate values. It will be a job for monday when I’m back at work.

2 Likes

Hi @mlauber71

I found a workaround using this additional code at the end in my R to Table node.

if (class(knime.out$signal) == "distribution") {
   tmp <- knime.out$signal
   tmp2 <- sapply(tmp, `[[`, 1)
   knime.out$signal <- tmp2
   tmp2 <- sapply(tmp, `[[`, 2)
   knime.out$sigma <- tmp2
}

From something I added in the description of my component I have the impression this signal column contained these two numbers before as well. Somehow the R to Table node just took the first column from the list, which contains the signal.
It’s only circumstancial “evidence”, but as said I cannot replay this old situation anymore.

1 Like

@JanDuo ,

what RServe version are you using with Windows10 and what R and RServe version did you use with your old Windows7 installation.

Hi @Mark_Ortmann,

Under Windows10 I’m using R 3.6.3 and RServe 1.8-7 which is the latest you get when creating it from source. I used RTools 3.5 to compile this RServe.
Initially I created RServe 1.8-6, but that gave these issues in the first place. That’s why I attempted this newer version, but that did not make any difference. I kept this newest version.

Under Windows7 I’m sure about the version of RServe: 1.8-6. I followed the instructions in this post of @mlauber71 which I mentioned earlier in this topic. When I compiled it almost two years ago this 1.8-6 was the newest version.
I’m not 100% certain on the R version (and I cannot check it anymore). This was either 3.6.1 or 3.6.3 as well.
In combination with Knime 4.1.3 it worked great.

Hi @JanDuo -

I can reproduce the problem on my Windows10 machine, using a fresh R 4.0.3 environment and latest compiled RServe. I’ll create a ticket in our system (AP-16131).

Thanks very much for the detailed feedback and bug reporting!

3 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.