wtf am I doing

[Josh @ Dreamland]

So I'm tearing up the compiler and installing JDI. In between it and ENIGMA will be a new class called language_adapter, which is basically an interface to let any language capable of reflection be exported by ENIGMA. That includes our friend, JavaScript, so TGMG can merge in whatever changes he's made to EGMJS all official-like.

For the time being, I am setting the understood type of all expressions to "int." I have no idea what this is going to do to the compilation sequence, but you straight GML users probably won't notice (Expression evaluation was not a huge part of general EDL).

Also, :: is dead until further notice, since no one used it and keeping it working would be a pain before I start integrating the heavy features that JDI presently lacks.

Moreover, most ironically, due to a hitch in the otherwise very strong similarity between JDI and the old C parser (API-wise), function pointer calls will still not work until then. But varargs should actually be fixed without me recoding any part of ENIGMA, which is neat.

For those who are interested, the following are notable differences:

• The main definition class no longer contains ENIGMA-tailored utility functions. These include the functions to get parameter count bounds and varargs positions. I have already recoded these at the global scope.
• JDI does not have a default context in which items can be looked up. I have created one locally in ENIGMA for the time being.
• The old parser used a central lookup system; one variable controlled which scope operations were performed in, and another variable controlled which scope :: access was done in (the latter having precedence when non-NULL). JDI does not use any such system.

Stunning compatibilities include the following:

• [snip]if (find_extname(name,0xFFFFFFFF))[/snip] ->[snip]else if ((d = main_context.get_global()->look_up(name)))[/snip]
• [snip]if (ext_retriever_var->flags & EXTFLAG_TYPENAME)[/snip] ->[snip]if (d->flags & jdi::DEF_TYPENAME)[/snip]
• [snip]macitr itm = macros.find(name)[/snip] ->[snip]jdi::macro_iter itm = main_context.get_macros().find(name)[/snip]
• [snip]itm->second.argc != -1[/snip] ->[snip]itm->second->argc != -1[/snip]
• All I had to do to integrate the new macro system was replace a block of shit with two function calls.

When this all blows over, it'll either work magically or fail catastrophically. We shall see which! I'm looking forward to it.

Anyway, I have me my sledgehammer. I think it and I will have a nap, and then we'll be back to work.

[Josh @ Dreamland]

Okay, so I've finished installing the new parser. It's having issues at the moment that I'm trying to diagnose; the ENIGMA engine "parses" "fine" en vitro, but as soon as ENIGMA runs it, it disagrees with glu.h for no apparent reason. So I'm trying to run valgrind on it, and that's going terribly.

Did you know valgrind has a 10,000,000 error cutoff? I didn't know that. I discovered that by—you guessed it—attempting to run Valgrind on the JVM. It turns out that Valgrind detects everything the JVM does as an error, which is really helpful when all I need to know is what ENIGMA is doing when it dies. Try as I might, I can not reproduce the segfault from my C++ testing platform. So I'm going to bed.

Tomorrow, when I'm rested, maybe I'll be able to shed some light on how LGM is calling ENIGMA differently than I am.

[Josh @ Dreamland]

As of now, I have committed my changes to a new branch, https://github.com/enigma-dev/enigma-dev/tree/enigma-jdi.

Code: [Select]

git clone -b enigma-jdi https://github.com/enigma-dev/enigma-dev.git if you really want to see it. It will eventually be merged with master.

So far, it seems to have syntax check errors, making it about as useless as the old one. I will fix those in a few hours following a break.

Then I'll deal with the fact that it can't seem to detect the ds_ functions.

Then it'll undergo a testing phase, and then I'll merge it into the main repository.

Also, just FYI: It won't work on Windows. I'll fix that later, too.

[Josh @ Dreamland]

All of my attempts to reproduce the crash from C++ have failed. Last crash was due to a stack overflow caused by G++ failing to optimize a tail call. I replaced it with a jump, and the change was fixed. This time, the crash is with the syntax checker, which never goes deeper than two function calls. And it's with the simplest code. Performing a syntax check on the code [snip]a[/snip] causes a crash from LateralGM. I can check far more complicated code using the same function from C++ without issue. So what else is at play?

I will continue probing the issue. In the meantime, I may start fixing the remaining errors in JDI as well (none of which, again, result in segmentation fault or even leak memory).



Ciao.

[Josh @ Dreamland]

So I fixed a couple problems that were silly typos on my account, and now I've run into a new one. This one is a genuine heisenbug. You see, upon calling a function, memory is corrupted to the degree that I cannot print the name of the scope I passed as a parameter. The interesting thing is, if I attempt to print the name myself (by hard-casting std::string to char* illegally), it magically works, temporarily. It completes the first cycle without segfault. This one is going to take more brainpower, so I think I'll sleep on it. Figuratively speaking, of course; I feel as though sleeping on ENIGMA right now would be akin to sleeping on a cloud made of red-hot needles covered in thorns and lemon juice.

[luiscubal]

Instead of running ENIGMA through Java, can't you just directly run the commands via command line (thus bypassing Java<->Valgrind interaction nightmares?)
Aside from that, you can always turn on all warning-related flags you can find.

If the file isn't too big, you can do things the classic gdb way. Jump into, Jump Into, Jump Out, etc.