On 10/19/22 07:05, data pulverizer wrote:

> I am calling code from a C API, and would like to know how to catch exit
> errors

If you are talking about the exit() Posix function, you can't do anything about that because its purpose is to cause "normal process termination".

Ali

On 10/19/22 09:47, data pulverizer wrote:

> It's okay, I've found a work around.

Do you simply check the return value?

Ali

On Wednesday, 19 October 2022 at 16:48:10 UTC, Ali Çehreli wrote:
> On 10/19/22 07:05, data pulverizer wrote:
>
> > I am calling code from a C API, and would like to know how to
> catch exit
> > errors
>
> If you are talking about the exit() Posix function, you can't do anything about that because its purpose is to cause "normal process termination".
>
> Ali

Yes it is the `exit()` function in the end I figured that it couldn't be sidestepped like an exception so I did something else.

As it happens, the situation turned out to be a bit trivial, not even sure if it's worth going into. But for those interested the description is below.

I'm currently writing a D interop with R, the dynamic statistical programming language. There's a function called `Rf_initEmbeddedR()` which allows you to call the full R C API from D without having to compile a DLL and call code from R. There is also a function called `Rf_endEmbeddedR(int fatal)`, which I assumed terminates the R session, but it doesn't, after seeing the code it only cleans some things up and looks as if it is intended to be used just before you exit main.


I have unit tests in D that begin with the init function and finish with the end function, and when I tried re-initialising I get an exit() error saying the R session was already initialized. So all I did was create a static init flag, and a wrapper function to only call init if the flag is false.

As I said in the end it was trivial.

On Thursday, 20 October 2022 at 09:52:05 UTC, data pulverizer wrote:
> I'm currently writing a D interop with R, the dynamic statistical programming language. There's a function called

How is your project related to EmbedR?

The description of the project could be found here: https://dlang.org/blog/2020/01/27/d-for-data-science-calling-r-from-d/

AFAIK Lance wants to re-write it to the second version with some improvements in the code.

On Thursday, 20 October 2022 at 10:13:41 UTC, Sergey wrote:
> On Thursday, 20 October 2022 at 09:52:05 UTC, data pulverizer wrote:
>> I'm currently writing a D interop with R, the dynamic statistical programming language. There's a function called
>
> How is your project related to EmbedR?
>
> The description of the project could be found here: https://dlang.org/blog/2020/01/27/d-for-data-science-calling-r-from-d/
>
> AFAIK Lance wants to re-write it to the second version with some improvements in the code.

I know about the EmbedR project.

I'm doing a "full-throated" R<->D API aiming to be on the scale of Rcpp (https://cran.r-project.org/web/packages/Rcpp/index.html) all built with native D code, which is more full-featured than EmbedR - which ships with a DLL that some end users will probably not accept and does not have the full capability and convenience of something like Rcpp.

The architecture of my library and my approach is also quite different to EmbedR. I also have structures like

`alias NumericVector = RVector!(SEXPTYPE);`

and so on, which builds in all the D-lang ops, and so on to allow a full interop with the R API. Mine is also private for now till it reaches an acceptable state when I'll think about whether it should be publicly released or jealously guarded. It's a project I'm building for my own use really.

On Thursday, 20 October 2022 at 11:59:45 UTC, data pulverizer wrote:
> [snip]
> Mine is also private for now till it reaches an acceptable state when I'll think about whether it should be publicly released or jealously guarded. It's a project I'm building for my own use really.

It can't hurt to publicly release (when ready) so that other users work through any kinks.