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

Proposals / Re: Named loops vs numbered breaks
« on: September 11, 2012, 02:13:23 pm »
That is what [snip=edl]continue loop;[/snip] would do. Same as [snip=edl]continue 2;[/snip].

Proposals / Re: Named loops vs numbered breaks
« on: September 11, 2012, 07:51:59 am »
That's pretty ugly, and it doesn't match other languages, so newcomers couldn't really guess it.  If we're going to have them learn something new, it should be that the number after break is the total number of loops to exit, not the additional number.

People are really used to named loops, too. We'll let the userbase decide.

Proposals / Re: Named loops vs numbered breaks
« on: September 10, 2012, 11:35:23 pm »
While "both" was originally a joke, I actually think I might do it. My main aversion to it was that it would make goto labels ambiguous, but in the end, (1) do we really want goto, and (2) why can't a loop name also be a label?

It would be simple to just warn on [snip]break 1;[/snip]. Did I mention I'm adding warnings?

Issues Help Desk / Re: Seg Fault once LGM opens ENIGMA
« on: September 10, 2012, 06:42:12 pm »
Did some basic testing. No segfault when reading that engine file on 64 bit, but I notice an increased number of error messages printed—about three times as many as on the 64-bit equivalents of Windows and Linux.

That said, the issue could very well be with the preprocessor. It might be best if you could check out JDI and run the test manually, so we know for sure that the problem is with JDI. If you stop in on the IRC, I'll be happy to walk you through it. Otherwise, hold tight until I can get a 32bit VM at my disposal (I don't have the resources where I am now).

Issues Help Desk / Re: Seg Fault once LGM opens ENIGMA
« on: September 09, 2012, 08:26:04 pm »
Assuming your binaries are all up-to-date, I'm not sure why this would happen. Ubuntu 12.04 is pretty uniform, even five months later. It seems odd to me that it has worked for everyone out of the box on 12.04, but isn't working on yours. To be on the safe side, could you run [snip]gcc -E -DJUST_DEFINE_IT_RUN -I. SHELLmain.cpp -o enigma_engine_segv.cpp[/snip] from ENIGMAsystem/SHELL and upload the generated enigma_engine_segv.cpp somewhere? The segfault seems related to the new parser, but no one else has reported it.

Are you on 32 bit, perhaps? To my knowledge, all of our testers thus far have been on 64. It would help me diagnose the problem better if I knew that.

