1. eu4.0a2 error
- Posted by doncole2009 Jan 22, 2009
- 901 views
I changed my bin folder from 3 to 4 and now I get the error:
Errors resolving the following references:
E:\EUPHORIA\STOCKS\layer.e (19) EditText13
E:\EUPHORIA\STOCKS\layer.e (25) EditText14
E:\EUPHORIA\STOCKS\layer.e (28) EditText19
E:\EUPHORIA\STOCKS\layer.e (32) EditText20
E:\EUPHORIA\STOCKS\layer.e (36) EditText24
E:\EUPHORIA\STOCKS\layer.e (53) EditText25
E:\EUPHORIA\STOCKS\layer.e (97) EditText4
E:\EUPHORIA\STOCKS\layer.e (108) EditText5
E:\EUPHORIA\STOCKS\layer.e (133) EditText8
E:\EUPHORIA\STOCKS\layer.e (144) EditText9
E:\EUPHORIA\STOCKS\watch.e (167) start
E:\EUPHORIA\STOCKS\watch.e (174) start
if a = start then
Press Enter
I did not change my include folder but none of these includes are in my include folder.
Don Cole
2. Re: eu4.0a2 error
- Posted by mattlewis (admin) Jan 22, 2009
- 826 views
I changed my bin folder from 3 to 4 and now I get the error:
Errors resolving the following references:
...
Press Enter
I did not change my include folder but none of these includes are in my include folder.
Ok. So, what were you running? Where are these symbols actually located? Do you believe that you included them properly? What makes you believe this is related to the switch between 3 and 4. Your post doesn't really make it clear.
Matt
3. Re: eu4.0a2 error
- Posted by doncole2009 Jan 22, 2009
- 840 views
I changed my bin folder from 3 to 4 and now I get the error:
Errors resolving the following references:
...
Press Enter
I did not change my include folder but none of these includes are in my include folder.
Ok. So, what were you running? Where are these symbols actually located? Do you believe that you included them properly? What makes you believe this is related to the switch between 3 and 4. Your post doesn't really make it clear.
Matt
Hello Matt.
I'm running through the Edita Editor on winXP.
This problem does not occur when I put the old (ver 3.x) back in.
All the includes are in the same folder as port.exw the mother program.
Don Cole
4. Re: eu4.0a2 error
- Posted by mattlewis (admin) Jan 22, 2009
- 799 views
I changed my bin folder from 3 to 4 and now I get the error:
Errors resolving the following references:
...
Press Enter
I did not change my include folder but none of these includes are in my include folder.
Ok. So, what were you running? Where are these symbols actually located? Do you believe that you included them properly? What makes you believe this is related to the switch between 3 and 4. Your post doesn't really make it clear.
Matt
Hello Matt.
I'm running through the Edita Editor on winXP.
This problem does not occur when I put the old (ver 3.x) back in.
All the includes are in the same folder as port.exw the mother program.
This is not useful information in understanding your issue. I'm not sure what sort of help you were expecting.
Answers to the following would be useful:
- Where are symbols such as EditText13 located?
- What is the scope of symbols such as EditText13?
- How are the source files that declare the mystery symbols included into the application?
Matt
5. Re: eu4.0a2 error
- Posted by ChrisB (moderator) Jan 22, 2009
- 820 views
Hi
I think this is going to be one of the classic errors that we see when converting from 3.xx to 4.00
Don, what those errors mean, in eu 3.00 speak, is that the variables haven't been defined, or the parser can't define them. Like, you would get an error with
procedure blah() integer x y = x + 2 end procedure
In 3.xx this would produce the error y has bot been defined, but in 4 it produces the unable to resolve error.
The reason 3.xx can resolve the labels, is the way files are included is different.
I suspect that in your case, the main program includes files which also include other files, and these files look for labels earlier in the chain. Sounds hideously complicated, but eu 4 no longer looks in these other include files, unless you specifically tell it to do so.
so at the top of layer.e, you now have to include files explicitly, which 3.xx would have accessed through the file that included layer.e
Sometimes adding 'public include whatever.e' in the root (main) program lists of includes helps.
Does that help?
Chris
6. Re: eu4.0a2 error
- Posted by mattlewis (admin) Jan 22, 2009
- 872 views
I suspect that in your case, the main program includes files which also include other files, and these files look for labels earlier in the chain. Sounds hideously complicated, but eu 4 no longer looks in these other include files, unless you specifically tell it to do so.
so at the top of layer.e, you now have to include files explicitly, which 3.xx would have accessed through the file that included layer.e
This is somewhat inaccurate. What you say is true for export or public symbols, but since this is code that runs on 3.1, I'll assume that they're all global, so they should be seen just fine in 4.0, although if the include statements aren't there, the resolution won't actually happen until the end of parsing. But it should still find them.
So Don may have found a real bug, but there's no way to know from what he's told us so far. Ideally, Don could post a minimal example that demonstrates the structure of his code and exhibits the bug. Something like:
-- post.exw global constant EditText13 = 0 include label.e -- label.e ? EditText13 -- cannot resolve this symbol!
Then, we could reproduce the error, and create a fix (and a unit test, so it won't slip through again).
Matt
7. Re: eu4.0a2 error
- Posted by doncole2009 Jan 22, 2009
- 812 views
I suspect that in your case, the main program includes files which also include other files, and these files look for labels earlier in the chain. Sounds hideously complicated, but eu 4 no longer looks in these other include files, unless you specifically tell it to do so.
so at the top of layer.e, you now have to include files explicitly, which 3.xx would have accessed through the file that included layer.e
This is somewhat inaccurate. What you say is true for export or public symbols, but since this is code that runs on 3.1, I'll assume that they're all global, so they should be seen just fine in 4.0, although if the include statements aren't there, the resolution won't actually happen until the end of parsing. But it should still find them.
So Don may have found a real bug, but there's no way to know from what he's told us so far. Ideally, Don could post a minimal example that demonstrates the structure of his code and exhibits the bug. Something like:
-- post.exw global constant EditText13 = 0 include label.e -- label.e ? EditText13 -- cannot resolve this symbol!
Then, we could reproduce the error, and create a fix (and a unit test, so it won't slip through again).
Matt
ChrisB and Matt,
I think I found the problem.
The Program is set up like this"
port.exw
include ListView2.ew
include newEntry.ew
I have EditText13 defined as global in port.exw, ListView2.ew and newEntry.ew.
These are not the same EditTexts they just have the same name. So I suppose I will have have to go back and remame all these EditTexts.
So why didn't this problem show up in the earlier version of Euphoria.
Don Cole
8. Re: eu4.0a2 error
- Posted by mattlewis (admin) Jan 22, 2009
- 794 views
I think I found the problem.
The Program is set up like this"
port.exw
include ListView2.ew
include newEntry.ew
I have EditText13 defined as global in port.exw, ListView2.ew and newEntry.ew.
These are not the same EditTexts they just have the same name. So I suppose I will have have to go back and remame all these EditTexts.
So why didn't this problem show up in the earlier version of Euphoria.
Do you mean that there are multiple EditText13s (or whatever)? And I presume that the files (label.e, etc) never included anything? Since there are multiple, equally valid symbols that fit the resolution criteria, the parser has no way to determine which is correct.
There are several ways to fix this. You could add an include statement to port.exw in the files causing the error. Though having multiple things named EditText13 is probably not a good convention.
Matt
9. Re: eu4.0a2 error
- Posted by jimcbrown (admin) Jan 22, 2009
- 778 views
So why didn't this problem show up in the earlier version of Euphoria.
I suspect its due to forward referencing. Earlier versions didn't have it, and resolved the names immediately - and therefore could choose the global symbol that was defined earlier in the same file.
Now, when the time to resolve the symbol names come - after all the parsing is done - confusion results due to multiple same names since it is no longer remembered which version of the symbol fits where.
This kind of forward referencing/namespacing issue seems rare enough that we should leave it alone (and call apps that do this broken), at least imnsho.
