Hi Micahel,
You're right, "Animals" is broken again.
Lest everyone think I'm a complete moron, let me explain what's going on:
1) CLIPS' treatment of (read) and (readline) is -extremely-
context-sensitive; 2) The buffering behaviour of Java's higher-level
I/O streams change with each new release; 3) I personally rarely write
systems that use (read).
#2 is why Jess 4.1's biggest new feature is an entire new tokenization
scheme that doesn't use DataInputStream or StreamTokenizer at
all. Remember, that's what we're testing during this beta period!
#1 is the biggest problem. CLIPS treats (read) and (readline)
differently if the stream being read from is standard input as opposed
to a file. At the console, (read) actually consumes an entire line of
input (including the readline,) then keeps only the first token. In
contrast, (read) from a file finds the next token, crossing line
boundries only if needed. If the consumed token is the last token on a
line, then the following newline is LEFT ON THE STREAM, so that a
subsequent (readline) call returns an empty string.
Now, in Java, "standard input" might be System.in, or a textfield in a
GUI, or a network stream... so it's not clear how the implementation
of read is supposed to know what kind of router it's talking to. I
could special-case the 't' router, for example, I suppose; but this
would not always help. For example, if I'm writing a GUI, and I
install a new stream 'foo' connected to a GUI console, and I write
rules to explicitly read from the 'foo' router, well, than this won't
be enough.
So here's an idea that strikes me as even uglier, but which I suppose
would work: the 'addInputRouter' function gets another argument, a
boolean named 'actAsConsole'. Routers added with this flag set to true
get the console (read) behaviour; false give the file behaviour. Jess
would internally take care of this for opened files and the standard
streams, of course. I guess there'd need also to be a function
getInputRouterBehavior().
I guess that's not so bad. Thanks for giving me the chance to write
this; it was therapeutic, and I might even get it straight this time! :)
I think Michael A. Fochtman wrote:
>
> Hi all,
>
> Using Jess 41b2, I came across a problem with using read and readline.
> I'm using NT4.0, VJ++ and MS SDK 2.01, just for the record.
>
> The problem can be seen in the 'animal.clp' demo, in the rule
> 'replace-answer-node'. When the intrinsic function 'read' is called, it
> eventually gets around to calling jess.Tokenizer.nextToken(). This
> calls jess.Tokenizer.nextChar(). nextChar() correctly converts \r\n
> pairs to \n. Since \n is considered whitespace, when nextChar() returns
> that in the second loop of nextToken(), it puts the last char back by
> calling m_ios.reset() and terminates. This seems okay.
>
> My problem is, when the rule then calls 'readline', the first character
> read in is the \n put back by nextToken(). The function treats this as
> the end of the line, and returns a string of zero length. (in the
> animal.clp demo, when it asks for a question to differentiate the last
> known animal with your new animal, it completes immediately with a zero
> length question).
>
> Now it seems to me, that nextToken() is doing the right thing, by
> restoring the first whitespace character after the token. And, it seems
> reasonable for the readline method to allow entering just a newline for
> a string of zero length. So, how do I get the animal.clp demo to
> behave?? that is, get 'read' and 'readline' to work together??
>
> Or, maybe this isn't a problem with other compilers/javaVMs?? Anyone
> have this problem on other platforms, java VM?
>
> TIA
>
> Mike Fochtman
>
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (510) 294-2154
Sandia National Labs FAX: (510) 294-2234
Org. 8920, MS 9214 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list. List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
