Since compiles of large projects can cause Dream Maker to become unresponsive for long periods of time and somtimes even crash DM altogether (which has been reported twice), it would be nice if compiling took place on a different process so that DM stays responsive and can continue to run if the compiler crashes. This seems fairly straight forward to do, since dm.exe is already distributed with BYOND. Just have Dream Maker run it and parse its output instead of having the IDE perform the compile.
Edit: It would also be nice if this were done for updating the object tree as well, so that we can continue using DM while the update takes place.
ID:101243
 Sep 1 2010, 3:31 am (Edited on Sep 1 2010, 11:48 am)
|
|||||||
Resolved
| |||||||
|
Sep 1 2010, 5:50 am
|
|
Darker Legends
 |
+
|
Much agreed, crashing irritates me so much...
| |
DreamMaker and dm.exe both link to the backend functions in libbyond.so. So it's not that DreamMaker is calling dm.exe, per-se. However, we should be able to put the compilation into a separate thread since it doesn't need much interaction. I'm not sure the program won't crash if the worker thread does, but at least you'd be able to use the UI during long compiles.
| |
That would definitely be a big improvement, but would it be feasible to run the compile in a separate process, like Google Chrome does with its tabs?
| |
Tom wrote:
DreamMaker and dm.exe both link to the backend functions in libbyond.so. So it's not that DreamMaker is calling dm.exe, per-se. However, we should be able to put the compilation into a separate thread since it doesn't need much interaction. I'm not sure the program won't crash if the worker thread does, but at least you'd be able to use the UI during long compiles. You can catch these kinds of errors in another thread anyway. Spawning another process might be easier to manage (plus, you could let the user customize arguments and stuff freely by doing that). | |
We'll also need a kill compile if you send a compile command while it's already compiling so that it doesn't stack up and cause issues, as a single compilation run by itself is a little process heavy when it comes to larger projects.
That's just me though. | |
I'd love for my 1000x1000x5 map to stop locking Dream Maker up entirely on compile.
| |
Stevenw9 wrote:
I'd love for my 1000x1000x5 map to stop locking Dream Maker up entirely on compile. You shouldn't have a map of that size to begin with. Chance's are you aren't going to use much of it. | |
ExPixel wrote:
Stevenw9 wrote: On top of that, the larger the map is, the worse it will lag when in the map editor as well. Z levels are your friend. I'd rather have 100x100x100 than have a 1000x1000x1 | |
I have a thing for large maps rather than blocky ones. It gives a much better seamless world feel, and you'd be suprised how much of a 1,000x1,000x5 map I can actually use.
P.S. I only get lag with the initial load. As far as actually using it, it works fine. Until I compile. | |
I have had someone set variables like icon size to 1x1 to mess with me while i'm coding & then DM even on a small 10x10 map is un-responsive for minutes...it would be nice to be able to cancel the compiling process & not lock up DM so you can still do ANYTHING...I end up having to cancel the process by ending dream maker forcefully through the Task Manager because I get tired of waiting, on an actual project that takes a long time for example I would do the same if I spotted an error or started seeing the compiler throwing lots of errors out at me so I can start all over again without needing to wait through the whole compile process.
| |
Compiling large projects can take a rather long time.
Currently, if an error occurs, like missing a closing bracket (everybody does it =p), the compiler will continue to report errors for 5 minutes or so until it reaches the maximum number of errors it can report. The guide says that errors halt compilation, so I don't know why it hangs for so long after encountering one, or why it appears to be trying to continue to find errors in the subsequent mess caused by unclosed brackets/indentation/missing statements/empty clauses. Would it be feasible/practical to add an option to the interface like "Abort on Error" or similar (like many other compilers have), or perhaps a setting like #define MAX_ERRORS *number*, to make compiling more bearable when you keep making silly typos. If there's a lot of work involved in doing that, no worries. We can just continue using taskmanager to kill it. Thanks for your time. | |
While this would be a great addition you can manage this right now by using dm.exe to compile from the command-line, you can press ctrl+C to cancel the compile after it errors to see the error you need quicker without having to wait for it to finish.
| |
Your are pretty much just killing the process hen you use command prompt, an idea solution if you compile the source that way, surely this can be done in DreamMaker.
| |
I'm sure that's something we can add an option for. Honestly, we never intended BYOND to be used for games that take 5 minutes to compile!
| |
Cool. As for the games, yeah it happens sometimes. Currently I've got a game that takes about a minute and a half to compile due to all the resources....
Quick question: Is the compiler multi-threaded? | |