Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!chinacat!woody From: woody@chinacat.Unicom.COM (Woodrow Baker) Newsgroups: comp.lang.postscript Subject: nec 800/890 Keywords: tests Message-ID: <1574@chinacat.Unicom.COM> Date: 12 Sep 90 06:45:33 GMT Organization: a guest of Unicom Systems Development, Austin Lines: 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 pairs. Apparently what is happening, is that the interpreter can't handle pairs withing a readline /readstring funtion, but can handle or 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 pair between readstring and the %%%%%... Using debug and over writing the with a space resulted in false ( ) presumably the blank space was the space that was placed just after readstring. Changing the remaining to 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 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