Re: Can we use "ImportC" used yet?
Okay wow, this is amazing, I can now call R's standalone math library `Rmath.h` by converting: ``` //r2d_con.c #define __restrict restrict #define __asm__ asm #define __extension__ #define __inline #define __builtin_bswap16 #define __builtin_bswap32 #define __builtin_bswap64 #define MATHLIB_STANDALONE 1 typedef struct _Float128 {unsigned long long x[2];} _Float128; #include "Rmath.h" #include "R_ext/Random.h" ``` ``` //callr import r2d; import std.random: unpredictableSeed; import std.stdio: writeln; void main() { set_seed(unpredictableSeed(), unpredictableSeed()); writeln("rgamma (2, 3): ", rgamma(2, 3)); } ``` Using: ``` gcc -E -P -I"/usr/share/R/include" -lRmath r2d_con.c > r2d.c dmd callr.d -L-lRmath -L-lm && ./callr ``` Okay it's only the standalone library which is a small part of R, but this rocks. The PAHWAHR! Lol.
Re: Can we use "ImportC" used yet?
On Sunday, 17 October 2021 at 10:46:30 UTC, data pulverizer wrote: Okay wow, this is amazing, I can now call R's standalone math library `Rmath.h` by converting ... Sorry you don't need `-lRmath` so the initial call should be: ``` gcc -E -P -I"/usr/share/R/include" r2d_con.c > r2d.c ```
Re: std.format doesn't want to work
On Sunday, 17 October 2021 at 13:03:46 UTC, jfondren wrote: then it's likely that some memory corruption prior to format() has broken the GC, and format's allocation of a string is what's failing. Try sprinkling `@safe` and and see what it complains about; try valgrind; try reducing your problem. I don't think we can help you more without a way to replicate the fault. I ran Valgrind, and I've noticed some possible leakage in a library I've written, but I'll check for it further once I'll have a bit more time.
Re: Can we use "ImportC" used yet?
On Sunday, 17 October 2021 at 10:46:30 UTC, data pulverizer wrote: Okay wow, this is amazing, I can now call R's standalone math library `Rmath.h` by converting: [...] Yeah it's pretty nice hey ☀️ But will become even more convenient later
Re: std.format doesn't want to work
On Sunday, 17 October 2021 at 05:22:17 UTC, russhy wrote: On Saturday, 16 October 2021 at 22:47:09 UTC, solidstate1991 wrote: When I make this call ``` format(" %3.3f"w, avgFPS); ``` my program immediately crashes with an access violation error. The debugger out is different between x86 and x86-64. I've made all sanity checks, so I need some other suggestions. what is the type of avgFPS? I's a double, but I've tried to pass it as real and float too, with the same exact error being generated.
Re: std.format doesn't want to work
On Sunday, 17 October 2021 at 12:53:07 UTC, solidstate1991 wrote: On Sunday, 17 October 2021 at 05:22:17 UTC, russhy wrote: On Saturday, 16 October 2021 at 22:47:09 UTC, solidstate1991 wrote: When I make this call ``` format(" %3.3f"w, avgFPS); ``` my program immediately crashes with an access violation error. The debugger out is different between x86 and x86-64. I've made all sanity checks, so I need some other suggestions. what is the type of avgFPS? I's a double, but I've tried to pass it as real and float too, with the same exact error being generated. then it's likely that some memory corruption prior to format() has broken the GC, and format's allocation of a string is what's failing. Try sprinkling `@safe` and and see what it complains about; try valgrind; try reducing your problem. I don't think we can help you more without a way to replicate the fault.
Why is opIndexAssign replaced by opSlice here?
Hello Dear community. I'd like to overload `opIndexAssign` for a struct which wraps around a generic array (so that it can't support `opIndex` due to unknown return type). Broken down as much as possible this is the code: ``` import std.stdio : writeln; import std.range : ElementType; struct S { void opIndexAssign(X, RANGE)(X x, RANGE range) if (is(ElementType!RANGE : size_t)) { writeln(__FUNCTION__); } auto opSlice(size_t start, size_t end) { import std.range : iota; return iota(start, end); } } void main() { auto arr = new int[7]; S s; s.opIndexAssign(arr, s.opSlice(1,4)); // works s[0..3] = arr[1..4]; // does not work, compiles to `s.opSlice(0,3) = arr[1..4]` } ``` I'm clueless about why it wouldn't compile the last statement to `s.opIndexAssign(arr[1..4], s.opSlice(0,3))`. Help appreciated :-)
Re: How to do a function pointer to "malloc" and "free"?
On Sunday, 17 October 2021 at 23:07:15 UTC, Elmar wrote: Do you have a link for more information how to initialize the D runtime? Export a function that calls this: http://druntime.dpldocs.info/core.runtime.Runtime.initialize.html And also export a function that calls this: http://druntime.dpldocs.info/core.runtime.Runtime.terminate.html And tell the user to call those when they load/unload the library. (It is pretty common for C libraries to require explicit init/term calls so they should be used to it.) They refcount internally so it is ok to call multiple times, just make sure the init and term are always paired. (btw the druntime actually exports them as extern(C) rt_init/rt_term but I'd still recommend you do your own anyway. if you do have extra work to do you can just do it there, and it can use whatever your lib naming conventions are. and besides im not sure if the extern(C) things are specified stable (even though they have been for as long as i can remember), whereas doing your own thing that `import core.runtime; return Runtime.initalize;` is. )
How can we allow using phobos with asserts/contracts?
On 10/16/21 6:47 PM, solidstate1991 wrote: When I make this call ``` format(" %3.3f"w, avgFPS); ``` my program immediately crashes with an access violation error. The debugger out is different between x86 and x86-64. I've made all sanity checks, so I need some other suggestions. FYI, solidstate figured this out. It was because of an out-of-bounds index on `BitArray`. But that irks me. Why wouldn't `BitArray` do a bounds check? And then I remembered -- Phobos is built in release mode even when your app is not. I literally *cannot* request from the compiler that `BitArray` enforce its contracts without rebuilding the library completely. I never want to build code that doesn't have bounds checks. How can we fix this? -Steve
Re: Why is opIndexAssign replaced by opSlice here?
On Sunday, 17 October 2021 at 22:52:27 UTC, Elmar wrote: Hello Dear community. I'd like to overload `opIndexAssign` for a struct which wraps around a generic array (so that it can't support `opIndex` due to unknown return type). Broken down as much as possible this is the code: ``` import std.stdio : writeln; import std.range : ElementType; struct S { void opIndexAssign(X, RANGE)(X x, RANGE range) if (is(ElementType!RANGE : size_t)) { writeln(__FUNCTION__); } auto opSlice(size_t start, size_t end) { import std.range : iota; return iota(start, end); } } void main() { auto arr = new int[7]; S s; s.opIndexAssign(arr, s.opSlice(1,4)); // works s[0..3] = arr[1..4]; // does not work, compiles to `s.opSlice(0,3) = arr[1..4]` } ``` I'm clueless about why it wouldn't compile the last statement to `s.opIndexAssign(arr[1..4], s.opSlice(0,3))`. Help appreciated :-) What happens here is, the compiler first tries the D2-style rewrite: ```d s.opIndexAssign(arr[1..4], s.opSlice!0(0, 3)) ``` However, that rewrite fails to compile, because your `opSlice` does not take a template argument specifying the dimension along which to slice, as specified in the language spec's section on ["Slice Operator Overloading".][1] Since the above rewrite fails to compile, it falls back to rewriting the expression using D1-style operator overloads: For backward compatibility, `a[]` and `a[i..j]` can also be overloaded by implementing `opSlice()` with no arguments and `opSlice(i, j)` with two arguments, respectively. This only applies for one-dimensional slicing, and dates from when D did not have full support for multidimensional arrays. This usage of opSlice is discouraged. ...which results in the following rewritten statement: ```d s.opSlice(0, 3) = arr[1..4]; ``` My guess is that you got into this situation by trying to follow the example in the spec's section on ["Slice Assignment Operator Overloading"][2]. Unfortunately, that example is incorrect. Here is a fixed version of your example on run.dlang.io: https://run.dlang.io/is/dtfT5y [1]: https://dlang.org/spec/operatoroverloading.html#slice [2]: https://dlang.org/spec/operatoroverloading.html#slice_assignment_operator
Re: Why is opIndexAssign replaced by opSlice here?
On Monday, 18 October 2021 at 03:42:35 UTC, Paul Backus wrote: My guess is that you got into this situation by trying to follow the example in the spec's section on ["Slice Assignment Operator Overloading"][2]. Unfortunately, that example is incorrect. [2]: https://dlang.org/spec/operatoroverloading.html#slice_assignment_operator https://issues.dlang.org/show_bug.cgi?id=22417 https://github.com/dlang/dlang.org/pull/3113
Re: Why is opIndexAssign replaced by opSlice here?
On Monday, 18 October 2021 at 04:11:18 UTC, Paul Backus wrote: On Monday, 18 October 2021 at 03:42:35 UTC, Paul Backus wrote: My guess is that you got into this situation by trying to follow the example in the spec's section on ["Slice Assignment Operator Overloading"][2]. Unfortunately, that example is incorrect. [2]: https://dlang.org/spec/operatoroverloading.html#slice_assignment_operator https://issues.dlang.org/show_bug.cgi?id=22417 https://github.com/dlang/dlang.org/pull/3113 Gold star for fixing broken examples
Re: How to do a function pointer to "malloc" and "free"?
On Sunday, 10 October 2021 at 17:14:30 UTC, Adam Ruppe wrote: On Sunday, 10 October 2021 at 13:52:57 UTC, Elmar wrote: The language subset "BetterC" is required for calling D functions from C though. This is false. You can use any D features when calling it from C, you just need to provide an init and term function that is called from C that runtime initialize and terminate for the full experience. BetterC helper librarys like Tanya or Tango do exist. I don't know tanya, but Tango has absolutely nothing to do with betterC. It is a set of classes that use the full runtime. That's nice! Do you have a link for more information how to initialize the D runtime? I just wondered about that because I thought it actually shouldn't be much more difficult than just linking the runtime into the foreign-language compiled program. I didn't find information on that. Maybe I didn't search long enough.
Re: Why is opIndexAssign replaced by opSlice here?
Btw, I should have written: `s.opIndexAssign(arr[1..4], s.opSlice(0,3));` But it compiles the same way.