ENIGMA Development Environment
Website is in read-only mode due to a recent attack.

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 / 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:
  • if (find_extname(name,0xFFFFFFFF)) ->else if ((d = main_context.get_global()->look_up(name)))
  • if (ext_retriever_var->flags & EXTFLAG_TYPENAME) ->if (d->flags & jdi::DEF_TYPENAME)
  • macitr itm = macros.find(name) ->jdi::macro_iter itm = main_context.get_macros().find(name)
  • itm->second.argc != -1 ->itm->second->argc != -1
  • 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.

Announcements / Re: Screw it
« on: July 14, 2012, 09:53:52 AM »
As I said, at present, I'm just replacing the C parser, not the GML parser, until the lion's share of the C++ issues are resolved. Otherwise, we'd just be taking a step sideways.

JDI doesn't have issue with anything C; that includes arrays. So don't worry about that.

Announcements / Screw it
« on: July 13, 2012, 11:22:32 PM »
As I announced on the IRC, I resolved several issues with the parser and now the entirety of the STL will "parse" — "parse," in the sense that the parser successfully makes it from one end of the file to another without crashing, burning, or leaking. On that note, I have decided that the parser will be plugged into ENIGMA "as-is," in an effort to get the system working on new Linux distributions (and apparently on really new Windows systems).

This will begin tomorrow, after I make a few more attempts at correcting the existing errors.

In case you are worried, let me elaborate on the status of the parser. Its C support is flawless—I do not own a C header that it has, in testing, not successfully completed. It is easily capable enough to define all of ENIGMA's functions, types, and globals.

Code: [Select]
> d
Enter the item to define:
>> sin
double sin(double __x);
> d
Enter the item to define:
>> strstr
char *strstr(char *__haystack, const char *__needle);
> d
Enter the item to define:
>> malloc
void *malloc(size_t __size);
> d
Enter the item to define:
>> sprintf
int sprintf(char *__s, const char *__format, ...);
> d
Enter the item to define:
>> fwrite
size_t fwrite(const void *__ptr, size_t __size, size_t __n, FILE *__s);

The parser does NOT have what it takes to give complicated template definitions. It has a good start, but nothing more. Its typename keyword handling is entirely broken because I was foolish enough to believe that I could handle partial specializations inline; I need to lex the shit and handle it at instantiation time. Also, it actually lacks support for overloading  cast operators and operators (), [], new, delete, new[], and delete[]. Those are simple things I might fix before plugging it in.

Code: [Select]
> d
Enter the item to define:
>> std::vector
No `vector' found in scope `std'
> d
Enter the item to define:
>> std::string
typedef basic_string string;
> d
Enter the item to define:
>> std::basic_string
template<typename _CharT, typename _Traits = char_traits, typename _Alloc = allocator> class basic_string;
> d
Enter the item to define:
>> std::map
template<typename _Key, typename _Tp, typename _Compare = less, typename _Alloc = allocator> class map
  value_compare _Alloc;
  typedef value_type _Alloc_value_type;
  value_compare _Compare;
  value_compare _Key;
  value_compare _Tp;
  typedef _Alloc allocator_type;
  typedef _Compare key_compare;
  typedef _Key key_type;
  typedef _Tp mapped_type;
  class value_comparepublic binary_function
  typedef pair value_type;

You may gather that it has no definition for vector, or for string, save that it's a typedef of some basic_string instance; that basic_string is abstract, and that map is missing some three dozen members. This is probably related to the 6600 errors that are thrown as those headers parse. Probably.

Don't fret, though; that's a good thing. When I said "this parser won't break every time a new GCC is released," I said that seriously; not because this parser is perfect, but because this parser can take a beating. A huge beating.

For those who are interested in the actual error count, it was 6625.

The only worry I have right now—the above considered—is its performance on windows, where each console print costs 25 milliseconds. I'll probably have to pass in a custom error handler that doesn't print anything. No biggie, theoretically. I also need to get its file reading mechanism working on Windows.

Damn, I hate Windows.

Announcements / Re: Das Newspost
« on: July 12, 2012, 11:55:39 PM »
Due to a heisenbug, I can't accurately report progress at the moment. I'm either at line 450 or 860. You see, commenting out a line that printed to stdout broke everything, probably due to RVO finally kicking in on the type I removed. Valgrind had nothing to say on the matter, which means I'm probably reading something invalidly, but within the bounds of another allocated block. I'll find it tomorrow, or just let it deal with itself.

Edit: I can't reproduce the strange effects; seems it was more of a Schrödinbug after all, as the solution to the issue on line 450 was the only issue for 200 lines. So that's a nice jump start.

Announcements / Re: Das Newspost
« on: July 12, 2012, 08:34:17 PM »
The C++ parser is called JustDefineIt. I have written its functions in such a way that ENIGMA will be able to reuse them--if one works, both work. ENIGMA will supply a custom lexer to JDI, which will account for missing tokens. For instance, begin and end will be mapped to { and }, <> will be lexed as an operator, and so on and so forth.

Announcements / Re: Das Newspost
« on: July 12, 2012, 03:11:26 PM »
It fixes the C++11 issues. Should be more extensible, too. As part of that, it can tell me the type of an expression much more adeptly, so translating entity.member is much less of a guess. This includes template instantiation, so map<string,int>::operator[] gives the correct type as well.

Announcements / Re: Das Newspost
« on: July 12, 2012, 01:48:00 AM »
Ended up spending most of the day on a backtracking spree. Spent it making sure 22,000 lines of C parsed correctly instead. As for the C++ set above, in actuality, 758 lines (8.8%) parse without serious error, and should parse without any error by tomorrow's end as a result of today's work, but we'll see.

Announcements / Re: Das Newspost
« on: July 11, 2012, 12:04:32 PM »
Watch the console output. If you don't see -Os in it, then you didn't add it in the right place.

