Re: reader macro
Awesome, thank you very much for the links. Converting my AST to Nim AST is not my issue. It is putting that Nim AST into a macro to get it to compile which I'm struggling. I think I follow the basic logic in your compile macro although I haven't tried to sort out with my code. I'll report back when I give it a shot. Thanks again for the links!
reader macro
Is there any equivalent to a reader macro in nim? I wrote an expression parser and evaluator in nim which was very easy to do. To get better performance I thought that since nim has macro's I can leverage that without too much trouble. However, walking the AST of my expression parser to create nim AST (in macros) requires compile time proc's for recursion and so I have a chicken and egg problem that I can't seem to resolve.
Re: Nim calling Lemon parser and SIGSEGV
This problem seems to have been a bug in gcc 8.3.0 (version in debian stable [buster]). Once I tried clang and it worked I installed debian testing on Gnome Boxes and it compiled and ran correctly with gcc 9.2.1.
Re: Nim calling Lemon parser and SIGSEGV
ledigbick reported that it works under Windows with a few .cdecl. additions. The current version of the repo should run if you use Windows. Doesn't fix the segfault on Linux. I have a Windows instance in boxes and I'll set up Nim in it a play around but I'm not certain this will help me figure this out.
Re: Nim calling Lemon parser and SIGSEGV
Yes, nothing jumped out at me as unusual. Reading the generated C code isn't so clear so I could have missed something. On linux when calc_parser is executing state->tree is 0x0 which shouldn't happen (gdb). When it exits it is no longer null but points to invalid memory and hence the segfault. When running under valgrind it does the same in calc_parser (0x0) but when it exits it points to the correct location and the AST is printed and evaluated. The equivalent with a main.c (all that is really Nim here) works as expected.
Re: Nim calling Lemon parser and SIGSEGV
Boy, I haven't been this stumped in a very long time. When run it doesn't seem that the parsers state (PState struct called state) exists for either Nim or C. I've tried a bunch of things and no joy. Anyone on this forum who knows anything about valgrind that could provide any insight as to why the code works when it is evoke and fails when it doesn't? Clearly all my intuition previously was wrong else I'd have this sorted by now. Thanks.
Re: Nim calling Lemon parser and SIGSEGV
`.bycopy.` was originally in the pragma for all the C types. I removed any pragma that didn't seem to help to not obfuscate the issue. The code segfaults in `dump_ast` at the switch statement. The first 32 bits made me think that it was `ntype` a c integer that was the issue but I don't think so now. Lemon produces a header in this case called `calc.h` of token types: #define ADD 1 #define SUB 2 #define MUL 3 #define DIV 4 #define LPAR 5 #define RPAR 6 #define NUM 7 Run which the Makefile evokes `c2nim` to create `calc.nim`: const ADD* = 1 SUB* = 2 MUL* = 3 DIV* = 4 LPAR* = 5 RPAR* = 6 NUM* = 7 Run The reason I don't think this is the issue is that I hard coded the c int's to their actual values in both `calc.y` and `main.nim` and got the same result. Thank you both for your input.
Nim calling Lemon parser and SIGSEGV
I'm trying to call a Lemon based parser from Nim. I think Nim is garbage collecting the parsers state but I can't figure out why that is happening. I've created the simplest example of the issue on [github](https://github.com/drjdn/nim_lemon_calc). More info on the problem and how to run the code are at the link. There is nothing fancy going here as far as I know as it is just Nim calling into C (the AST is all C code etc.). I'm pretty new to Nim so any input would be greatly appreciated.
Re: Wrapped C++ code is leaking memory
Sorry, I saw "match" in your code and assumed it was calling re. I now see you have a real memory leak and not a "still reachable". There isn't anything else in the std. lib that has "still reachable" warnings so I still think it is a bug in the interface (arguable a low priority one). Sorry for the noise.
Re: Wrapped C++ code is leaking memory
I haven't looked too closely at your code but it looks to be using pattern matching which is likely calling re. See #12952. Jason
Re: exportc pragma and ref object
Got it, I was assuming this was going to be less effort on my part, thank you. I was using the --header flag mostly to see how to make the interface. Also, all material I could find on how to call nim from C uses it.
Re: exportc pragma and ref object
So does that mean there is no way to export a recursive type to C++/C? I'm happy to make a bug report if this is considered an issue.
exportc pragma and ref object
When I compile the following code:
import strutils
type
Token {.exportc.} = object
typ: cint
val: cstring
proc exportc(a: Token) {.exportc.} =
let msg = "Token (type, value): ($1, $2)" % [$a.typ, $a.val]
echo msg
Run
with
nim c --header exportc.nim
Run
I get a header file with the following snippet:
typedef struct Token Token;
struct Token {
int typ;
NCSTRING val;
};
N_NOCONV(void, signalHandler)(int sign);
N_NIMCALL(NI, getRefcount)(void* p);
N_NIMCALL(void, exportc)(Token a);
N_CDECL(void, NimMain)(void);
Run
which is what I expect and can then call from a c main function. However, if I
change the object to a ref object
Token {.exportc.} = ref object
typ: cint
val: cstring
Run
I get a header file with the following:
typedef struct tyObject_TokencolonObjectType___My6xn9bSiVikjAjVy7Y8xcA
tyObject_TokencolonObjectType___My6xn9bSiVikjAjVy7Y8xcA;
N_NOCONV(void, signalHandler)(int sign);
N_NIMCALL(NI, getRefcount)(void* p);
N_NIMCALL(void,
exportc)(tyObject_TokencolonObjectType___My6xn9bSiVikjAjVy7Y8xcA* a);
N_CDECL(void, NimMain)(void);
Run
So for a ref object the exportc pragma doesn't stop name mangling which makes
calling from c a pain. Is this a bug or is there something about reference
objects I'm not comprehending.
Thanks,
Jason
