OpenEuphoria

Re: Attn:[Daryl Border]

• Posted by Vincent <darkvincentdude at yahoo.com> Apr 30, 2005
• 445 views

Daryl Border wrote:
> 
> Vincent wrote:
> > 
> > Daryl,
> > 
> > I just got around to voting on your "Updated PD Interpreter Source Files";
> > great job on it, the global conflict resolution works great with VEEU. As
> > you already
> > know, there was a small bug I had to fix to get it to work
> > without random failure:
> 
> Thank you, maybe it will motivate me to finish some other projects I've
> started.
> 
> > 
> > }}}
<eucode>
> > -- symtab.e
> > if length(dup_globals) > 1 and sequence(include_paths[current_file_no]) then
> > ...
> > ...
> > </eucode>
{{{

> > 
> > I'm not sure how that fixed the problem with dup_globals not reading
> > as a sequence with PD source, dup_globals should always be a sequence,
> > because it's
> > defined as sequence type: "global sequence dup_globals",
> > but w/e :S.
> 
> I don't think it was dup_globals that was the problem. It was
> include_paths[current_file_no].
> The problem starts with the way I add a new element to include_paths as new
> files are
> included. I used include_paths &= 0. This starts each include path as an
> integer zero.
> Normally when the parser processes a include statement, that file's file
> number and
> path
> are appended to the zero changing it to a sequence. What I didn't consider was
> a situation
> where a programmer references a global variable, but doesn't use any include
> statements.
> Under 
> those circumstances, the integer isn't changed to a sequence causing the
> crash.
> I see three ways to fix the bug. 
> 1 use your fix which works fine.
> 2 fix the bug at the source by changing line 370 of scanner.e from 
>    include_paths &= 0  to include_paths = append(include_paths, {}).
>    this will assure that each element is always a sequence and also eliminate
>    the zeros
> saving 
>    a little space.
> 3 take advantage of the bug to provide a custom error message reminding the
> programmer
> to use
>   include statements in their files.
> Which would you prefer?
> 
> > 
> > If you like, you could fix that line in symtab.e and update the
> > contrubution, though it may not matter to much now.
> > 
> > 
> > Regards,
> > Vincent
> > 
> > --
> > Without walls and fences, there is no need for Windows and Gates.
> > 
> 
> Thanks again, Daryl
> 

Ok, now that I thought about it.. my method only prevents that block of
in symtab.e from being executed if "include_paths[current_file_no]" isn't
evaluated as a sequence. So in a case where it is not evaluated as a
sequence, the block is skipped, and the conflict resolution system will
not function. My method prevents an find() error from occuring, but at
a cost of disabling the system in that case.

That is not what I wanted, and makes a new issue. I tested your #2
method, and that worked perfectly. So I will be using your slight
modification in scanner.e, and will remove the "now" unnecessary
sequence() test with "include_paths[current_file_no]".

That will completely fix the problem, plus remove the extra of zeros
you were talking about and remove the sequence test (thus increasing
efficency slighty). I will upload another VEEU update by tommorow with
the fix in the source and all recompiled interpreters.

Thanks,
Vincent

--
Without walls and fences, there is no need for Windows and Gates.