I don't recall leaving either system in a state in which disabling components failed. I recall marveling at how disabling the audio system in Windows cuts the size in quarters, and I have not modified that system since.

My biggest concern is getting JDI finished and hooked in. I could practically sing about all the things that will be in my power at that point. One of the first things I will be doing is removing references to instance_event_iterator, replacing it with a parameter that the compiler will insert. This affects the extension system in a big way, though I don't see it affecting the problem you seem to be reporting. I've never had issues enabling or disabling any system.

Announcements / Re: Das Newspost
« on: July 11, 2012, 10:11:28 AM »
I don't know how you find yourself in these messes.
Anyway, most of that five percent was done yesterday, but since that was the beginning of a large change set, that's probably a poor projection.

Announcements / Das Newspost
« on: July 11, 2012, 12:10:16 AM »
I'm beginning to realize I'm keeping you people in the dark about what's going on with my progress, aside from the ticker at the top that shows commits.
People ask me to put a number to things; I can't give a date, but I can tell you that I'm on the last section of my to-do list, as far as I know, and this is how it stands:

I am


done with the last segment of the new parser.

That is



I will update this newspost as that number changes.

2012/07/12 11:18:19 - 566
2012/07/12 03:04:14 - 590

General ENIGMA / Re: Enigma and the Liberated Pixel Cup competition
« on: June 30, 2012, 01:07:26 PM »
I'm worried it might take more than just installing those libraries, if they have a different name than the native equivalents. I'm unsure, though; let me know how that works out.

As for the missing MinGW libraries, I'd completely forgotten about that. I'm glad they're actually offered on Debian; on Windows, I have to include them in an archive. Keep in mind you can add include/linker search directories in the descriptor file; if you find the right directories (and those directories are common between distributions), I'd be happy to pull your changes.

Odds are, if they are not common between distributions, you can use something like pkg-config to get the directories. In that case, you'd just put, eg, cxxflags: `pkg-config --cflags ffi` in the descriptor to allow it to find them.

Issues Help Desk / Re: Simple Transformations
« on: June 29, 2012, 10:21:59 PM »
If I'm not mistaken, that measure's a little imprecise. It wouldn't really matter unless you had something like this:

Taking a distance from corners instead will fix that. You don't need to use the sqrt function, since all you are interested in is proportions.

Issues Help Desk / Re: Simple Transformations
« on: June 29, 2012, 01:55:58 PM »
I was thinking the math would simplify. In my formula,
A*sqrt(sqr(x-x1) + sqr(y-y1)) = B*sqrt(sqr(x-x2) + sqr(y-y2)) = C*sqrt(sqr(x-x3) + sqr(y-y3)) = D*sqrt(sqr(x-x4) + sqr(y-y4))

x1=x4, x2=x3, y1=y2, y3 = y4. So we can rewrite it as this:
sqrt(sqr(x-x1) + sqr(y-y1)) = B*sqrt(sqr(x-x2) + sqr(y-y1)) = C*sqrt(sqr(x-x2) + sqr(y-y3)) = D*sqrt(sqr(x-x1) + sqr(y-y3))

But that's not really making the math any easier; we still have a thousand variables. So, use x1 = y1 = 0, and shift x2 and y3 appropriately (we'll shift the result back later):
sqrt(sqr(x) + sqr(y)) = B*sqrt(sqr(x-W) + sqr(y)) = C*sqrt(sqr(x-W) + sqr(y-H)) = D*sqrt(sqr(x) + sqr(y-H))

Square all terms:
sqr(x) + sqr(y) = B*B*(sqr(x-W) + sqr(y)) = C*C*(sqr(x-W) + sqr(y-H)) = D*D*(sqr(x) + sqr(y-H))

Looking kinder. Now, we treat W as 1 and H as 1. We can transform that later, too.
sqr(x) + sqr(y) = B*B*(sqr(x-1) + sqr(y)) = C*C*(sqr(x-1) + sqr(y-1)) = D*D*(sqr(x) + sqr(y-1))

Multiply everything out:
x*x + y*y = B*B*((x*x - 2*x - 1) + y*y) = C*C*((x*x - 2*x + 1) + (y*y - 2*y + 1)) = D*D*(x*x + (y*y - 2*y + 1))

x*x + y*y = B*B*x*x + B*B*y*y - 2*B*B*x - B*B = C*C*x*x + C*C*y*y - 2*C*C*x - 2*C*C*y + 2*C*C = D*D*x*x + D*D*y*y - 2*D*D*y + D*D

Now subtract x*x and y*y from everything:
0 = (B*B-1)*x*x + (B*B-1)*y*y - 2*B*B*x - B*B
0 = (C*C-1)*x*x + (C*C-1)*y*y - 2*C*C*x - 2*C*C*y + 2*C*C
0 = (D*D-1)*x*x + (D*D-1)*y*y - 2*D*D*y + D*D

I'll revisit those later to figure out how to solve them.

Announcements / Re: Parser Progress
« on: June 29, 2012, 09:12:55 AM »
I feel like I should just ban cheeseshit and be done with it.

Issues Help Desk / Re: Simple Transformations
« on: June 28, 2012, 11:44:19 AM »
Kind of a neat problem. My first thought would be to represent the point in terms of four distances.
A*sqrt(sqr(x-x1) + sqr(y-y1)) = B*sqrt(sqr(x-x2) + sqr(y-y2)) = C*sqrt(sqr(x-x3) + sqr(y-y3)) = D*sqrt(sqr(x-x4) + sqr(y-y4)).

So to get the transformation, you'd use A=1 to solve for B, C, and D, then swap out the x1..x4,y1..y4 pairs and solve back for x,y. That part's a real pain in the ass.