Proposals / Named loops vs numbered breaks
« on: September 08, 2012, 04:47:37 pm »
Code: (EDL) [Select]
for (int i = 0; i < 10; ++i) {
  for (int j = 0; j < 10; ++j) {
    if (target[i][j])
      break; // FUCK!

Named Loops:
Code: (EDL) [Select]
  for (int j = 0; j < 10; ++j) {
    if (target[i][j])

Numbered breaks:
Code: (EDL) [Select]
for (int i = 0; i < 10; ++i) {
  for (int j = 0; j < 10; ++j) {
    if (target[i][j])
      break 2; // (Y)

Announcements / Re: What needs said
« on: September 03, 2012, 01:55:28 pm »
JavaScript was the very language I had in mind. We already have a JS engine started, and it of course supports execute_string. ;)

Announcements / Re: What needs said
« on: September 02, 2012, 09:07:33 am »
I'm bumping this, because I'm starting to think that people don't view the front page and therefore cannot see this post.
I'll post a new newspost later regarding progress on the operation. Edit: Actually, maybe I'll just post it here.

I have basically completed getting JDI working on the major platforms (Linux, Windows, Mac OS). The parser completes with less than 300 errors on Linux; I can't give a good estimate on Mac/Windows because I am not the one who tests it on those platforms. While 300 errors may seem like a lot, it really isn't a big deal, because JDI easily recovers from them and continues reading definitions. That's a good behavior to have in a parser whose only objective is to inform on the basics.

Right now I am further reducing that error count and finishing up the parts of JDI upon which ENIGMA's new EDL parser will depend. ENIGMA will, in principle, be able to invoke JDI methods to handle a good amount of EDL parsing. This means that I only have one parser to maintain rather than two; if one is right, both are right. It also means that ENIGMA's lexicography will match that of G++, so we shouldn't have any inconsistencies except due to utter negligence.

I'm going to knock off a few more errors and then begin the new parser methods to build ASTs of entire codes. Since the system will operate with JDI as a basis, you will be able to render your code as an SVG to diagnose any misinterpretations (and, of course, to show it off to your friends ;)).

Anyway, I'll report back on how that goes when I'm actually starting the EDL parser. Ciao.

Update: On Linux, I have it down to 215 lines of errors; of those, there are 86 separate errors (problems in the parse process), caused by 21 unique issues with the parser. That last figure, 21, is the number you need to be concerned with. For now, I'm going to leave it, unless correcting the bug that seems to involve the preprocessor is necessary. The preprocessed Windows engine only throws 187 total lines of errors, which means to me that either Windows is much more parser-friendly, or there is a bug with JDI's preprocessor.

Announcements / Re: k done
« on: September 01, 2012, 04:17:09 pm »
... I think she's dead.

Announcements / What needs said
« on: August 08, 2012, 01:21:01 pm »
Okay, I think it's about time to answer the obvious question: Why are you so interested in a new parser?

The C parser needed fixed to get the project working again on Linux, due to changed headers. I decided that it would be a good time to do some re-thinking of the parser system in general.

A lot has changed since the project began, and not just with my views on what ENIGMA should be. I wanted ENIGMA to be free, fast, capable, and cross-platform from the start. In the time since then, Yoyo has set similar goals. They have proven to—as far as commercial organizations go—not be very capable of attaining those goals. However, one of the achievements they have made is getting Game Maker to work on every platform ENIGMA does. In fact, they've gone a step further and made it easy to get GM working on those platforms; presently, ENIGMA takes some finagling. In addition to working on those platforms, GM can export to JavaScript. This changes the rules of the game in itself.

With that turn of events, it is time to take Rusky's advice from two years ago. Well, not all of it. Some of it still makes me want to puke (and he no longer defends it, either). Unfortunately, I went ahead and threw the baby out with the bathwater on that one.

While originally, the plan for ENIGMA was to leave the bulk of interpretation to the host language (ie, C++), doing so has closed the doors to a number of language features.

I have designed JDI in such a way that ENIGMA will be able to reuse the vast majority of its code (in addition to using all of it to being the C++ backend).

What that means is the availability of this feature set:
  •   A unified language and corresponding AST whose backend language does not matter.
    • Ability to export to any language from the backend.
    • Ability to accept definitions from any language capable of reflection (and C++) as the frontend.
  •   Ability to declare getters and setters on certain variables
    • The possibility of adding quad trees to collision systems by placing setters on x and y.
    • The ability to assign a getter for variables such as bbox_left, object_count, etc.
  •   Ability to replace operators with methods
    • No more div/mod class. Simple to cast division operands to double.
    • Simple to implement boolean xor, [snip]^^[/snip].
  •   Ability to determine the type of any expression used in code.
    • Full control of instance or class access through the dot operator.
    • Ability to decide whether or not to cast operands to division (eg, determine whether the class has a division operator overloaded).
    • Ability to regulate the ternary operator to ensure against ambiguity (eg, [snip=edl]var a = string_mode? "" : 0;[/snip]).
  • Ability to resolve overloads of functions
    • Ability to use a more efficient overload for varargs functions.
    • Ability to pass additional arguments to certain functions.
      • Ability to pass information about the current instance and other instance to functions implicitly.
        • Replacement system for the central iterator system, which is founded on globals.
        • Ability to call instance modifying functions from threads.
Maybe you can see how I'm excited about the prospect. If not, questions here.

Announcements / Re: k done
« on: July 28, 2012, 01:34:58 am »
I have JDI compiling and working (zero errors, zero warnings) on Windows with the following headers:

Code: (cpp) [Select]
#include <GL/gl.h>
#include <GL/glu.h>

#include <stdio.h> //printf, NULL
#include <stdlib.h> //malloc
#include <time.h> //clock

#include <stdio.h>
#include <stdlib.h>

#include <errno.h>
#include <float.h>
#include <iso646.h>
#include <math.h>
#include <locale.h>
#include <stdarg.h>
#include <wchar.h>
#include <stdint.h>
#include <string.h>
#include <stdbool.h>
#include <stddef.h>
#include <malloc.h>

#include <stdint.h>
#include <time.h>

#include <fcntl.h>
#include <sys/types.h>
#include <signal.h>
#include <setjmp.h>
#include <inttypes.h>

// Once affected by lack of '?' operator token
#include <ctype.h>
#include <wctype.h>
#include <limits.h>
#include <assert.h>

#include <windows.h>

// Once affected by lack of support for public/private/protected, and by lack of support for constructors.
#include <pthread.h>

#include <sys/stat.h>
#include <sys/time.h>

#include <fenv.h>
#include <tgmath.h>
#include <complex.h>

I'll probably commit what I have shortly, assuming nothing segfaults and dies in ENIGMA (Which I'm already sure that it will).

General ENIGMA / Re: Recodes
« on: July 26, 2012, 08:44:39 pm »
What Ism said.

General ENIGMA / Re: Recodes
« on: July 25, 2012, 04:02:36 pm »
The old parser was designed to bail on the first error. At first, it wasn't a problem, but as C++ continued to evolve and GCC continued to change, it was left unable to read the headers each time they were updated. Maintaining it became a pain in the ass. This new one takes a real beating, and still doesn't give up; plus, it gives us more information about the language, which opens the doors to giving us more tricks.

The number of advantages ENIGMA has over GM have declined since Yoyo started pulling budget out of the air to get code out. We're down to being faster and being free (and they're trying to threaten to get rid of the former advantage). I'm not interested in just being another Game Maker.

ENIGMA keeps getting bigger and better; we haven't launched a formal release because we really don't need one: People can check out the latest at any time. It's practically a release every time we commit. At some point, I will take the latest SVN version, package it up and mark it "stable" and go wave it at people. In the meantime, we'll stick with our Git revisions.

Announcements / Re: k done
« on: July 23, 2012, 07:03:09 pm »
If it broke, it was because the parser was not checking errors correctly at all, because the `variadic' field given to each parameter in memory was not initialized. While it's possible for what seemed like a regression to surface, it's a sharp statistical improbability.

Either way, I've pushed the version that initializes those fields, and sets them correctly.

Announcements / Re: k done
« on: July 23, 2012, 05:32:26 pm »
What I committed didn't break anything. It fixed your problem, revealing the next error it encountered while trying to parse your code.

I will commit the fix to the instance_nearest problem after I finish writing these diagnostic toString methods.