Re: [eclipse-users] Library Induction

That was helpful. That change recognized use_module/3. Theres another
problem though:

 while executing the statement :
                    :- multifile prolog:message/3.

I get the error:
-----------------------------------------------
WARNING: declaring multifile procedure(s) as dynamic in multifile
prolog : message / 3

not a module in dynamic message / 3
-----------------------------------------------

The above statement is followed by a definition of a message/3
predicate. But no predicate
is defined as dynamic. Whats this?

Thanks
Siddharth



On 4/25/07, Kish Shen <kish.shen_at_crosscoreop.com> wrote:
> On Thursday 26 April 2007 03:24, Siddharth Angrish wrote:
> >            Thanks for the previous comments. I have the following
> > queris/points to make:
> >
> > 1) As per your suggestion I am installing sicstus on my machine and
> > paralelly try to
> > see if there some advantages.
> >
> > 2) During FSA6 installation, the type of Prolog available on machine is asked.
> > The fsa_library and other supporting libraries are generated
> > afterwards. It appears
> > that FSA6 generates all its libraries according to the Prolog
> > available. Hence, FSA6
> > might be treating all Prologs as same.
> >
> > 3)   I have installed ECLiPSe 5.10 on my machine. I noticed this
> > peculiar thing, the path
> >   had to be encloed in "`", that is, backticks rather than double
> > quotes while in previous
> > ECLiPSe double quotes were used. Is this some fancy change or I am
> > seeing strange
> > behaviour?
>
> This is not a change in ECLiPSe 5.10, but instead is because you loaded lib(swi), and what you
> see is the SWI syntax:
>
> In ECLiPSe, strings are enclosed in double quotes: "string", but in most other Prologs, this
> represents a list of numbers, where each number represents the ASCII value of the characters
> in the string. When you load lib(swi), ECLiPSe is switched to using this representation, so
> you can no longer use double quotes to represent strings.
>
> In SWI, strings are represented using the backquotes character you mentioned, and once you
> loaded (imported) lib(swi), the module you are using supports this syntax as well.
>
>
> > I used the following command:
> >   get_flag(library_path,Path),
> >         set_flag(library_path, [`/users/angrish/fsa/fsa6/swi` | Path]).
> >
> > 4)  The above added path has all the required libraries. After adding
> > this path I get the
> > following error upon executing lib(fsa_library):
> > --------------------------------------------
> > lib(fsa_library).
> > calling an undefined procedure use_module(charsio, [format_to_chars /
> > 3]) in module eclipse
> >
> > *** compilation aborted
> >         before line 24 in the file /users/angrish/fsa/fsa6/swi/fsa_library.pl
> > Abort
> > ---------------------------------------------
> >
> > This appears to be due to incompatibility between ECLiPSe and SWI Prolog.
>
> Yes.
>
> > What are the possible remedies for this? Shall I try changing this paticular
> > "use_module" to the one compatible with ECLiPSe. There a total of 35 such usages
> > in all the libraries.
>
> A proper fix would be to use ensure_loaded/1 followed by import/1 (import ... from ...).
>
> However, this is one thing that could (should?) be supported by lib(swi) -- the use_module/2
> syntax is supported by lib(quintus) and lib(sicstus), so it probably should be supported by
> lib(swi) as well.
>
> I think you can add support for use_module/2 to your copy of swi.ecl, by adding use_module/2
> to the list of predicates exported from the quintus module. Change
>
> :- reexport
>         (multifile)/1, op(_,_,(multifile)),
>         format/2,
>         format/3
>     from quintus.
>
> to
>
> :- reexport
>         (multifile)/1, op(_,_,(multifile)),
>         use_module/2,
>         format/2,
>         format/3
>     from quintus.
>
> in the swi.ecl file. If you have a binary distribution, this file is in <ECLiPSe>/lib/swi.ecl. You
> also need to remove the compiled swi.eco file in the same directory, so that swi.ecl will be
> loaded instead of swi.eco, which is the compiled form of the original swi.ecl file (i.e. without
> the above change).
>
> >       What I am afraid of is if after this change I run into more such
> > incompatibilites?
> > Is there some cheaper way?
> >
>
> You may very well run into more incompatibilities, some of which may be things (like
> use_module/2) that can be easily added to lib(swi).
>
> Cheers,
>
> Kish
>