Strange detection failure thingy...

Monkey Forums/Monkey Beginners/Strange detection failure thingy...

Irvau(Posted 2016) [#1]
So, recently I've been having problems with some of my projects. Specifically, the main class (the one extended from mojo's App class) doesn't cooperate all too well with the rest of the project.

It's practically impossible to work with the main class in non-main monkey files. You can import the main file just fine, but you can't modify/read any of the main class' fields and their values. Attempting to do so will only get you an error.
For example, the code below would error out around the line in DoStuff() where it attempted to print Thing's A: the parser would claim that the class Test has no such member (or something along those lines).


Interestingly enough, I was able to overcome that by creating a getter function within the same file:

Parser had no problem with that, for some reason.

The same also applies for working with other classes inside the main class. Some of the imports will work out just fine, but other times I stumble upon a class that gets overlooked. For example:

The parser reports an error along the lines of "B = New Bar"; it claims that type Bar is not found. Didn't even complain when I declared the field as of type Bar, only whenever I used the keyword "New" did it bother.

In both cases I made sure to check my spelling thoroughly by ctrl+c'ing and ctrl+v'ing the names around, and the errors still popped up.

Interestingly enough, this seems to happen randomly throughout my projects - not all of them behave in such a way, and not all of them need a workaround for the first problem (although this might be simply because I don't ever try to get something from the main class in that project.)

I'm really curious as to why this stuff occurs. I've tried out my code on the linux compiler and the windows compiler, and both got the same results.

Help, anyone?


ImmutableOctet(SKNG)(Posted 2016) [#2]
Everything's working without a problem for me. Although, I'd recommend not trying to use 'Return' like a function. Add a space between the 'Return' keyword and the value you're returning. I'm surprised that even works when spaced like that.

Anyway, it sounds like your code isn't broken, but your files are. If it's not finding the code between multiple files, it's probably because it can't find the modules you're asking for. Have you tried naming all of the modules using the standard lowercase format? So, something like 'main' instead of 'Main', and 'funx' instead of 'Funx'. The same goes for the imports. This depends on the system, though. Some file systems aren't case sensitive, and some systems do care about it.

Of course, you also need to make sure all of the modules share the same main directory, or are otherwise added to the module path.

Either way, those examples seem to work, so I don't think it's an actual code/compilation issue.


dawlane(Posted 2016) [#3]
As Immutable has beaten me to it. I shall add some tips.
When posting these kind off problems some more information is required like
1) Version of MonkeyX along with the version of transcc
2) The native compiler (MinGW/MSVC) and the version used.

As Immutable has pointed out the the problem is your file naming, you should be careful not to use reserved words/function or class name as file names. Linux is case sensitive as is MonkeyX and as such the file name myclass.monkey and MyClass.monkey with the variables myclass and MyClass are totally different file names and variables. But on Windows and OSX (with case sensitivity off), the file names myclass.monkey and MyClass.monkey would be the same file.

Tip for the naming of files:
Always use lower case letters and don't use the exact character case for the variables and classes.
Some legal file name characters on one target are not guaranteed to be legal on another. One example is the use of the minus sign (-). It causes problems with the Flash target.


Irvau(Posted 2016) [#4]
Oh, woops, my bad.
Version of Monkey X = 84f (Free)
Version of Transcc = 1.85
Version of MinGW (compiler used) = I dunno how to find this

Anyways, I think I've figured it out. It's not anything to do with finding modules (although I must note, Immutable, that the only module imported in the examples is mojo; all the other imports are files). Error seems to be whenever I name a file the same as a class or variable it contains.
Looking through my projects, I find that the first error occurs whenever the global variable I use to store the instance of the game is named the same as the file name. The second one happens whenever I name a class itself the same as the file name.

Making all the filenames lower-case was enough to stop the errors, even when I was on Windows (which seems contradictory to what dawlane has stated).

Now, my curiosity is only furthered - why does the parser mix file names with class and variable names? Wouldn't make sense trying to do that on purpose; it's not like doing "New foo.monkey" will clone all the classes in the file during runtime or anything.

Any explanations would be appreciated.

Oh, and some thoughts:
@Immutable, what's so bad about using Return like a function?
@dawlane don't worry, I tend to avoid using characters such as "-,.;>?\" and all that. Letters is all I use. :^)


dawlane(Posted 2016) [#5]
Making all the filenames lower-case was enough to stop the errors, even when I was on Windows (which seems contradictory to what dawlane has stated).
I will clarify it a bit. What actually matters is the naming and casing of the Import not that actual file name (though file names are important for Linux).
On Windows and OSX (with OSX case sensitivity off) the file system would treat Funx.monkey or funx.monkey as the same file, so a file named Funx.monkey would still get imported if you coded Import Funx or Import funx.
On Linux the file names are case sensitive, so the Import must match that file name and case exactly. On any of the operating systems. If the Import name matches any Class, Function, Variable or reserved word; then you will get errors.

As a general rule I do:
Important avoid direct naming conflicts with reserved words, functions, classes etc.
File names are always lower case.
File Imports are always lower case.
Constants are always UPPER CASE
Normal identifiers are written either in lower case (avoiding the use of any of the file names imported or reserved words etc.), camelCase or if I want to make it more clear with underscore_spacing.
Functions use a capital letter for the first part of every word for FunctionCalls
Classes/Types start with a capital C and follows the same rules as for a function call e.g. CMyClass
Private class identifiers always start with an _underscore

This means I can name a file with something that resembles the class name as an easy reminder of what the file is meant to be.
e.g.
file name: cmyclass.monkey
Import cmyclass
Class CMyClass

Version of MinGW (compiler used) = I dunno how to find this
You should familiarise yourself with the GCC manual. Almost all commands have a brief help summary built-in for options and command format. GNU tools such as gcc, g++ use the command followed by either --help or -h to access this summary. MinGW is the Windows version of these tools.
All you do is open a command prompt, change directory to the bin folder of the MinGW installation any type either gcc -h or g++ -h for the summary. If you have this directory in your system path variable, then there's no need to change directories.

Now, my curiosity is only furthered - why does the parser mix file names with class and variable names? Wouldn't make sense trying to do that on purpose; it's not like doing "New foo.monkey" will clone all the classes in the file during runtime or anything.

If you want to get an answer as to why there is a mixing of Import name with program identifiers. Then I would suggest that you ask Mark Sibly on how he's managing name munging.


Irvau(Posted 2016) [#6]
Ah, I see what you mean now dawlane, with the imports.

As for the MinGW stuff, I was being a derp: I didn't realize that MinGW was/included gcc. :P

Well, thanks for the help!