Euphoria Ticket #315: Parser waits for ever

Whether the interpreter or the translator, the EUPHORIA implementation waits for ever. I suspect it is the parser. The program will get the name from the number of this ticket and I will post the zip file up at: 


Type: Bug Report Severity: Blocking Category: Interpreter
Assigned To: mattlewis Status: Fixed Reported Release: 3810
Fixed in SVN #: 3826 View VCS: 3826 Milestone: 4.0.0RC1

1. Comment by jeremy Nov 03, 2010

Waits forever for what? How complex of a program is it, can you reduce it to just a simple include via eucode?

2. Comment by SDPringle Nov 03, 2010

It means it waits for you to type Cntrl+C. Give it a run. Try it out. I just tried it out for 3810.

3. Comment by jeremy Nov 03, 2010

I still don't follow. If I type

$ eui 

it returns right away. What waits? Can you give an example command line that shows this problem?

All bug reports should include easy steps to reproduce the bug.

4. Comment by SDPringle Nov 03, 2010

Download and unzip it change directory into the extracted directory you will find sm.exw

eui sm.exw 

5. Comment by jeremy Nov 03, 2010

Is there not a simple example you could include inside of eucode tags?

6. Comment by mattlewis Nov 03, 2010

It tells me that it can't find Win32Lib.ew. You haven't included all of the code that you're using.

7. Comment by jimcbrown Nov 04, 2010

In smreceivable.e we see that payment.e is included.

The infinite loop happens when we call IncludePop(), and then HideLocals() (symtab.e) never returns.

It looks like we somehow have a loop in SymTab, caused somehow when the S_NEXT symbol winds up pointing to an earlier one.

I was able to work around it by changing HideLocals() to this..

export procedure HideLocals() 
-- hide the local symbols and "lint" check them 
        symtab_index s 
        object old 
        s = file_start_sym 
        while s do 
        ? {-2, s} 
        old = s 
                s = SymTab[s][S_NEXT] 
                if old = 74190 and s = 73990 then 
                s = 0 
                end if 
        end while 
end procedure 

Then I get this error, which seems to be correct (as sm.exw doesn't include any file with that namespace name, only smregistration.e does so)

<0133>:: Syntax error - Unknown namespace 'payables' used 

8. Comment by jimcbrown Nov 04, 2010

Leaving the hack in, if I fix the issue with payables:save(), I get a run-time crash on a call to message_box(). Understandable, considering that I'm using Linux/GNU to test.

9. Comment by jimcbrown Nov 04, 2010

I've uploaded what I have to

This should be the complete source to get running and reproduce the error. See z/ for how I've been running eui (I use no eu.cfg).

Shawn, it would be greatly helpful if you included your versions of win32libex and eugrid (so we could be sure that we are using the same version, as a different one might not allow us to reproduce the bug).

10. Comment by mattlewis Nov 04, 2010

I think the problem is the way we're fixing up the S_NEXT chain for enum types.

11. Comment by SDPringle Nov 04, 2010

I am using 1.3.4 of EuGrid dated: 2nd December 2007. I am using svn version 68 of win32lib from patched with the patch from

12. Comment by mattlewis Nov 04, 2010

Here is a pretty minimal example to reproduce the bug:

-- bug.ex 
public enum type foo FOO, BAR, BAZ end type 
include bug.e 
-- bug.e 
include bug.ex 
public enum type bar FOO, BAR, BAZ, BAT end type 

13. Comment by mattlewis Nov 04, 2010

The issue arose from having an enum as part of an enum type that had the same name as a symbol visible in another file (i.e., another public, etc, symbol in an included file). There were also line table issues, which should be fixed now.

Both the sample code and the minimal sample are parsed correctly now.


Quick Links

User menu

Not signed in.

Misc Menu