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=-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 = [ , ];
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 "" 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
Re: Is it possible to translate this API's C headers?
On Monday, 17 September 2018 at 03:16:33 UTC, spikespaz wrote: There is a project that I wish to use from D (https://ultralig.ht). It's Electron, but with forked WebKit and the samples are very, very fast. This is a great compromise between wanting to have a very custom interface and not wanting to use the slow Electron/Sciter/Awesomium/WebView. I am having trouble porting the C headers though. Firstly, I barely know C at all, especially not enough to do this. The extent of my C knowledge is terminal TicTacToe game I made three years ago. I tried using all of the conversion tools under the "Interfacing with C" page of the wiki, but I'm getting import errors. Probably because the paths are all using "<>", expecting an include path from the compiler. I tried to solve this by refractoring the imports to use relative quoted paths. But even when I fixed that, I kept hitting miscellaneous problems with MSVC, LLVM, and every other dependency under the sun those conversion tools needed. So I figured that Windows was just a crappy ecosystem, and tried it on Linux. No easier. So now I'm here, a C noob, really wanting to use Adam's great project from the D language. The only barrier is my lack of knowledge in C. And I definitely do not have the means to port these headers by hand. Could one of you give me pointers about how to go about this? I have the dynamic link libraries, the static libraries, and the header includes. https://github.com/ultralight-ux/ultralight https://github.com/ultralight-ux/ultralight-0.9-api FYI, those are C++ headers, not C. The page you read will get you part of the way there, but the Interfacing to C++ page would be more relevant: https://dlang.org/spec/cpp_interface.html Of course, if you don't know C++ that will only get you so far. If these were C headers, I'd just go ahead and translate them myself, but C++ headers will require a higher time investment from me because I'm not up to speed on the current state of D's C++ interface. There are people here who are more well informed who might be able to help, but it's going to require more than a few tips in a forum post.
Re: dub doesn't work with dmd 1:2.082.0-1.0?
On Friday, 14 September 2018 at 15:42:05 UTC, Jesse Phillips wrote: On Friday, 14 September 2018 at 05:41:41 UTC, rmc wrote: I do wonder if `dmd` by itself on the command line works. Could it be some sort of 32 bit bug in the latest release of dmd? Relating to argc/argv. "source/dub/compilers/compiler.d(127)" That doesn't look like DMD source code. Yip, that link is to where dub uses dmd (showing the specific error) and the other link is to a line in dmd that throws the initial error. The mars.d file is part of dmd. The line in dmd appears to be a safety check that makes sure there is at least one argument in argv. To me it seems really weird that dmd would be able to reach the trymain function with `argc < 1 || !argv` or with argc >= 1 and one of the arguments being null. R
