Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Josh @ Dreamland

Announcements / Re: k done
« on: July 23, 2012, 11:45:15 am »
That, I am looking into now. Median is the only function correctly identified to take variadic parameters. Due to issues in resolving ::, min, max, and choose are not read correctly. The bug in resolving median as variadic is ENIGMA's fault; I'll look into it after the other three read properly.

Announcements / Re: k done
« on: July 23, 2012, 11:15:17 am »
Bear in mind, cheeseboy, I can very easily apply all the IP bans from the IRC here.

I have not touched sounds. If they don't work anymore, it has nothing to do with the parser. The parser only determines whether or not the sounds are functions. The other problems you are describing sound like an issue identifying locals, which was already fixed.

General ENIGMA / Re: Liberated Pixel Cup beta-entry
« on: July 22, 2012, 06:57:57 am »
Pull requests are fine. Did you make any changes to the compiler, or just to the engine? I ask because ENIGMA is presently divided into two branches from my attempts at installing the new C parser, and the other branch could make it very difficult to auto-merge compiler changes, while only a little of the engine was changed.

Also, we sometimes go by "ENIGMA Development Environment."

Announcements / Re: k done
« on: July 21, 2012, 10:15:44 pm »
You make a great point, but let me offer this as a rebuttal: I'm lazy. I have higher priorities.

(Note from Ism: ftfy)

Announcements / k done
« on: July 21, 2012, 07:39:57 pm »
After some grueling moments of agony, I have the new system working—as far as I can tell—on Linux. TGMG is testing it for Mac, and then I guess I'll make it work on Windows and merge it in to the main branch.

I'm more concerned about Mac because, number one, its headers are older and very different, and number two, TGMG has a massive testing platform running on it which we can use for automated regression testing.

In other news, I fixed depth, too.

Proposals / Re: question: how to make an EXE?
« on: July 19, 2012, 10:23:35 pm »
The option that is supposed to work is "Compile." If it doesn't work, it's because IsmAvatar still doesn't add .exe to the end of the output name, but GCC does. You can fix that by adding .exe yourself.

I will add a Compile button with icon to the UI when I start doing Java dev.

General ENIGMA / Re: Liberated Pixel Cup beta-entry
« on: July 19, 2012, 10:19:51 pm »
Indeed, the game looks great. I was saving my comments for after I was able to run it, which I hope to be soon, but rest assured that the game looks great.

Oh, and as I mentioned, I would be happy to pull your changes. Though I must say, your use of the sprite max ID is concerning, as sprite IDs can become fragmented (hence the need for sprite_exists).

Issues Help Desk / Re: ENIGMA Shell crashes on Win 7 64-bit
« on: July 19, 2012, 12:06:28 am »
For future reference of anyone else affected by this sort of issue:

Aergis was having trouble with the Radeon card described above while playing Skyrim, and so installed a third-party driver set to patch the issue. This patch knocked out all GL-based applications, including Blender and ENIGMA.

I encouraged Aergis to install the latest version of AMD's driver for the card, as it will likely fix both issues.

If you have this problem and have not tinkered with your graphics, post a new thread.

Issues Help Desk / Re: ENIGMA Shell crashes on Win 7 64-bit
« on: July 18, 2012, 10:24:01 pm »
Okay, from your specs, you should have absolutely everything you need to run ENIGMA successfully.

Anyway, GDB is the GNU debugger. It's proficient at finding the point at which programs die. Unfortunately, you have to know a few commands to be able to do it.

I'll try to give the step-by-step, but it'd be easier to walk you through over IRC.

  • First, download this version of Verlet, compiled with debugging symbols: You can technically build your own by selecting Debug from the ENIGMA menu and copying the executable out of the temporary files.
  • Next, open an msys bash shell. There should be a program under C:\MinGW\MSys\1.0\bin\ called "bash.exe" or similar. You may need to open it from a terminal.
  • Once the bash shell is open, input [snip]gdb "Verlet (Debug).exe"[/snip] and press Enter. You may need to replace "Verlet (Debug).exe" with the full path to the program. A line starting with (gdb) should display.
  • Type [snip]run[/snip] and press enter. The program should attempt to start.
  • From there, GDB will print the error that occurred, probably SIGSEGV (segmentation fault). If it does, type [snip]backtrace[/snip], or "bt" for short.
  • GDB should then output a list of functions on the call stack before the program exploded. Copy the contents of the terminal, and paste them to us (either here or on Pastebin.

If you have trouble copying text from the terminal, try right clicking the title bar and going to Edit->Select All/Copy.

Issues Help Desk / Re: ENIGMA Shell crashes on Win 7 64-bit
« on: July 18, 2012, 09:59:19 pm »
You are running Windows 7, 64bit, I presume? Is there anything notable about your Windows environment? Also, it might help if we knew what graphics card you used, and possibly some info from running dxdiag. Basically, computer specs might help.

Better yet, it would help if you could run a debug version of the program through GDB for us, so we have an idea of what is failing. Have you ever used GDB before?

Announcements / Re: wtf am I doing
« on: July 18, 2012, 12:55:21 am »
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.

Announcements / Re: wtf am I doing
« on: July 17, 2012, 10:52:39 pm »
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).


Announcements / Re: wtf am I doing
« on: July 17, 2012, 01:56:13 pm »
As of now, I have committed my changes to a new branch,

Code: [Select]
git clone -b enigma-jdi 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.

Announcements / Re: wtf am I doing
« on: July 16, 2012, 11:35:51 pm »
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.

Announcements / wtf am I doing
« on: July 15, 2012, 11:34:53 pm »
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.