Problem compiling

[Bainespal]

For all I know this might be a file management mistake that I've made, and if so I apologize for wasting time. But I think it's some kind of bug in my source that is confusing the compiler so badly it doesn't know what to do.

I foolishly added a lot of code before compiling the changes, and now the compiler freezes. I use the Windows graphical compiler, and the progress slowly advances and then stops when its almost all the way to the right. Since compiling has never even been slow for me before, I assume something is wrong.

I've tried commenting out the code that I think most likely to have caused the problem. When I first commented it out the compiler did not freeze again, but it produced an error message that does not cite any particular problem in the source. It just says "- Exit code = -1 (1)". What's the exit code mean?

Code: Select all

Unable to compile using '"C:\Documents and Settings\Bainespal\IF\Hugo\hc.exe" @list=. -lso "C:\Documents and Settings\Bainespal\IF\Hugo\Projects\Legend Maker\legendmaker.hug"' - Exit code = -1 (1)

I tried commenting and uncommenting the code in question a few different times, and sometimes the compiler gives the exit code as an error message, and sometimes it freezes. I don't understand why these two behaviors seem unpredictably interchangeable. This probably means that the code I thought was the problem isn't.

[Roody_Yogurt]

Hmm, yeah, I'll ask Kent the next time I see him, but I don't know what that code is.

Things I'd try-
1. If you've been compiling under the same instance for a while, close out of the compiler completely and open up a new one. I find that the frontend gets confused, especially if you move source files around in between compilations.
2. Maybe you did as Tdarcos did the other month and accidentally treated a constant or object as a variable.

EDIT: Also, try adding the -a switch so it quits after the first error, possibly. Maybe the -e switch for expanded errors, too.

[Tdarcos]

2. Maybe you did as Tdarcos did the other month and accidentally treated a constant or object as a variable.

No, that just caused the run time to crash when it came across that, I don't think it affected the compilation.

Sometimes the complilation speed drops like a rock. Also, if you have the game open in another window because the run-time is holding it open because you're using the typical "compile in one window, edit in another, run the game in a third" practice that can cause problems and seriously increase compile time. Free Pascal under Lazarus makes it obvious, if you have the executable application file open from a previous run or have it open in a CMD window because you have to give new parameters, when you try to re-compile the source, you get a message that the compilation failed because the compiler is unable to rewrite the application file. Hugo will rewrite the .HEX file if it's in use, it just takes damn near forever.

I'll notice that, up to a point, a game will compile in a second or two, then, all of a sudden, you add a few more lines of code, use a few more features of the system or add another verb or two, or something minor, and the compile time jumps to like 13-15 seconds. No further jumps in the compile time seem to occur, I guess my program didn't get big enough to go to an even longer time. (Although I did have to increase the number of verbs or something, I used more than the maximum of something in Tripkey that exceeded the standard limit and I had to increase it. Not attributes, thank Wotan!)

This reminds me of something because I think I had a problem like this with Hugo on something I was doing.

Also, are you running 64-bit Windows? I have to kill a zombie process every so often in Task Manager because Word Perfect 8 - the last really good version of Word Perfect - fails to quit clean when running on 64-bit Windows 7. Which means whatever file it was editing is still in use and locked so it can't be replaced as long as that process does not quit.

[Roody_Yogurt]

Paul, are you still using ConTEXT? You might want to set it up to compile from within it. To do so, go to /Options/Environment Options/Execute Keys, and set it up like this:



(my parameters field is set to "@lib=c:\hugo\lib @source=%p -s %n", where my Hugo library is at c:\hugo\lib)

After that, you can set up other buttons to play the resulting file in the expected directory. You can control where new files will show up by changing the environmental variables: http://hugo.gerynarsabode.org/index.php ... _Variables

Personally, I set my HUGO_OBJECT environment variable to a HugoFiles folder on my desktop.

[Tdarcos]

Paul, are you still using ConTEXT?

I have never used it, never claimed I used it, and don't even know what it is. For Free Pascal, they have an excellent IDE called Lazarus which does a lot of things for Object Pascal that I wish they had for Hugo. Object inspector, procedure locator, find where variable is declared, etc.

For Hugo, I use Programmer's Editor, it does have tabbed editing and color syntax-based editing. I've never used ConTEXT at all.

THE
OUT OF CONTEXT
STEALER OF AARDVARK'S ENDINGS

[Bainespal]

1. If you've been compiling under the same instance for a while, close out of the compiler completely and open up a new one. I find that the frontend gets confused, especially if you move source files around in between compilations.

I didn't move source files around until after I started getting the compiler problems, but at any rate, the graphical compiler just now worked again. Thank you, and I'm sorry to bother you with that.

Also, thanks for showing me how to set up the compilation from within ConTEXT. I tried to do that before, but I couldn't quite get it set up right, and it never worked. Following your screenshot, I got it almost working. Closer than I've had it before. Now it only complains that there's "no sourcefile specified," although I did specify the sourcefile, and it prints the full path with the extension. Anyways, don't worry about what I'm still doing wrong there; it doesn't really matter. ;)

Also, if you have the game open in another window because the run-time is holding it open because you're using the typical "compile in one window, edit in another, run the game in a third" practice that can cause problems and seriously increase compile time. Free Pascal under Lazarus makes it obvious, if you have the executable open when you try to compile it, the compiler is unable to rewrite it. Hugo will rewrite the .HEX file if it's in use, it just takes damn near forever.

Hmm... That may have been involved. That is how I've generally worked, with the Context, the graphical compiler, and the Debugger open. That never caused any problem like this before. This time, instead of the Debugger, I had the .hex open in Gargoyle.

Also, are you running 64-bit Windows?

No.

[Bainespal]

Good news! I can now compile directly from ConTEXT! I had to get rid of the "@source" parameter, and simply include the file path instead (represented in ConTEXT by "%n"). I'm sure compiling from the editor will be much more efficient.

Roody, again, a thousand thank-yous!

[Bainespal]

Strangely, even launched from within ConTEXT, the compiler was freezing every other time I tried to compile -- exactly ever other time, for a few times at least. The output window in Context would remain blank indefinitely, with the "Terminate" button available. I would have to click the Terminate button, and then try compiling again. Then the compilation would go through, producing the list of code errors. When I made a change and tried to recompile, the compiler would freeze again, and I had to abort and compile again.

I finally corrected all the errors, and the compiler successfully built the game file. So, I'm hoping that it something about the glitchy code structure that was doing weird things to the compiler. Hopefully, it should work from now on.

Anyways, I'm just trying to document this experience for future reference. I'm fairly certain that my code was the main problem, but this might also indicate a bug in the compiler. If there is a bug, it is present in both the graphical and command-line versions of the compiler.

[Roody_Yogurt]

Good news! I can now compile directly from ConTEXT! I had to get rid of the "@source" parameter, and simply include the file path instead (represented in ConTEXT by "%n"). I'm sure compiling from the editor will be much more efficient.

Roody, again, a thousand thank-yous!

The main reason I go with the @source route is that various text editors hate when the command line compiling the game is too long. I cut down on the length of the resulting command by keeping my Hugo executables and library in a /hugo folder directly on the C: drive. That way, getting that stuff right lets me keep my source files on the desktop or buried in other folders and I can compile without a hitch.

Anyhow, that's strange the the @source parameter didn't work for you, but hey, at least it's working.