www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Catching C errors

reply data pulverizer <data.pulverizer gmail.com> writes:
Hi all,

I am calling code from a C API, and would like to know how to 
catch exit errors so that they can be handled and make them more 
like an exceptions so that the computation can continue. I've 
tried something similar to what is outlined here: 
https://dlang.org/phobos/object.html#.Error but it doesn't work, 
the process dies in the try block.

Thanks
Oct 19 2022
next sibling parent reply data pulverizer <data.pulverizer gmail.com> writes:
On Wednesday, 19 October 2022 at 14:05:35 UTC, data pulverizer 
wrote:

 Hi all,

 I am calling code from a C API, and would like to know how to 
 catch exit errors so that they can be handled and make them 
 more like an exceptions so that the computation can continue. 
 I've tried something similar to what is outlined here: 
 https://dlang.org/phobos/object.html#.Error but it doesn't 
 work, the process dies in the try block.

 Thanks


It's okay, I've found a work around.
Oct 19 2022
next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Oct 19 2022
prev sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Wednesday, 19 October 2022 at 16:47:49 UTC, data pulverizer 
wrote:

 On Wednesday, 19 October 2022 at 14:05:35 UTC, data pulverizer 
 wrote:

 Hi all,

 I am calling code from a C API, and would like to know how to 
 catch exit errors so that they can be handled and make them 
 more like an exceptions so that the computation can continue. 
 I've tried something similar to what is outlined here: 
 https://dlang.org/phobos/object.html#.Error but it doesn't 
 work, the process dies in the try block.

 Thanks


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


Always good to share what it is, for future readers who have the 
same question
Oct 19 2022
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Oct 19 2022
parent reply data pulverizer <data.pulverizer gmail.com> writes:
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.
Oct 20 2022
parent reply Sergey <kornburn yandex.ru> writes:
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.
Oct 20 2022
next sibling parent reply data pulverizer <data.pulverizer gmail.com> writes:
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.
Oct 20 2022
parent reply jmh530 <john.michael.hall gmail.com> writes:
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.
Oct 20 2022
parent data pulverizer <data.pulverizer gmail.com> writes:
On Thursday, 20 October 2022 at 12:14:38 UTC, jmh530 wrote:

 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.


Those are good points. I'll give it some thought when the time 
comes. Thanks!
Oct 20 2022
prev sibling parent reply bachmeier <no spam.net> writes:
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've done an initial release of the second version:

https://github.com/bachmeil/embedrv2

The two biggest changes are

- Moving to Dub as the default for compilation, which allows the 
use of any other Dub libraries
- It writes the wrappers for you. You write a D function and it 
converts it to R.

The part I haven't finished is in the other direction. For 
instance, suppose you have a D function that sends data to R many 
times. If you don't release the memory on the R side, your 
program's going to crash quickly. I haven't worked on this 
recently because I've mostly been calling D functions from R.
Oct 20 2022
parent data pulverizer <data.pulverizer gmail.com> writes:
On Thursday, 20 October 2022 at 13:02:52 UTC, bachmeier wrote:

 I've done an initial release of the second version:

 https://github.com/bachmeil/embedrv2

 The two biggest changes are

 - Moving to Dub as the default for compilation, which allows 
 the use of any other Dub libraries
 - It writes the wrappers for you. You write a D function and it 
 converts it to R.

 The part I haven't finished is in the other direction. For 
 instance, suppose you have a D function that sends data to R 
 many times. If you don't release the memory on the R side, your 
 program's going to crash quickly. I haven't worked on this 
 recently because I've mostly been calling D functions from R.


Haven't see this update, good to know!
Oct 20 2022