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 »
1201
Announcements / Re: New LGM Backend Map/List
« on: November 21, 2011, 08:43:34 am »
Glad to hear you have that done, Ism.
Fede:
Depends how you make the array.
string array[10000]; // Yes
var array; array[10000] = 0; // No
Fede:
Depends how you make the array.
string array[10000]; // Yes
var array; array[10000] = 0; // No
1202
General ENIGMA / Re: Makefile is fucked
« on: November 09, 2011, 11:18:04 pm »
There wouldn't be that many results for his name.
1203
General ENIGMA / Re: Makefile is fucked
« on: November 08, 2011, 08:59:47 pm »
Ism's bug memory is roughly zero.
1204
General ENIGMA / Re: What's the status of this project?
« on: November 08, 2011, 09:35:42 am »
Actually, 39DLL would go in ENIGMAsystem/SHELL/Network_Systems, along with Ism's EnigmaSockets thing. We haven't added it because it's not... satisfactory. An MPlay port will also go in there.
So yes, 3D was "implemented" by Zach and does not work at all. Particles haven't been started. Surfaces should work; HaRRi's tested them on Windows, but not since my update, and I've not tested them at all. Pathfinding is done. You can't create paths in the editor yet, but you can generate them using GM's pathfinding functions.
A list of all available functions can be found in LGM under Enigma->Keywords.
A large, semi-maintained list of things that need done: http://enigma-dev.org/docs/Wiki/ENIGMA:Todo
A list of things we're not doing: http://enigma-dev.org/docs/Wiki/Discarded_behaviors
If you're on Mac, you should see an android option under the compilers in Enigma Settings.
So yes, 3D was "implemented" by Zach and does not work at all. Particles haven't been started. Surfaces should work; HaRRi's tested them on Windows, but not since my update, and I've not tested them at all. Pathfinding is done. You can't create paths in the editor yet, but you can generate them using GM's pathfinding functions.
A list of all available functions can be found in LGM under Enigma->Keywords.
A large, semi-maintained list of things that need done: http://enigma-dev.org/docs/Wiki/ENIGMA:Todo
A list of things we're not doing: http://enigma-dev.org/docs/Wiki/Discarded_behaviors
If you're on Mac, you should see an android option under the compilers in Enigma Settings.
1205
Proposals / Re: EDL V.Next
« on: November 08, 2011, 09:19:52 am »
Good question.
Also, which part is Stockholm Syndrome? I just see it as business strategy; any more I'm just trying to assemble an engine, and GML is along for the ride.
Also, which part is Stockholm Syndrome? I just see it as business strategy; any more I'm just trying to assemble an engine, and GML is along for the ride.
1206
Proposals / Re: EDL V.Next
« on: November 08, 2011, 09:06:04 am »
EDL allows flopping between real and string, as in GML. It also allows flopping between ds_stack and ds_list, etc, because all of them are represented by integers. If this ever ceased to be the case...
If I really wanted, I could implement a highly unsafe integer conversion for all C++ containers and user structures, but that'd end up being pointless. Even with the ability to integerize complicated data structures on a whim, calling a generic method like erase() or length() or size() on one of them would be impossible to syntax check without some sort of type tracing that would involve going out of scope. Way out of scope. Like, the entire game, every time I need to make sure that call applies.
GM's typing is only dynamic because it doesn't offer a way of storing anything locally. Dynamic typing between all native classes has never been a plan in ENIGMA--Its availability in JavaScript is a side effect that will ultimately not be supported except in native scripts.
Perhaps in the future I will look into standardizing containers for EDL and at that point will look into making sure they all have those methods available to prevent compile errors. Still, the efficiency of the operation would bother me. I'm basically content to keep segregating functions like ds_blah from blah<blahblah> until users develop the ability to type things manually.
If I really wanted, I could implement a highly unsafe integer conversion for all C++ containers and user structures, but that'd end up being pointless. Even with the ability to integerize complicated data structures on a whim, calling a generic method like erase() or length() or size() on one of them would be impossible to syntax check without some sort of type tracing that would involve going out of scope. Way out of scope. Like, the entire game, every time I need to make sure that call applies.
GM's typing is only dynamic because it doesn't offer a way of storing anything locally. Dynamic typing between all native classes has never been a plan in ENIGMA--Its availability in JavaScript is a side effect that will ultimately not be supported except in native scripts.
Perhaps in the future I will look into standardizing containers for EDL and at that point will look into making sure they all have those methods available to prevent compile errors. Still, the efficiency of the operation would bother me. I'm basically content to keep segregating functions like ds_blah from blah<blahblah> until users develop the ability to type things manually.
1207
Proposals / Re: EDL V.Next
« on: November 07, 2011, 09:49:23 pm »
Nah, I'm just insane.
...Okay, maybe the volumes of school shit I have to deal with are getting to me.
Anyway, I'll probably end up adding those things to ENIGMA in hell, but until then, I'm going to pass on them. I might allow the C++ auto keyword, but I don't want to ambiguate var--in GML, and in JavaScript, var can change types dynamically. I don't want people to think they can flop from map to list on a whim.
Anyway, the compiler can currently identify C++ terms just fine. The issue is in type resolution with those. My C parser's argument type tracking isn't there, and its template resolution is abysmal.
...Okay, maybe the volumes of school shit I have to deal with are getting to me.
Anyway, I'll probably end up adding those things to ENIGMA in hell, but until then, I'm going to pass on them. I might allow the C++ auto keyword, but I don't want to ambiguate var--in GML, and in JavaScript, var can change types dynamically. I don't want people to think they can flop from map to list on a whim.
Anyway, the compiler can currently identify C++ terms just fine. The issue is in type resolution with those. My C parser's argument type tracking isn't there, and its template resolution is abysmal.
1208
Proposals / Re: EDL V.Next
« on: November 07, 2011, 05:31:12 pm »
I keep giving this another lookover, but every time I see it, I just think, "Fuck everything about this."
I mean, calling class::something() on a typeless variable? Fuck that. People want compile-time "too many arguments to..." errors. I can't offer that if people can flop entire class types whenever the fuck they want, without any kind of predetermination.
foreign()? __cpp_pod__? ENIGMA_EXPORT? What the shit are these? How about, instead of dropping breadcrumb trails for the compiler, we just say what the fuck we want as we want it? Like with strong types, and by just giving access to scripting in the native language.
I mean, calling class::something() on a typeless variable? Fuck that. People want compile-time "too many arguments to..." errors. I can't offer that if people can flop entire class types whenever the fuck they want, without any kind of predetermination.
foreign()? __cpp_pod__? ENIGMA_EXPORT? What the shit are these? How about, instead of dropping breadcrumb trails for the compiler, we just say what the fuck we want as we want it? Like with strong types, and by just giving access to scripting in the native language.
1209
Announcements / Re: We can't decide
« on: November 07, 2011, 05:09:36 pm »
I suppose. I'd still say we're in a pretty gunky predicament, especially with the need to support old GM formats and new, never-load formats.
1210
Issues Help Desk / Re: svnkit error
« on: November 06, 2011, 12:26:57 am »
But it is recognizing the MinGW installation, yes?
This thread's on the old side; what is the version number of the zip you used? A while back, there was an error-prone copy uploaded. It's possible you've accidentally happened upon it (The zip had an old version of ENIGMA.exe but a new version of the GCC template).
This thread's on the old side; what is the version number of the zip you used? A while back, there was an error-prone copy uploaded. It's possible you've accidentally happened upon it (The zip had an old version of ENIGMA.exe but a new version of the GCC template).
1211
Issues Help Desk / Re: svnkit error
« on: November 05, 2011, 11:15:56 pm »
You are getting the same Java exception? Is this with a fresh ENIGMA install as well, or just re-running the same ENIGMA.exe? If you're just running it again, you may need to delete the config file it attempted to generate under Compilers/Windows/gcc.ey.
1212
Announcements / Re: We can't decide
« on: November 05, 2011, 12:19:32 am »Guess what you can't do in C++, but could do in EDL if Josh wanted to write a better code generator?Code: [Select](a ? foo : bar) = 3
Since when can you not do this in C++? This is part of the "complicated ternary expressions" I was talking about.
1213
Announcements / Re: We can't decide
« on: November 03, 2011, 05:21:03 pm »
We could do without nearly the entirety of LLVM. It'd be an option for users who want neat stuff.
Clang, plus my estimate of its LLVM dependencies, is only about 50, I believe.
Clang, plus my estimate of its LLVM dependencies, is only about 50, I believe.
1214
Announcements / Re: We can't decide
« on: November 03, 2011, 01:54:17 pm »
I'm still personally leaning toward V8 for execute_string. It was just another option worth mentioning. LLVM brings a lot to the table. Too much, really, is the problem.
1215
Announcements / We can't decide
« on: November 03, 2011, 12:46:26 pm »
The ENIGMA project has hit a snag recently. Basically, our collective ideologies have become tangled.
It looks something like this:
.
Ism and I are both sorting issues with our projects. Ism is dealing with Java's ill-equipped generics, trying to structure LGM to be more extensible for future releases. As far as you need to be concerned, this is so we can add our Definitions and Overworld resources, as well as other potential resources down the road.
As for myself, right now I am dealing with a small issue regarding a dynamic type that implements implicit accessors and setters for generic data, which has presented a number of "how should I"s, but in the big picture, my concern is for the progression of ENIGMA's parser.
One point is certain: I need to rewrite or do serious work on the C parser. ENIGMA is presently ill-equipped to make distinctions between the following sample lines:
(id)
(int)
(show_message)
(100001)
This has led to issues in interpreting some GM6 code unless extraneous parentheses are added, which is unacceptable to newcomers, as well as to issues implementing some of C++'s more desirable features, such as complicated ternary expressions. This is because ENIGMA needs information from C.
The purpose of the C++ parser—be it the current one, a rewrite, or Clang—is to provide ENIGMA's EDL parser with information about available types, functions, and other constructs. For example, ENIGMA would not know what var a; meant if the C++ parser couldn't understand var's header, and it would not understand what show_message was if it could not read function definitions. The parser also needs to be able to resolve complicated types for further error checking. Hence, we need some mechanism of parsing C++ sources accurately enough for ENIGMA to produce correct C++ code.
I am faced with two options which I have filtered out as the best.
That said, I am torn between the two options. I need people to say, "50 MB and a potential shitton problems that aren't yours, in exchange for four languages? That sounds worth it to me!" Or to say, "for that price, just write your own."
TL;DR version:
Additional Q/A:
dazappa: Clang is a "frontend to LLVM." So you would use Clang but not LLVM? And what's the final size decision, 1gb or 50mb?
Josh@Dreamland: Well, clang has LLVM dependencies, so I would be cutting LLVM into little pieces and throwing away the ones I don't need. 50MB is the projected size after I throw away the little pieces.
dazappa: Would you rather maintain 50mb of shit that you don't know, or 1mb of shit you do?
Josh@Dreamland: Good question. Ideally, for Clang, the maintenance would just be updating Clang headers, adding any more pieces of LLVM that become necessary, and making sure it compiles as though the configure script had run. Maintaining a megabyte of C++ parser can be just as difficult, if not more so as my responsibility extends beyond making sure it simply compiles.
dazappa: Well, you failed to write the C++ parser happily the first time, so you think you'd be able to do it better the second time? Using clang might save you time if you can get it setup and be able to easily update the headers like you think.
Josh@Dreamland: I do think I'd be able to do better the second time. As you can see, the current version succeeds for the most part, with one warning it throws three times. If I code the second version knowing everything I do from the first, and with all that shit in mind, I should be able to get it to play nice.
dazappa: ...Until you realize you have to rewrite it for a 3rd time.
Josh@Dreamland: I'm going to use a system very similar to the recursive descent scheme Rusky talks about. Basically, it would use the body of the current C parser, which invokes a function to handle the token in the context of each statement. Instead of calling this big mash-up switch statement that makes a hundred if checks, the parser would call one function based on the current context and pass it the token, and that function would deal with it appropriately. This means adding a new type of statement to the list would be pretty easy.
Go to town.
It looks something like this:
.
Ism and I are both sorting issues with our projects. Ism is dealing with Java's ill-equipped generics, trying to structure LGM to be more extensible for future releases. As far as you need to be concerned, this is so we can add our Definitions and Overworld resources, as well as other potential resources down the road.
As for myself, right now I am dealing with a small issue regarding a dynamic type that implements implicit accessors and setters for generic data, which has presented a number of "how should I"s, but in the big picture, my concern is for the progression of ENIGMA's parser.
One point is certain: I need to rewrite or do serious work on the C parser. ENIGMA is presently ill-equipped to make distinctions between the following sample lines:
(id)
(int)
(show_message)
(100001)
This has led to issues in interpreting some GM6 code unless extraneous parentheses are added, which is unacceptable to newcomers, as well as to issues implementing some of C++'s more desirable features, such as complicated ternary expressions. This is because ENIGMA needs information from C.
The purpose of the C++ parser—be it the current one, a rewrite, or Clang—is to provide ENIGMA's EDL parser with information about available types, functions, and other constructs. For example, ENIGMA would not know what var a; meant if the C++ parser couldn't understand var's header, and it would not understand what show_message was if it could not read function definitions. The parser also needs to be able to resolve complicated types for further error checking. Hence, we need some mechanism of parsing C++ sources accurately enough for ENIGMA to produce correct C++ code.
I am faced with two options which I have filtered out as the best.
- Rewrite the C++ parser to support the new ISO and to better support the old.
This will mean partitioning ENIGMA's compiler into two projects—one to parse EDL, and one to work with C++—and maintaining them both. I would choose to split the two so that any other party interested in parsing C++ could potentially join in, though it has proven in the past to be unlikely for this to happen.
The benefits of doing this would include minimalistic size and features tailored specifically to ENIGMA and similar projects, meaning—if I code it right—it could potentially work faster than Clang due to a lack of need to lex and check code inside functions. The resulting project would also be less than a megabyte in size (ENIGMA's current hand-rolled C++ parser is 300 KB of source). - Drop the existing C parser altogether and outsource to Clang.
Clang is an LLVM frontend. Certain members of this forum, I'm sure you're aware, blow lots of smoke about LLVM, but in general we would want to avoid it because it will run users somewhere between half a gigabyte and a complete gigabyte of disk space, and MinGW LD/MSys would still be necessary (which is presently the largest component of ENIGMA).
Clang, and its support for LLVM, would bring unprecedented benefit to the project, but not unwarranted benefit given its size. If ENIGMA was compatible with LLVM, by nature of the huge amount of support for the LLVM project, ENIGMA would be able to use, export to, and interact with a half a dozen other languages, notably JavaScript, Lua, Python, and an interpreter for C++ which, depending on its speed, could mean a native method of doing execute_string(), or could just be something crappy to avoid (we have only just learned of its existence, and I have little faith in the ability of anything to both parse and interpret C++ in a reasonable timeframe). In short, we would be getting not only C++ functions, but Lua and JavaScript functions as well, if desired.
The issue is not only the huge size. Ostensibly, I could invest a few hours each update into isolating the segments of Clang required to simply parse C++ and give me info about it. Therein lies the issue; I am well aware that at this point, Clang sounds like the clear choice, but whether or not I choose Clang, I am left with something to maintain. Getting just libclang, its Clang dependencies, and the necessary headers from the LLVM svn to compile alongside ENIGMA will take work, research, trial, and error, and will cost about 50MB in the SVN. Then any time Clang updates something, I have to try updating my copy without stomping all over the modifications. I can't measure at the moment how messy it will be; only that the process is not streamlined.
That said, I am torn between the two options. I need people to say, "50 MB and a potential shitton problems that aren't yours, in exchange for four languages? That sounds worth it to me!" Or to say, "for that price, just write your own."
TL;DR version:
(1) Custom | (2) Clang |
Tiny (Less than 1MB); fast, pointed runtime | 50 MB; Parses EVERYTHING, though quickly |
Gives precisely the needed information, no more, no less | Gives general information that can likely be used to meet all of ENIGMA's purposes. |
Supports interfacing with other languages (Lua, Python, JavaScript) at the cost of hundreds of megabytes on top of Clang | |
Likely to be sole maintainer, responsible for all aspects including any potential errors. This would be no different from now. At worst, it could mean a second recode in the future, but ideally I would make the code sufficiently extensible to prevent that this time. | Maintenance involves separating Clang from LLVM as cleanly as possible every time an update is made; any parse errors are not the responsibility of the ENIGMA team, and may or may not be dealt with in a timely manner. Potentially, we'd be facing another MinGW fiasco. (See #13297) |
Additional Q/A:
dazappa: Clang is a "frontend to LLVM." So you would use Clang but not LLVM? And what's the final size decision, 1gb or 50mb?
Josh@Dreamland: Well, clang has LLVM dependencies, so I would be cutting LLVM into little pieces and throwing away the ones I don't need. 50MB is the projected size after I throw away the little pieces.
dazappa: Would you rather maintain 50mb of shit that you don't know, or 1mb of shit you do?
Josh@Dreamland: Good question. Ideally, for Clang, the maintenance would just be updating Clang headers, adding any more pieces of LLVM that become necessary, and making sure it compiles as though the configure script had run. Maintaining a megabyte of C++ parser can be just as difficult, if not more so as my responsibility extends beyond making sure it simply compiles.
dazappa: Well, you failed to write the C++ parser happily the first time, so you think you'd be able to do it better the second time? Using clang might save you time if you can get it setup and be able to easily update the headers like you think.
Josh@Dreamland: I do think I'd be able to do better the second time. As you can see, the current version succeeds for the most part, with one warning it throws three times. If I code the second version knowing everything I do from the first, and with all that shit in mind, I should be able to get it to play nice.
dazappa: ...Until you realize you have to rewrite it for a 3rd time.
Josh@Dreamland: I'm going to use a system very similar to the recursive descent scheme Rusky talks about. Basically, it would use the body of the current C parser, which invokes a function to handle the token in the context of each statement. Instead of calling this big mash-up switch statement that makes a hundred if checks, the parser would call one function based on the current context and pass it the token, and that function would deal with it appropriately. This means adding a new type of statement to the list would be pretty easy.
Go to town.
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 »