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 »
1336
Off-Topic / Re: Will somebody please kill that damn protected keyword!?
« on: June 30, 2011, 07:28:49 pm »
Someone hates regular expressions?
1337
Issues Help Desk / Re: enigma can't find 'make'
« on: June 28, 2011, 05:47:19 pm »
I'll look into that issue; maybe I can reproduce it myself. It seems it's just being obstinate. Give me a bit; I'm working on something else at the moment.
1338
Issues Help Desk / Re: enigma can't find 'make'
« on: June 28, 2011, 12:08:09 pm »
Interesting. It seems it's finding another make somewhere on your computer. Have you (or anyone else who may use your computer) ever used a console development kit such as DevKitPro? Unless I miss my guess, some program in your PATH makes use of some version of Make, but LGM seems unable to use it.
As you can see, the Path: ENIGMA generated is empty, meaning it didn't need to check a specific path to find Make. So it's most likely in your path.
Now, if you did let ENIGMA install its own MinGW, but it still failed, we have a real issue; in that case, Path should have been set to C:\MinGW\bin, where it was installed.
As you can see, the Path: ENIGMA generated is empty, meaning it didn't need to check a specific path to find Make. So it's most likely in your path.
Now, if you did let ENIGMA install its own MinGW, but it still failed, we have a real issue; in that case, Path should have been set to C:\MinGW\bin, where it was installed.
1339
Issues Help Desk / Re: enigma can't find 'make'
« on: June 28, 2011, 10:04:58 am »
That's interesting; if ENIGMA.exe reported a find, it should be working. However, if you say it found it, but has not installed it, that may be an issue of its own.
Did you already have an installation of MinGW before running ENIGMA?
At any rate, please paste the contents of Compilers/Windows/gcc.ey either here or on pastebin. Unfortunately, IsmAvatar doesn't catch that exception and report useful information.
If I'm correct, it's opened the descriptor successfully, but cannot run the make it describes... I'll talk to her about how she runs those. You may need to edit that file manually, or delete it as well as your current installation of MinGW and let ENIGMA reinstall it from scratch.
Did you already have an installation of MinGW before running ENIGMA?
At any rate, please paste the contents of Compilers/Windows/gcc.ey either here or on pastebin. Unfortunately, IsmAvatar doesn't catch that exception and report useful information.
If I'm correct, it's opened the descriptor successfully, but cannot run the make it describes... I'll talk to her about how she runs those. You may need to edit that file manually, or delete it as well as your current installation of MinGW and let ENIGMA reinstall it from scratch.
1340
General ENIGMA / Re: Game Maker and LLVM
« on: June 21, 2011, 09:17:01 am »
Fede, read the first letter of every paragraph.
1341
Off-Topic / Re: jailbreak download
« on: June 20, 2011, 11:17:32 pm »
I have no idea the legitimacy of this download; have you had success with it and ENIGMA?
1343
General ENIGMA / Re: Game Maker and LLVM
« on: June 20, 2011, 11:15:07 am »
The first question I have for you is, how does them actually freeing memory they aren't using jeopardize my chance of using less? I don't keep a great lot of memory allocated that I won't need--some systems keep bits of memory allocated at all times, yes, like the sound system, but since any sound can be played at any time, so freeing them for no reason would be silly. Other than that, there's not a whole lot I can free. Unless you're suggesting I unload resources after a while of not being used, then just load them in again when they are. ENIGMA could use to change the delivery mechanism of rooms such that they aren't kept loaded, but they're relatively low-impact.
Hell, I doubt they will be able to type-trace even object event codes--instance_change() could make an object using myVar as a double into one using it as a string. Then what? LLVM's garbage collection run would be ruined!!
Eh, I fear I don't follow your third paragraph; could you rephrase to sound less like Sandy and Co.?
Great, I don't understand a bunch of your paragraphs; they look as though LLVM took its built-in switch()-powered garbage collector to them. I'll do my best to generate a response, but I fear the worst.
Architecture issues don't concern me, really; that's why ENIGMA has some 600 different APIs in it and uses fifty different compilers. I trust native compilation on one platform to work well on other computers running that same platform. I don't imagine argument[N] is needed for execute_string(), since it is without script.
Meh, I don't really care about Haskell at this point. I'm more concerned about C++, GML, and now, JavaScript. I really doubt GM will ever build large, gnarly projects well, though; their setup is rather limited and it seems the best they can do is outsource to the magical garbage collecting and code crawling powers of LLVM.
Enough of that, though; I guess we'll just have to wait and see what happens to both projects as they go their separate ways. But I won't include two copies of V8.
Hell, I doubt they will be able to type-trace even object event codes--instance_change() could make an object using myVar as a double into one using it as a string. Then what? LLVM's garbage collection run would be ruined!!
Eh, I fear I don't follow your third paragraph; could you rephrase to sound less like Sandy and Co.?
Great, I don't understand a bunch of your paragraphs; they look as though LLVM took its built-in switch()-powered garbage collector to them. I'll do my best to generate a response, but I fear the worst.
Architecture issues don't concern me, really; that's why ENIGMA has some 600 different APIs in it and uses fifty different compilers. I trust native compilation on one platform to work well on other computers running that same platform. I don't imagine argument[N] is needed for execute_string(), since it is without script.
Meh, I don't really care about Haskell at this point. I'm more concerned about C++, GML, and now, JavaScript. I really doubt GM will ever build large, gnarly projects well, though; their setup is rather limited and it seems the best they can do is outsource to the magical garbage collecting and code crawling powers of LLVM.
Enough of that, though; I guess we'll just have to wait and see what happens to both projects as they go their separate ways. But I won't include two copies of V8.
1344
General ENIGMA / Re: Game Maker and LLVM
« on: June 20, 2011, 09:46:03 am »
What do you mean, replacing it wouldn't be a step? I thought we needed the base to be LLVM'd into a lovely, garbage collected heap of nonsense before we could link more dynamic code against it. Either way, though, I hate garbage collection, so I'd probably never do it. I don't even see why GML needs a garbage collector; it doesn't do anything very messy, and there's no way to tell if you have a reference to something you _create()'d because they're all just integers.
Anyway, assuming V8 doesn't do any tracing now, it's bound to do so in the future. No way Google's not going to keep chrome ahead of the game if Mozilla's optimizations are proving marginally more effective. Either way, I don't think it's necessary considering how short most snippets of execute_string() are. Honestly, 95% of the use cases are divided between "script0()", "return spr_box_red;", and "return sqrt(1 + 10)/15;", where each of those have segments of user input or a color or number by which a resource should be looked up. Not much to optimize, and even if it did have a tracer, it would be impossible for either LLVM's stock passes or even a particularly brilliant pass to resolve types on the fly, since the scope can change randomly in GML, changing everything.
Anyway, Clang's always been good at compiling C things; they're just constantly hemming and hawing about whether they support C++. I saw geordi had been replaced by clang for a bit on freenode, and I thought it was finally becoming production ready, but clang has since disappeared so I guessed I just assumed the project failed because C++ doesn't get along well with garbage collected JIT stuff.
Anyway, assuming V8 doesn't do any tracing now, it's bound to do so in the future. No way Google's not going to keep chrome ahead of the game if Mozilla's optimizations are proving marginally more effective. Either way, I don't think it's necessary considering how short most snippets of execute_string() are. Honestly, 95% of the use cases are divided between "script0()", "return spr_box_red;", and "return sqrt(1 + 10)/15;", where each of those have segments of user input or a color or number by which a resource should be looked up. Not much to optimize, and even if it did have a tracer, it would be impossible for either LLVM's stock passes or even a particularly brilliant pass to resolve types on the fly, since the scope can change randomly in GML, changing everything.
Anyway, Clang's always been good at compiling C things; they're just constantly hemming and hawing about whether they support C++. I saw geordi had been replaced by clang for a bit on freenode, and I thought it was finally becoming production ready, but clang has since disappeared so I guessed I just assumed the project failed because C++ doesn't get along well with garbage collected JIT stuff.
1345
General ENIGMA / Re: Game Maker and LLVM
« on: June 19, 2011, 06:48:49 pm »
I was insinuating that GCC could be replaced with something like Clang, which would be a fundamental step towards writing an execute_string based on LLVM. If Clang is the only C++ frontend to LLVM, then so be it.
I was also insinuating that type tracing would already be implemented for me in V8, and since JavaScript and GML are so similar, I could easily take advantage of Google's astounding job on it. How are you so sure that the optimizations Google makes to their code would be any less than completely sufficient for ENIGMA's purposes? My assumption is that being specifically catered to JavaScript would make V8 better for the job. With all the scoping changes involved in running GML, I don't see LLVM's generalized optimizations being perfect for the job.
For simpler code, LLVM is likely to do a great job on it without intervention. But for the purposes of execute_string(), which is completely dynamic, scope-wise, and very likely to employ with() and co, I believe at very least I am better off with V8.
Besides, V8 encorporates optimizations LLVM won't handle for them. How's LLVM like switch()? Oh, that's right, it just does what it's told; it has no more an idea of switch() than a CPU. This means while V8 handles that for me, Yoyo will just generate a string of if() jumps, as GM has always done. V8 optimizes its switch() for anything var can represent. LLVM won't automagically take care of all of GM's optimization woes. It can handle a great deal of them and, indeed, potentially even get their variables to outperform ENIGMA's own var class if I never have ENIGMA's compiler intervene. Potentially. We'll see how that works out for them.
By the by, did anyone ever finish Clang?
I was also insinuating that type tracing would already be implemented for me in V8, and since JavaScript and GML are so similar, I could easily take advantage of Google's astounding job on it. How are you so sure that the optimizations Google makes to their code would be any less than completely sufficient for ENIGMA's purposes? My assumption is that being specifically catered to JavaScript would make V8 better for the job. With all the scoping changes involved in running GML, I don't see LLVM's generalized optimizations being perfect for the job.
For simpler code, LLVM is likely to do a great job on it without intervention. But for the purposes of execute_string(), which is completely dynamic, scope-wise, and very likely to employ with() and co, I believe at very least I am better off with V8.
Besides, V8 encorporates optimizations LLVM won't handle for them. How's LLVM like switch()? Oh, that's right, it just does what it's told; it has no more an idea of switch() than a CPU. This means while V8 handles that for me, Yoyo will just generate a string of if() jumps, as GM has always done. V8 optimizes its switch() for anything var can represent. LLVM won't automagically take care of all of GM's optimization woes. It can handle a great deal of them and, indeed, potentially even get their variables to outperform ENIGMA's own var class if I never have ENIGMA's compiler intervene. Potentially. We'll see how that works out for them.
By the by, did anyone ever finish Clang?
1346
General ENIGMA / Re: Game Maker and LLVM
« on: June 19, 2011, 02:08:10 pm »
We'll see how it does against my personal choice. It seems to me that V8 is a more likely candidate to be good at optimising GML; JavaScript's own var is ten times more capable than Game Maker's as far as storing <all sorts of shit>. Of course, the optimization effect may well be dampened by the fact that I'll have to declare all variables as an Array ahead of time.
To be honest, though, I'm not really worried about that.
What does concern me is how big a parse hack with() will be, and how array = 1; will set all of array to 1 (except for ENIGMA arrays such as alarm[] or view_*[]).
To be honest, though, I'm not really worried about that.
What does concern me is how big a parse hack with() will be, and how array = 1; will set all of array to 1 (except for ENIGMA arrays such as alarm[] or view_*[]).
1347
General ENIGMA / Re: Game Maker and LLVM
« on: June 19, 2011, 07:17:03 am »
That's a good bit of news. Now even if they do hook up LLVM, they'd have to triple overhaul everything to pretend to approach ENIGMA's speed, and they'd still not offer the versatility. Enjoy typing sixteen letters to instantiate anything, GM fans ^_^
Oh, and by the way, Rusky; in case this is what you were getting at, it'd take sixty, maybe 120 seconds to hook up LLVM to ENIGMA if you have both installed, at this point. Just copy gcc.ey in Compilers/Windows to llvm.ey, and change the PATH and command attributes in the file to cater to it. Then just select it from LGM's "ENIGMA Settings" pane.
How good is LLVM at JITing a plain-text string of C++?
Oh, and by the way, Rusky; in case this is what you were getting at, it'd take sixty, maybe 120 seconds to hook up LLVM to ENIGMA if you have both installed, at this point. Just copy gcc.ey in Compilers/Windows to llvm.ey, and change the PATH and command attributes in the file to cater to it. Then just select it from LGM's "ENIGMA Settings" pane.
How good is LLVM at JITing a plain-text string of C++?
1348
General ENIGMA / Re: Game Maker and LLVM
« on: June 18, 2011, 10:34:35 pm »
That post had no trollable content; would you care to try again?
...I've been taking ENIGMA mostly any direction I please at this juncture. Adding new features and points of extensibility rather than going through and implementing old ones. Wonder if Dailly will try to add real types to GM any time soon...
...I've been taking ENIGMA mostly any direction I please at this juncture. Adding new features and points of extensibility rather than going through and implementing old ones. Wonder if Dailly will try to add real types to GM any time soon...
1349
General ENIGMA / Re: Game Maker and LLVM
« on: June 18, 2011, 10:20:34 pm »
Point taken; forgoing the possibility that they will somehow include two copies of LLVM as they did SDL on Mac, I suppose it is possible that they could even decrease the size of the runner by replacing their mess with code from a crack team of caffeine-driven FOSS programmers.
Also, I hear all sorts of shit about Dailly's modifications breaking compatibility. While I don't pay any more mind to their endeavours than I might a piece of gum stuck to the bottom of my chair, it sounds like they're breaking scripts that take advantage of arguments being assumed zero when not passed. Really, I've heard so much shit about GM8.1, it makes me think there's not much else to ruin. Of course, I suppose it all really depends on who you ask; kind of like I might gag and choke upon visiting someone's ammonia-exuding rathole home, while its owner would be completely comfortable (if comparatively incapacitated).
As far as using LLVM goes, in theory, this is a great stride for GM and could mean the dawn of a new age in which it keeps up (or even surpasses) ENIGMA's own performance, depending on ten or so trillion conditions. In practice, I won't be surprised to find they still pad the runner to the next integer megabyte with nulls and include two copies of something large.
Also, I hear all sorts of shit about Dailly's modifications breaking compatibility. While I don't pay any more mind to their endeavours than I might a piece of gum stuck to the bottom of my chair, it sounds like they're breaking scripts that take advantage of arguments being assumed zero when not passed. Really, I've heard so much shit about GM8.1, it makes me think there's not much else to ruin. Of course, I suppose it all really depends on who you ask; kind of like I might gag and choke upon visiting someone's ammonia-exuding rathole home, while its owner would be completely comfortable (if comparatively incapacitated).
As far as using LLVM goes, in theory, this is a great stride for GM and could mean the dawn of a new age in which it keeps up (or even surpasses) ENIGMA's own performance, depending on ten or so trillion conditions. In practice, I won't be surprised to find they still pad the runner to the next integer megabyte with nulls and include two copies of something large.
1350
General ENIGMA / Re: Game Maker and LLVM
« on: June 18, 2011, 09:48:29 pm »
I can't wait to see what this does to the size of the runner. :3
Not to mention they're already beginning to trash compatibility with old GM's. If they play their cards right, they could very well level the playing field between us in a number of respects with this new idea of theirs. I can't wait to see how they fuck it up.
I'll mention that personally, I'm already greasing up for the size overhead V8's going to bring us. As such, I'm adding a more formal extension system that will enable it to be swapped off for practical applications. When it's on, however, I imagine our "runner" is going to shoot up to 2.5M. My ass is going to be sore for days.
Not to mention they're already beginning to trash compatibility with old GM's. If they play their cards right, they could very well level the playing field between us in a number of respects with this new idea of theirs. I can't wait to see how they fuck it up.
I'll mention that personally, I'm already greasing up for the size overhead V8's going to bring us. As such, I'm adding a more formal extension system that will enable it to be swapped off for practical applications. When it's on, however, I imagine our "runner" is going to shoot up to 2.5M. My ass is going to be sore for days.
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 »