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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »
1036
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.
JDI doesn't have issue with anything C; that includes arrays. So don't worry about that.
1037
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.
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.
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.
http://dl.dropbox.com/u/1052740/enigma/demos/JDI/valgrind-2012-07-14.txt
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.
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.
http://dl.dropbox.com/u/1052740/enigma/demos/JDI/valgrind-2012-07-14.txt
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.
1038
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.
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.
1039
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.
1040
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 [snip]entity.member[/snip] is much less of a guess. This includes template instantiation, so map<string,int>::operator[] gives the correct type as well.
1041
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.
1042
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.
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.
1043
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.
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.
1044
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 [bubble=red]
650/8587
[/bubble] done with the last segment of the new parser.
That is [bubble]
7.57%
[/bubble].
I will update this newspost as that number changes.
Archive:
2012/07/12 11:18:19 - 566
2012/07/12 03:04:14 - 590
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 [bubble=red]
650/8587
[/bubble] done with the last segment of the new parser.
That is [bubble]
7.57%
[/bubble].
I will update this newspost as that number changes.
Archive:
2012/07/12 11:18:19 - 566
2012/07/12 03:04:14 - 590
1045
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, [snip]cxxflags: `pkg-config --cflags ffi`[/snip] in the descriptor to allow it to find them.
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, [snip]cxxflags: `pkg-config --cflags ffi`[/snip] in the descriptor to allow it to find them.
1046
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.
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.
1047
Issues Help Desk / Re: Simple Transformations
« on: June 29, 2012, 01:55:58 pm »
I was thinking the math would simplify. In my formula,
[snip]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))[/snip]
x1=x4, x2=x3, y1=y2, y3 = y4. So we can rewrite it as this:
[snip]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))[/snip]
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):
[snip]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))[/snip]
Square all terms:
[snip]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))[/snip]
Looking kinder. Now, we treat W as 1 and H as 1. We can transform that later, too.
[snip]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))[/snip]
Multiply everything out:
[snip]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))[/snip]
More:
[snip]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[/snip]
Now subtract x*x and y*y from everything:
[snip]0 = (B*B-1)*x*x + (B*B-1)*y*y - 2*B*B*x - B*B[/snip]
[snip]0 = (C*C-1)*x*x + (C*C-1)*y*y - 2*C*C*x - 2*C*C*y + 2*C*C[/snip]
[snip]0 = (D*D-1)*x*x + (D*D-1)*y*y - 2*D*D*y + D*D[/snip]
I'll revisit those later to figure out how to solve them.
[snip]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))[/snip]
x1=x4, x2=x3, y1=y2, y3 = y4. So we can rewrite it as this:
[snip]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))[/snip]
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):
[snip]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))[/snip]
Square all terms:
[snip]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))[/snip]
Looking kinder. Now, we treat W as 1 and H as 1. We can transform that later, too.
[snip]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))[/snip]
Multiply everything out:
[snip]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))[/snip]
More:
[snip]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[/snip]
Now subtract x*x and y*y from everything:
[snip]0 = (B*B-1)*x*x + (B*B-1)*y*y - 2*B*B*x - B*B[/snip]
[snip]0 = (C*C-1)*x*x + (C*C-1)*y*y - 2*C*C*x - 2*C*C*y + 2*C*C[/snip]
[snip]0 = (D*D-1)*x*x + (D*D-1)*y*y - 2*D*D*y + D*D[/snip]
I'll revisit those later to figure out how to solve them.
1048
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.
1049
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.
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.
1050
General ENIGMA / Re: Enigma and the Liberated Pixel Cup competition
« on: June 28, 2012, 10:20:15 am »
I believe RetroX wrote up a compiler descriptor for MinGW; you could try to apt-get install mingw and use it. I've never personally tested it. To switch to it, open ENIGMA settings and switch to the API tab. Select it under "Compiler."
There is a 32-bit gcc descriptor file which should work fine. If not, all you need to do is add -m32 to the parameters in the existing Compilers/Linux/gcc.ey.
There is a 32-bit gcc descriptor file which should work fine. If not, all you need to do is add -m32 to the parameters in the existing Compilers/Linux/gcc.ey.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »