Re: U+FFFF

On 1/08/2013, at 1:06 PM, 申远 wrote:

> It is the JTransformer you mentioned.

(Why the **** do people insist on using Eclipse?  I've no objection to people
 using tools in Eclipse if they want to.  I have major objections to being forced
 to use Eclipse in order to use a tool.  I have Emacs.  I have Xcode.  I have
 NetBeans.  Why do I need yet another monster IDE that I don't know how to drive
 just in order to analyse some programs?)

> When I was processing the .pl file,making it runnable on tu-prolog, I met the U+FFFF. I chose just ignore the U+FFFF, and it has worked all right until now. As I said before, the U+FFFF existed after I had export factbase in a GUI. I have no idea how this generated, so there is nothing I can do except ignoring it.

1.  You MUST tell the JTransformer people about this bug in their software.

2.  While you are waiting for them to do something about it, you can start
    by finding out *where* it is.

    - Is there only one of it, or are there many?
      (If many, read "Are they" for "Is it" below.)
    - Is it at the end of the output?  Maybe processing should stop there.
    - Is it inside a comment?  Maybe it should be ignored.
    - Is it between two Prolog tokens?  Maybe it should be turned into space.
    - Is it inside a Prolog token?  If so, is it a string, an atom, or
      something else?
      - What property of the Java source code does the defective token
        refer to?
        - Does it refer to a Java identifier?  What identifier?
	- Does it refer to a Java comment?  What comment?
	  Does that Java comment contain a U+FFFF?
	  Can you remove it from the Java source code?
        - Does it refer to a Java character or string literal?  Which?
	  Would it work if U+FFFF was changed to \xFFFF\ in the Prolog
	  code?
	- Does it refer to something else?  If so, what?
      - Is the U+FFFF *consistently* present?  That is, supposing the
	source code has "foo\uFFFFbar" twice.  Is it converted as
	"foo<FFFF>bar" every time, or is it sometimes "foo\xFFFF\bar"?

3. Some of these reflect a situation where SWI's default action with this
   noncharacter is fine, so you could just run SWI Prolog in a UNIXProcess
   to convert the .pl file into something tuprolog is happy with.

   Some of them reflect a situation where the right immediate response is
   to fix the Java source code.

   If the FFFF is not consistently present, you might HAVE to take action
   in order to compute the correct results.

   I *suspect* that the issue is a U+FFFF in a Java string literal (or
   _maybe_ a comment), which raises the issue of whether the Java source
   code is correct or not.  If there is an actual U+FFFF in the Java
   source code, the Java source code is definitely illegal.  If there is
   a \uFFFF in a string or character literal, it's legal but highly
   questionable Java, and there's a bug in the way JTransformer writes it.
   JTransformer source code is available, so you could probably fix it.

I don't know anything about tuprolog.  Have you looked at JekeJeke Prolog?


_______________________________________________
SWI-Prolog mailing list
[email protected]
https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog