Re: How to use math functions in dcompute?
On Tuesday, 18 September 2018 at 01:39:51 UTC, Nicholas Wilson wrote: On Tuesday, 18 September 2018 at 00:25:33 UTC, Sobaya wrote: I'm waiting for the update. How's your progress? I t appears I have broke SPIR-V completely somewhere along the line, I may release a v0.2 with out it, hopefully within the week. I declared like: pragma(LDC_intrinsic, "llvm.nvvm.cos.f32") T cos(T)(T val) if (__traits(isFloating, T)); It also doesn't work.
Re: BetterC + Windows + setjmp longjmp
On Tuesday, 18 September 2018 at 00:24:23 UTC, SrMordred wrote: Yes, i'm using signal(SIGSEGV, sigfn_t func), it catches correctly, but end the execution after. I find the alternatives of setjmp/longjmp and sigaction, but none are avaliable on windows afaik. setjmp/longjmp are available on windows (image loaders using libpng, lua, quake3, and lots of old C code make use of them): https://msdn.microsoft.com/en-us/library/xe7acxfb.aspx?f=255&MSPPError=-2147217396 https://msdn.microsoft.com/en-us/library/3ye15wsy.aspx You can declare the functions in your own code and they should link just fine. It would be helpful if you also submit a PR to add them to DRuntime for Windows. As for sigaction, a quick search suggests it isn't available (and it doesn't show up in MSDN): https://stackoverflow.com/questions/32389905/sigaction-and-porting-linux-code-to-windows
Re: Access to structures defined in C
On Sunday, 10 June 2018 at 17:59:12 UTC, Joe wrote:
That worked but now I have a more convoluted case: a C array of
pointers to int pointers, e.g.,
int **xs[] = {x1, x2, 0};
int *x1[] = {x1a, 0};
int *x2[] = {x2a, x2b, 0};
...
int x2a[] = { 1, 3, 5, 0};
Only the first line is exposed (and without the
initialization). So I tried:
extern(C) __gshared extern int**[1] xs;
After a long hiatus, I'm back to working on something related to
the above, but now that various other C pieces have been
converted to D I'm down to converting these static arrays to D.
There are two arrays that are giving me trouble. The second type
is like that shown above. The first is a simpler array of
pointers to int, e.g.,
int *yp = {2, 4, 0};
int *yq = {10, 12, 0};
int *ys[] = {yp, yq, 0};
In D, I first declared these as
int[] yp = [2, 4];
int[] yq = [10, 12];
__gshared int*[] ys = [ &yp, &yq ];
The compiler (ldc2) gave errors like "cannot take address of
thread-local variable yp at compile time" or "static variable yp
cannot be read at compile time" (when I replaced the "&yp" by
"yp[0]". Eventually, I managed to get them to compile without
errors by using the following:
immutable int[] yp = [2, 4];
immutable int[] yq = [10, 12];
__gshared immutable(int[])[] ys = [ yp, yq ];
I still haven't tested them (or linked them) so I don't know what
other changes I'll have to make to the library (now in D) where
ys is declared as:
__gshared extern int*[] ys;
Presumably changing it to
__gshared extern immutable(int[])[] ys;
should do the trick (everything is still within extern (C))? But
I suspect I'll have to change several array access statements as
well.
However, I've been unable to compile the other case, which now
looks like this:
immutable int x1a[] = [ 9, 7, 5];
immutable(int[])[] x1 = [ x1a ];
immutable(int[])[] x2a = [ 1, 3, 5];
...
immutable(int[])[] x2 = [ x2a, x2b ];
__gshared immutable(int[])[][] xs = [ x1, x2 ];
The error is like "static variable x2a cannot be read at compile
time". It seems like I would have to wrap that immutable(int[])
within another immutable, as
immutable(immutable(int[])[]) x2 ...
and extend that to xs as well.
I'll try it later but I'd like some confirmation or better yet,
pointers to where this is explained in some comprehensible way,
i.e., on what can you apply an address operator or array
subscript and when, is the behavior differerent for immutable,
const, static, thread-local and why?
Re: How to use math functions in dcompute?
On Tuesday, 18 September 2018 at 00:25:33 UTC, Sobaya wrote: I'm waiting for the update. How's your progress? I t appears I have broke SPIR-V completely somewhere along the line, I may release a v0.2 with out it, hopefully within the week.
Re: How to use math functions in dcompute?
On Tuesday, 18 September 2018 at 00:25:33 UTC, Sobaya wrote: On Friday, 7 September 2018 at 10:53:25 UTC, Sobaya wrote: On Friday, 7 September 2018 at 10:17:47 UTC, Nicholas Wilson wrote: On Friday, 7 September 2018 at 06:45:32 UTC, Sobaya wrote: [...] You're missing an "m" in "nvvm", dunno if that will fix it. [...] I'll be adding these to DCompute soon (probably Sunday), LLVM7.0 has just been released and I've been waiting on that to do testing. I understand about the release. But missing "m" is just my typo here. I wrote "llvm.nvvm.cos" correctly on my code, and error occurred. I'm waiting for the update. How's your progress? Still it doesn't work well in my environment. If you know temporary solution for use "cos" or "sin", I want to try it. Thank you. Sorry you need to add a size for the argument "llvm.nvvm.cos.f32" for float or copy what is done in ldc/intrinsics.di with a template for "llvm.nvvm.cos.f#"
Re: BetterC + Windows + setjmp longjmp
On Tuesday, 18 September 2018 at 00:24:23 UTC, SrMordred wrote: On Tuesday, 18 September 2018 at 00:12:35 UTC, Diederik de Groot wrote: On Monday, 17 September 2018 at 23:44:41 UTC, SrMordred wrote: [...] You can use core.stdc.signal nothrow @nogc @system sigfn_t signal(SIGSEGV, sigfn_t func) To catch the signal With a handler signature of: enum void function(int) nothrow @nogc @system SIG_ERR; [...] Yes, i'm using signal(SIGSEGV, sigfn_t func), it catches correctly, but end the execution after. I find the alternatives of setjmp/longjmp and sigaction, but none are avaliable on windows afaik. Aah ok. I think signal() and sigaction() are equivalent. Don't know about setjmp/longjmp not being available on D-windows. They are defined in core.sys.posix, so not directly available on windows per definition. They might be available under mingw. If you think this is an oversight (as they are part of libc in general) and see a definite need, it should not be too hard to add them, i would think. You would have to ask someone with knowledge and access to windows to help you out though (A druntime PR would be welcome).
Re: How to use math functions in dcompute?
On Friday, 7 September 2018 at 10:53:25 UTC, Sobaya wrote: On Friday, 7 September 2018 at 10:17:47 UTC, Nicholas Wilson wrote: On Friday, 7 September 2018 at 06:45:32 UTC, Sobaya wrote: [...] You're missing an "m" in "nvvm", dunno if that will fix it. [...] I'll be adding these to DCompute soon (probably Sunday), LLVM7.0 has just been released and I've been waiting on that to do testing. I understand about the release. But missing "m" is just my typo here. I wrote "llvm.nvvm.cos" correctly on my code, and error occurred. I'm waiting for the update. How's your progress? Still it doesn't work well in my environment. If you know temporary solution for use "cos" or "sin", I want to try it. Thank you.
Re: BetterC + Windows + setjmp longjmp
On Tuesday, 18 September 2018 at 00:12:35 UTC, Diederik de Groot wrote: On Monday, 17 September 2018 at 23:44:41 UTC, SrMordred wrote: [...] You can use core.stdc.signal nothrow @nogc @system sigfn_t signal(SIGSEGV, sigfn_t func) To catch the signal With a handler signature of: enum void function(int) nothrow @nogc @system SIG_ERR; [...] Yes, i'm using signal(SIGSEGV, sigfn_t func), it catches correctly, but end the execution after. I find the alternatives of setjmp/longjmp and sigaction, but none are avaliable on windows afaik.
Re: BetterC + Windows + setjmp longjmp
On Monday, 17 September 2018 at 23:44:41 UTC, SrMordred wrote: Its possible to use setjmp/longjmp on windows? Or, to be straight to my problem: its possible to continue execution after a SIGSEGV(or any other failure/signal) with betterC and windows? You can use core.stdc.signal nothrow @nogc @system sigfn_t signal(SIGSEGV, sigfn_t func) To catch the signal With a handler signature of: enum void function(int) nothrow @nogc @system SIG_ERR; However continuing execution after catching a SIGSEGV is normally considered undefined (at least to POSIX). Quote: According to POSIX, the behavior of a process is undefined after it ignores a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by kill(2) or raise(3). Integer division by zero has undefined result. On some architectures it will generate a SIGFPE signal. (Also dividing the most negative integer by -1 may generate SIGFPE.) Ignoring this signal might lead to an endless loop. From: https://stackoverflow.com/questions/14233464/can-a-c-program-continue-execution-after-a-signal-is-handled#14233912 I am not sure if this is any different on Windows. They handle SIGSEGV differently (ie: as an exception). You would have to read the windows manual, try and test (heavily).
BetterC + Windows + setjmp longjmp
Its possible to use setjmp/longjmp on windows? Or, to be straight to my problem: its possible to continue execution after a SIGSEGV(or any other failure/signal) with betterC and windows?
Re: Is it possible to translate this API's C headers?
On Monday, September 17, 2018 7:43:21 AM MDT Kagamin via Digitalmars-d-learn wrote: > try dpp https://github.com/atilaneves/dpp Since according to Mike's post, it's C++ code, dpp wouldn't help, because it currently only supports C and not C++. - Jonathan M Davis
Re: Manual delegates
On Sunday, 16 September 2018 at 14:45:08 UTC, Vladimir Panteleev wrote: On Sunday, 16 September 2018 at 14:12:27 UTC, Guillaume Piolat wrote: Anyone has any information about the ABI of delegates? In particular how to call them with a particular "this"/frame pointer? To solve a hairy problem I need a delegate with a synthesized frame pointer. https://dpaste.dzfl.pl/cf44417c98f9 The problem is that delegate forwarding seems to require GC closures. I want manually-managed closures. Have a look at the implementation of toDelegate, which does exactly this: https://github.com/dlang/phobos/blob/v2.082.0/std/functional.d#L1463 Thanks. I ended up using toDelegate internally, and enclosing the resulting delegate with code returning a struct with `opCall`. The conclusion is that "struct with `opCall`" is much easier to implement that faking delegate ABI, this is less brittle ; and doesn't add a lifetime of a trampoline context to extend the input delegate.
Re: dealing with very long paths and names
On Friday, 14 September 2018 at 20:52:42 UTC, H. S. Teoh wrote: Whoa. After seeing the insane mess that is the Windows pathname syntax, I'm so glad I code on Linux instead! Yeah, also SIGPIPE, EINTR and "fork should be fast enough".
Re: Is it possible to translate this API's C headers?
try dpp https://github.com/atilaneves/dpp
