Re: DinkC Validator public beta
Those few of you who remember my previous post about this, may recall that I tried to keep it secret at all cost. Well, now the alpha period is over, and it's beta test time. I'm not just looking for a few select beta testers. I'm putting the beta out in the open for everybody to test.
Like the name in the subject says, this thing validates DinkC scripts. It aims finding all kinds of errors in DinkC scripts, from missing semicolons at the end of lines, to "else"s appearing before "if"s. This beta isn't entirely complete, though, so it doesn't validate parameters of functions yet. (Such as that say() should have a string, and a sprite number, and nothing more, nothing less.)
I want you to report any kind of anomalies with the program. If it finds an error that is not an error, please report that. However, what's more important is when it doesn't find an error that it should've found. So please, put this program through scrutiny by testing all kinds of sick and twisted DinkC constructs you can come up with through it.
You can download the program from my site. Save it to a folder of its own, and extract it. A decent extractor, like WinRAR should be able to handle tar.bz2 files. You run the program by starting the command prompt, and change the directory to the one where you extracted the files, and then issue the command "java -jar dinkValidator.jar <path-to-dinkc-file-to-test>". I'm not certain that the path can contain spaces or not. You'll find out soon enough.
The final version will have a GUI, so you won't have to worry about these things if you wait. However, I will need to have some people to test this for me before I start doing the necessary stuff for the final release, so please give it a go if you have time.
Just like last time, the program requires you to have or install the Java Runtime. If you're certain you don't have it, you can download it at that link.
If you are sure you have it, you must also make sure that the path to the java binaries are in your PATH environmental variable. Instructions for doing this can be found here.
KNOWN ISSUES:
* Global variables will be reported as "possibly uninitialized variables"
* Calls to own methods will give an error
Like the name in the subject says, this thing validates DinkC scripts. It aims finding all kinds of errors in DinkC scripts, from missing semicolons at the end of lines, to "else"s appearing before "if"s. This beta isn't entirely complete, though, so it doesn't validate parameters of functions yet. (Such as that say() should have a string, and a sprite number, and nothing more, nothing less.)
I want you to report any kind of anomalies with the program. If it finds an error that is not an error, please report that. However, what's more important is when it doesn't find an error that it should've found. So please, put this program through scrutiny by testing all kinds of sick and twisted DinkC constructs you can come up with through it.
You can download the program from my site. Save it to a folder of its own, and extract it. A decent extractor, like WinRAR should be able to handle tar.bz2 files. You run the program by starting the command prompt, and change the directory to the one where you extracted the files, and then issue the command "java -jar dinkValidator.jar <path-to-dinkc-file-to-test>". I'm not certain that the path can contain spaces or not. You'll find out soon enough.
The final version will have a GUI, so you won't have to worry about these things if you wait. However, I will need to have some people to test this for me before I start doing the necessary stuff for the final release, so please give it a go if you have time.
Just like last time, the program requires you to have or install the Java Runtime. If you're certain you don't have it, you can download it at that link.
If you are sure you have it, you must also make sure that the path to the java binaries are in your PATH environmental variable. Instructions for doing this can be found here.
KNOWN ISSUES:
* Global variables will be reported as "possibly uninitialized variables"
* Calls to own methods will give an error
"I want you to report any kind of anomalities with the program."
So they have to be abnormalities and anomalies combined to merit a report.
Yeah.. just teasing.. my apologies for not having anything better to reply with. If it means anything, though, your program sounds awesome and I'd love to give it a try after I finish work on my new PC.
So they have to be abnormalities and anomalies combined to merit a report.
Yeah.. just teasing.. my apologies for not having anything better to reply with. If it means anything, though, your program sounds awesome and I'd love to give it a try after I finish work on my new PC.
Heh, woops. Corrected.
Yup, give it a shot. The more, the merrier.
Yup, give it a shot. The more, the merrier.
Ah Phoenix, it all becomes clear... Good luck with it... And hope you're feeling better!
Good luck with it... And hope you're feeling better!
Oh, and congrats on getting this out so quickly.
Hm, this thing sparked way less interest than I thought it would. Has nobody tried this thing yet? 
Cool. I'll get around to trying it soon (when I'm not quite so swamped with important stuff to do). Might be that I need this what with the errors the script I posted here had. 
I haven't, and probably won't, because:
a) I have better things to do (read: homework is eating time), partly due to this:
b) I don't code DinkC all that often. Even when there's no homework left, I find other things more enjoyable.
c) My DinkC is already beyond the level to make the mistakes your program finds. It wouldn't prove very useful to me.
When there's no homework left (hahaha, yeah right), I might try it, though, just for the purpose to "see what it does".
a) I have better things to do (read: homework is eating time), partly due to this:
b) I don't code DinkC all that often. Even when there's no homework left, I find other things more enjoyable.
c) My DinkC is already beyond the level to make the mistakes your program finds. It wouldn't prove very useful to me.
When there's no homework left (hahaha, yeah right), I might try it, though, just for the purpose to "see what it does".
c) My DinkC is already beyond the level to make the mistakes your program finds. It wouldn't prove very useful to me.
OK, now that is bullshoot. True and sincere bullshoot. Don't get me wrong, you're probably a good coder. But saying that you never make mistakes is total bullshoot. I tested my program on some the original Dink scripts and quite a few of SOB's scripts, and in both cases, I found many errors. I don't suppose you're going to tell me that SimonK is not yet "beyond the level to make the mistakes my program finds" because his scripts contains errors my program found, while your scripts certainly would not contain such errors?
It's as easy as forgetting the & at the start of a variable or forgetting to enclose your strings with a " in both ends, or perhaps forgetting a } at the end of a long list of ifs and elses, and whatnot. It doesn't take much do make a mistake. SOB (or perhaps it was the original Dink) had some instances of "freeeze" where it should've said "freeze", e.g. Hard to see with the naked eye, but my program will immediately kick your butt for it.
OK, now that is bullshoot. True and sincere bullshoot. Don't get me wrong, you're probably a good coder. But saying that you never make mistakes is total bullshoot. I tested my program on some the original Dink scripts and quite a few of SOB's scripts, and in both cases, I found many errors. I don't suppose you're going to tell me that SimonK is not yet "beyond the level to make the mistakes my program finds" because his scripts contains errors my program found, while your scripts certainly would not contain such errors?
It's as easy as forgetting the & at the start of a variable or forgetting to enclose your strings with a " in both ends, or perhaps forgetting a } at the end of a long list of ifs and elses, and whatnot. It doesn't take much do make a mistake. SOB (or perhaps it was the original Dink) had some instances of "freeeze" where it should've said "freeze", e.g. Hard to see with the naked eye, but my program will immediately kick your butt for it.
It's as easy as forgetting the & at the start of a variable or forgetting to enclose your strings with a " in both ends, or perhaps forgetting a } at the end of a long list of ifs and elses, and whatnot.
I agree. Even the best of professional programers make mistakes in their coding. And they admit it. They're usually little mistakes like the ones you mentioned. Of course these little mistakes cause problems ranging from small (doesn't work in extremely convulted situations that will probably never occur except when deliberately trying to crash program in them) to major ones (such as not executing at all).
All of the mistakes I mentioned in my other post in this thread are such small mistakes where I forgot to do a few things I knew to do. However, despite being small they caused a major problem: the script wouldn't execute and the game froze (it wouldn't end the intro sequence since it needed the parts with the errors to move onto the next script in the intro sequence).
I agree. Even the best of professional programers make mistakes in their coding. And they admit it. They're usually little mistakes like the ones you mentioned. Of course these little mistakes cause problems ranging from small (doesn't work in extremely convulted situations that will probably never occur except when deliberately trying to crash program in them) to major ones (such as not executing at all).
All of the mistakes I mentioned in my other post in this thread are such small mistakes where I forgot to do a few things I knew to do. However, despite being small they caused a major problem: the script wouldn't execute and the game froze (it wouldn't end the intro sequence since it needed the parts with the errors to move onto the next script in the intro sequence).
I ran it on all of Initiation's scripts, which I thought were pretty good. It did find a few valid errors.
Variable names actually include the & in the engine. It also might make it a tad easier to immediately see that the validator is complaining about a variable instead of a function.
Line 43: WARNING: the variable "_temp01" has already been defined earlier in the script
In this script (initiation's common.c), I have a series of functions that I call using external. There's no chance that the prior definition will affect the current one. I'm not sure if it's possible / worth-it to try to detect legitimate cases for this warning (such as with main procedures).
Line 101: WARNING: Shorthand if construct detected. These may not work as you expect. It is recommended that you enclose if constructs in braces
The shorthand if construct is only a problem with variable assignments, function calls should always work.
Line 246: ERROR: Found the literal "restart_game", expected command, "if", goto, return, or "}"
credits.c (and a few other scripts)... I'm not sure I see what the problem is. My braces are properly nested and everything. It seems to dislike restart_game entirely.
Line 52: ERROR: Found the literal "Dink must face the same direction as the arrow below him.", expected title_end()
dance.c. Doesn't seem to like titles with multiple lines.
goto end
goto end
goto end
goto end
It printed these lines out in dance3a1.c and a few other scripts, not sure why. Maybe because the label appeared after the goto statement?
Line 48: ERROR: Found the literal "loop", expected command, "if", goto, return, or "}"
ending3.c, this was a label "loop01:"
Line 11: ERROR: Found the literal "armmovie", expected command, "if", goto, return, or "}"
Doesn't like calling procedures declared elsewhere in the file.
Line 16: ERROR: The label "add_item" has not been defined
l3pole1.c : in fact, it had.
Line 43: ERROR: Found the integer "2", expected "("
Doesn't seem to like the function sp_brain_parm2
Variable names actually include the & in the engine. It also might make it a tad easier to immediately see that the validator is complaining about a variable instead of a function.
Line 43: WARNING: the variable "_temp01" has already been defined earlier in the script
In this script (initiation's common.c), I have a series of functions that I call using external. There's no chance that the prior definition will affect the current one. I'm not sure if it's possible / worth-it to try to detect legitimate cases for this warning (such as with main procedures).
Line 101: WARNING: Shorthand if construct detected. These may not work as you expect. It is recommended that you enclose if constructs in braces
The shorthand if construct is only a problem with variable assignments, function calls should always work.
Line 246: ERROR: Found the literal "restart_game", expected command, "if", goto, return, or "}"
credits.c (and a few other scripts)... I'm not sure I see what the problem is. My braces are properly nested and everything. It seems to dislike restart_game entirely.
Line 52: ERROR: Found the literal "Dink must face the same direction as the arrow below him.", expected title_end()
dance.c. Doesn't seem to like titles with multiple lines.
goto end
goto end
goto end
goto end
It printed these lines out in dance3a1.c and a few other scripts, not sure why. Maybe because the label appeared after the goto statement?
Line 48: ERROR: Found the literal "loop", expected command, "if", goto, return, or "}"
ending3.c, this was a label "loop01:"
Line 11: ERROR: Found the literal "armmovie", expected command, "if", goto, return, or "}"
Doesn't like calling procedures declared elsewhere in the file.
Line 16: ERROR: The label "add_item" has not been defined
l3pole1.c : in fact, it had.
Line 43: ERROR: Found the integer "2", expected "("
Doesn't seem to like the function sp_brain_parm2
You don't forget the } if you type it immediately after typing the {, then going one line backward and indent and thén type the code between the {}'s. Idem with "'s, just without the line-backward-indent thing.
Also, I use the EDC1 color coding, this will make any variable without & to be not coloured, and therefor stand out. Also this generates funky colours when using non-ending "'s, in case I ever forget them.
But you're right, I'm not completely flawless after only typing in the code. But, after re-reading it once, with colour coding on (within a few days I hope I'll even be using the über Notepad++ for this, too), it is (only for these kind of errors. Infinite loops might still exist).
<nag>As for freeeze (triple-e intended), you know custom functions are possible with 1.08, right? I could put make_global_function("function","freeeze"); somewhere and it'd be completely valid. </nag>
LATE ADDITION: I do accept ánd admit that I'm being a male reproductive organ.
Also, I use the EDC1 color coding, this will make any variable without & to be not coloured, and therefor stand out. Also this generates funky colours when using non-ending "'s, in case I ever forget them.
But you're right, I'm not completely flawless after only typing in the code. But, after re-reading it once, with colour coding on (within a few days I hope I'll even be using the über Notepad++ for this, too), it is (only for these kind of errors. Infinite loops might still exist).
<nag>As for freeeze (triple-e intended), you know custom functions are possible with 1.08, right? I could put make_global_function("function","freeeze"); somewhere and it'd be completely valid. </nag>
LATE ADDITION: I do accept ánd admit that I'm being a male reproductive organ.
Finally someone did worthwhile testing. I don't have time to reply properly now, cause I have work in 20 minutes and should prepare for leaving, but this most certainly points out a lot of mistakes that I need to take care of. Most of these errors I even know why happen, so that's cool... yeah. Thanks, redink1.
I don't have time to reply properly now, cause I have work in 20 minutes and should prepare for leaving, but this most certainly points out a lot of mistakes that I need to take care of. Most of these errors I even know why happen, so that's cool... yeah. Thanks, redink1.
