woody@chinacat.Unicom.COM (Woodrow Baker) (09/12/90)
Well, I finaly got back after spending about 3 hours or so fussing with the NEC 800 (at least that is what it says) It is version 47.0 I have 17 test cases that I ran, without the benifit of an editor (which is why it took so long), and I am going to have to devise and write a few more. It appears that there is something defintly broken with the 890. Glenns code failed right out of the box. All it produced was a blank page. I tried it using my PS-810 hooked up to the computer. It failed on the PS-810, UNTIL I put 2 ^D's after the file. Then it worked fine. I guess the first ^D ended the line, and the second one ended the job. However, the Nec paid no attention to it with either 1 ^D or 2 ^D's. I believe that I am onto the trail, I will say that the read operator does get the comments. I grabbed charcters one at a time and left them on the stack, and then broke with the debugger. The real whizzer seems to be concerned with <CR><LF> pairs. Apparently what is happening, is that the interpreter can't handle <CR><LF> pairs withing a readline /readstring funtion, but can handle <LF> or <CR> by them selves. After I get the data more completely analyzed, and the 17 tests put into a file, I'll post the results. But I never got Glenns code to produce anything but a white page. here is one short example /buff 30 string def currentfile buff readstring %% comments are getting throug buff ungabunga (I had the error handler loaded, and here is what I got. undefined ungabunga ( ) false () indicating that the string read in was empty. If this is truely the case then anchorsearch is not going to work. I did not get a chance (ran out of time) to test the original fragment of code, so have to set up some more tests and try it again. Now, the intersting thing is that /buff 30 string def currentfile buff readstring %%%%%%is this getting through ungabunga produced true (%%%%%%is this getting through ) while /buff 30 string def currentfile buff readstring %%%%%%is this getting through produced false () The only diffrence is a <CR><LF> pair between readstring and the %%%%%... Using debug and over writing the <CR> with a space resulted in false ( ) presumably the blank space was the space that was placed just after readstring. Changing the remaining <LF> to <CR> produced the same thing /buff 30 string def currentfile buff readstring /test 1 def %%%%%%% is this left (/test 1 def %%%%%%%is this) on top of the stack. The jury is still out, though it does appear that the readstring (readline did the same thing) operators are letting %%%%'s through, it there is ANY intervening <CR><LF> pair anywhere between the readstring and the %%%%%'s the code fails. It does not fail on the PS-810 if you put 2 ^D's at the end of the code. As you can see, I failed to test the case where the string was longer, and also failed to test the case of grabbing 3 characters at a time. Those will have to wait for later, probably next Monday, as I have to go fiddle around tomorrow night, and thursday and Fri will be out of the question as well. Cheers Woody