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