[PPL-devel] Re: Problems with XSB 2.7.1

[Terrance Swift]

Its pretty easy to comment out. Here's probably what is the safest
way to do it. Simply go to  $XSB_PATH/syslib and copy
std_xsb.xwam to std_xsb.xwamsav  Then comment out the line

standard_symbol(flush_output,1,file_io).

in std_xsb.P, load xsb, and type

| ?- compile(std_xsb).

This should succeed, and future sessions of xsb will use the modified
library file. So just halt and reinvoke.

Terry Swift

On Fri, 1 Jul 2005, Roberto Bagnara wrote:

> Terrance Swift wrote:
> > First, thank you Roberto for your help and patience in finding a bug.
> > I was away from email this morning, which I guess was fortunate for me
> > in that you and David did the work in isolating problematic behavior.
> >
> > There are actually two issues.  The first is that if you call
> > flush_output/1 with an atom that is not an alias it fails silently,
> > rather than raising an exception.  This is a bug.
> >
> > The second is the use of user_output as an alias for the current
> > output stream.  I had been under the impression that the ISO standard
> > used user_out rather than user_output, but I should recheck my copy (I
> > dont have it with me for the weekend, and it doesn't seem to be
> > available on line).  However, since other Prolog's support user_output
> > (at least Sicstus does) I should also include user_output and
> > user_input as aliases.
>
> They are indeed specified by the ISO standard: 7.10.2.2 and 7.10.2.3,
> page 55.
>
> > I'll make the fixes in sourceforge this afternoon.  It may require
> > changes to a couple of files.
> >
> > As a workaround, you can 1) check out XSB from sourceforge under
> > anonymous CVS (after I make the changes) or 2) use one of these in
> > your code
> >
> > | ?- flush_output(userout).
> > | ?- flush_output(user_out).
> > | ?- flush_output.
> >
> > or 3) undefine flush_output/1 as a standard predicate in your copy of
> > XSB (easy, and I can tell you how to do this if this is what
> > you want to do).
>
> I think (3) is the best option for me.  In fact, the users involved
> are unlikely to want to use a non-official release, which rules out
> (1), while (2) would require me to change the system-independent part
> of my code.
> So, if you teach me how to implement (3), I have the temporary
> workaround I was looking for.
> Many thanks,
>
>      Roberto
>
> > Terry Swift
> >
> >
> >
> >
> > On Fri, 1 Jul 2005, Roberto Bagnara wrote:
> >
> >
> >>David Warren wrote:
> >>
> >>>You've enabled more debugging than I ever have...  It gets through the
> >>>compilation of the emulator, but then fails as it begins to recompile
> >>>the prolog compiler.  It seems to have completed compilation of the
> >>>first file, so you've gotten reasonably far into the XSB code.  THis
> >>>means it is most likely not the tagging scheme, with which we formerly
> >>>had problems under fedora.
> >>>
> >>>It looks like here it may have something to do with file i/o?  What if
> >>>you try to execute other simple files with this emulator?  I.e., just
> >>>try to use this emulator to execute something simple.
> >>>
> >>>Going back to the original system, did you configure it (before trying
> >>>to enable debugging)?  Did it get through the recompilation of the
> >>>prolog compiler and system directories?  If so, then this seems to be
> >>>a problem with the debug configuration.  If we go back to the original
> >>>problem of a loop in some code that ought to run, where was that loop?
> >>> Could we trace or instrument that original program to try to see
> >>>where the loop was?  Or was it so early, you couldn't find it in the
> >>>Prolog code?
> >>>
> >>>So, to summarize.  It might be the debugging code that is causing the
> >>>problem here, and it may be easier (or may not) to go back to the
> >>>original nondebugging version to try to see what's going on there.  If
> >>>it getting into Prolog code, it might be easier to try to track down
> >>>the loop using Prolog tracing or other Prolog techniques.
> >>
> >>Dear David,
> >>
> >>you are right: the one I reported is probably a bug concerning
> >>the debugging options.  The problem was that my code makes heavy
> >>use of the foreign language interface and with the optimized version
> >>I was unable to understand where the problem occurred.
> >>
> >>Now I have configured XSB with
> >>
> >>   ./configure --prefix=/usr/local/lib/xsb --enable-debug  --disable-optimization
> >>
> >>and this gave me the possibility to ascertain that my problem was
> >>in the Prolog part.  Everything boils down to the fact that the
> >>query
> >>
> >>     ?- flush_output(user_output).
> >>
> >>silently fails.  This is strange, because flush_output/1
> >>is an ISO builtin, user_output is, in ISO Prolog, an alias
> >>for the user output stream.
> >>
> >>Passing from XSB 2.6 to 2.7.1 I was brought to remove my
> >>definition
> >>
> >>:- import file_flush/2 from file_io.
> >>
> >>flush_output(user_output) :-
> >>   file_flush(0, _).
> >>
> >>because of the error
> >>
> >>++Error[XSB]: [Compiler] Trying to redefine the standard predicate: flush_output/1
> >>The file ./xsb_clpq.xwam is removed
> >>Aborting...
> >>
> >>I thought: "cool, they have incorporated more ISO features!"
> >>What am I doing wrong?
> >>Many thanks,
> >>
> >>      Roberto
> >>
> >>--
> >>Prof. Roberto Bagnara
> >>Computer Science Group
> >>Department of Mathematics, University of Parma, Italy
> >>http://www.cs.unipr.it/~bagnara/
> >>mailto:bagnara at cs.unipr.it
> >>
> >>
> >>-------------------------------------------------------
> >>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> >>from IBM. Find simple to follow Roadmaps, straightforward articles,
> >>informative Webcasts and more! Get everything you need to get up to
> >>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> >>_______________________________________________
> >>Xsb-development mailing list
> >>Xsb-development at lists.sourceforge.net
> >>https://lists.sourceforge.net/lists/listinfo/xsb-development
>
>
> --
> Prof. Roberto Bagnara
> Computer Science Group
> Department of Mathematics, University of Parma, Italy
> http://www.cs.unipr.it/~bagnara/
> mailto:bagnara at cs.unipr.it
>