1. Parsing problem using constants
- Posted by zebra Apr 14, 2011
- 1423 views
When using constants like MB_YESNO in messagebox the parser does not recognize it and reports an error. If I substitute the value 4 in its place it works ok. I then tried replacing MB_YESNO from a different library ( my own constants ). It still failed. I changed public to global It still failed. I tried substituting msgbox.e library with ver3.11 msgbox.e library. It still failed. This seems to indicate something is wrong with the parsing of constants when it is being used inside of a function or procedure.
2. Re: Parsing problem using constants
- Posted by jaygade Apr 14, 2011
- 1480 views
Can you post a small example?
3. Re: Parsing problem using constants
- Posted by petelomax Apr 14, 2011
- 1396 views
I'm getting lots of problems trying to run Edita on 4.0.2
NULL, allocate, and sprintf.
What I think the problem is: I'm (accidentally) including dir1/dll.e and dir2/dll.e but the error is very unhelpful, just "errors resolving the following references" instead of the previous way of "a namespace is required; xxx is defined in dir1 and dir2".
Pete
4. Re: Parsing problem using constants
- Posted by zebra Apr 14, 2011
- 1416 views
When using constants like MB_YESNO in messagebox the parser does not recognize it and reports an error. If I substitute the value 4 in its place it works ok. I then tried replacing MB_YESNO from a different library ( my own constants ). It still failed. I changed public to global It still failed. I tried substituting msgbox.e library with ver3.11 msgbox.e library. It still failed. This seems to indicate something is wrong with the parsing of constants when it is being used inside of a function or procedure.
I have figured out what is causing my problem. I am including msgbox.e from another file via the PUBLIC INCLUDE ( scope ) If you try to use a PUBLIC CONSTANT from a PUBLIC INCLUDE file the parser does not see it. But you have use the NAMESPACE scope ( EXAMPLE : msgbox:MB_YESNO then the parser doesn't error out and my program works properly.
5. Re: Parsing problem using constants
- Posted by DerekParnell (admin) Apr 14, 2011
- 1389 views
When using constants like MB_YESNO in messagebox the parser does not recognize
it and reports an error.
If I substitute the value 4 in its place it works ok.
I then tried replacing MB_YESNO from a different library ( my own constants ).
It still failed.
I changed public to global
It still failed.
I tried substituting msgbox.e library with ver3.11 msgbox.e library.
It still failed.
This seems to indicate something is wrong with the parsing of constants
when it is being used inside of a function or procedure.
I have figured out what is causing my problem.
I am including msgbox.e from another file via the PUBLIC INCLUDE ( scope )
If you try to use a PUBLIC CONSTANT from a PUBLIC INCLUDE file the
parser does not see it.
But you have use the NAMESPACE scope ( EXAMPLE : msgbox:MB_YESNO then the parser
doesn't error out and my program works properly.
I don't think that is the problem because referencing a public constant from any included file (public or otherwise) works just fine.
The fact that you needed to use a namespace qualifier seems to indicate that the real problem is that the name 'MB_YESNO' is being included twice (or more) from different files and Euphoria needed your help to tell it which one you really wanted to refer to.
I'll see if we can improve the error message. As it is, Euphoria is telling you ("Errors resolving the following references:") that it can't workout what you mean when you reference 'MB_YESNO'. This could be because it doesn't know about anything of that name OR that there are multiple items with that name in scope.
6. Re: Parsing problem using constants
- Posted by Vinoba Apr 14, 2011
- 1369 views
............ there are multiple items with that name in scope.
I had the same problem with multiple includes of misc.e
In other languages they use "include once".
Is that not an appropriate solution, and if so, would it not be easy to implement?
7. Re: Parsing problem using constants
- Posted by DerekParnell (admin) Apr 14, 2011
- 1364 views
............ there are multiple items with that name in scope.
I had the same problem with multiple includes of misc.e
In other languages they use "include once".
Is that not an appropriate solution, and if so, would it not be easy to implement?
Well it's not quite so simple as that. Currently, you can include the EXACT same file multiple times and Euphoria only actually includes it once. But if two files that have the same name, but are in DIFFERENT folders are included, Euphoria treats them as two different files - even if they have identical contents. I'm not sure we would want to change this behaviour.
8. Re: Parsing problem using constants
- Posted by AndySerpa Apr 15, 2011
- 1402 views
There does seem to be a bug somewhere. Yesterday I ran into a problem in a program with a fairly complicated "include structure" (lots of includes including other includes, many files including the same files) and when calling a function in the regex library, it gave an error that the constant "all_options" had not been assigned a value, which makes no sense since it is a local constant declared in the same file as the function. Adding the no-op "if length(all_options) then end if" right after the constant definition fixed the problem. Couldn't reproduce the error on a simpler program.
9. Re: Parsing problem using constants
- Posted by Vinoba Apr 15, 2011
- 1370 views
At one point in time, somebody had written a small routine, that collected all includes for you. That way, you would know ahead of time the whole include structure in your complex program.
10. Re: Parsing problem using constants
- Posted by petelomax Apr 15, 2011
- 1341 views
At one point in time, somebody had written a small routine, that collected all includes for you. That way, you would know ahead of time the whole include structure in your complex program.
I think there is one in the archives, and that it might need updating with the new rules.
I have just got Edita running on 4.0.2, as well as 2.4 and Phix, though it does take around 18s to load compared to around 2s. Edita has a similar feature built in, just select Options/File Panel (Ctrl L) and, as long as you have saved the file at some point and let the background processing as seen in the status bar complete, you should get an include tree on the lhs. It may or may not be accurate, and I think it deliberately omits some things that 4.0.2 will probably not - it is quite some time since I last looked at that code.
Pete
11. Re: Parsing problem using constants
- Posted by AndySerpa Apr 15, 2011
- 1364 views
Having an include tree can be useful, but my program that trips the bug is "legal" -- the program is not recognizing a constant declared in the same file that references it, although the constant itself is created from values from another file, which may have something to do with it. It's an outright bug.
12. Re: Parsing problem using constants
- Posted by mattlewis (admin) Apr 16, 2011
- 1283 views
At one point in time, somebody had written a small routine, that collected all includes for you. That way, you would know ahead of time the whole include structure in your complex program.
There is a utility program called "eudist" that comes with euphoria v4 that will collect all of your include files for you in a way that makes it easy to distribute your program.
Matt
13. Re: Parsing problem using constants
- Posted by SDPringle Apr 16, 2011
- 1280 views
Well it's not quite so simple as that. Currently, you can include the EXACT same file multiple times and Euphoria only actually includes it once. But if two files that have the same name, but are in DIFFERENT folders are included, Euphoria treats them as two different files - even if they have identical contents. I'm not sure we would want to change this behaviour.
This ambiguous message that says 'cannot resolve %s' is a problem. There ought to be two messages, one '%s has not been declared' and another '%s has been declared more than once'. The second error message should show you where all of the other symbols with the same name are declared. We saw here a user that assumes it means one thing when it means the other. This helps in general.
For the standard library, we could replace the 3.1 .e files with files that only contain 'public include' statements such that at least the same symbols are visible as before. The fact that files in the distributed include directory contain up to three includes isn't a problem because you can just add the same 'public include's to dll.e as for misc.e.
Possible problems I see are name clashes user's existing code, as you will most likely have to include a superset of symbols most of the time; and sometimes a need to add more include files because of this lack of global behavior.
Shawn
