Re: warning from Euphoria
- Posted by Matt Lewis Jul 03, 2008
- 699 views
No, that's a separate issue. This warning is about the enhanced symbol conflict resolution that's in 4.0. Consider that you have been using libfoo from the archive. It is made up of multiple files, and one of those files exposes a global procedure named foo. Now suppose, that someone else releases libbar, which is also pretty cool, and you want to use it in your application. It's also made up of multiple files, and one of those exposes a global variable named foo.
Suppose that you included libfoo first in the application. Whenever any part of libfoo tries to call "foo", the interpreter knows exactly what it means, because there's only one of them. But later in the program, you've included libbar. Now, when parts of libbar try to use its "foo" variable, the interpreter has a choice to make. Which global did you really mean?
If the file in which it is being referenced has included the file where "foo" is defined, then the interpreter is now smart enough to figure that you must mean that one (assuming that you didn't *also* include libfoo, or something else that exposes something called foo, in which case you need to qualify the reference with a namespace). This warning is telling you that you're using a symbol from a file that was never included into the file.
To make the warning go away, you need to either include the file where the symbol is defined, or include some other file that includes the file. For instance, if you include win32lib, then all of the exposed symbols that are defined in its many files are considered included into that file.
But you may have other files that rely on other files to have previously included something. This may not be so bad in your application, but it can cause conflicts when people use third party code, and previously, the only way to fix it was to modify the third party code.
In Judith's case, machine.e had already been included, but not by the file that was calling allocate.
