1. Attn:[Daryl Border]
- Posted by Vincent <darkvincentdude at yahoo.com> Apr 28, 2005
- 455 views
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:
-- symtab.e if length(dup_globals) > 1 and sequence(include_paths[current_file_no]) then ... ...
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. 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.
2. Re: Attn:[Daryl Border]
- Posted by Daryl Border <Darylb5 at aol.com> Apr 29, 2005
- 431 views
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
3. Re: Attn:[Daryl Border]
- Posted by Vincent <darkvincentdude at yahoo.com> Apr 30, 2005
- 446 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.