RE: Problem with repeatedly compiling files with partly the same content and EmbeddedEclipse

Hi Cornelius, 

Every eclipse goal which gets executed has a "caller" module. This can be
qualified explicitly by the @/2 meta predicate, e.g. 

foo(a,b) @ bar

calls predicate foo/2 *from* module bar. 

When in the tkeclipse toplevel you change the drop down module to (X), or
when in the CLI eclipse you use module(X) on the command line, you are
changing the active module. However the active module is purely a property
of the toplevel in tkeclipse/CLI eclipse. In these environments, while the
active module is X, every unqualified goal (i.e. every goal called without
@) implicitly has X as its caller module. So changing the active module to X
in these two environments is really just a convenience for "please stick '@
X' on the end of every goal I call from now until I say otherwise". 

The Java interface is not an interactive toplevel like TkEclipse/CLI eclipse
so doesn't have conveniences like this, although I seem to recall that you
can set the default module once per EclipseEngine in the EclipseOptions.
Either way, you can still use the @/2 predicate from Java's rpc as it is is
a standard eclipse builtin. This should allow you to create a module,
compile facts into it or alter its state whichever way you like, and then
erase it from another module, e.g.

[eclipse 2]: module(d).
WARNING: creating a new module in module(d)
[d 3]: module(eclipse).
[eclipse 4]: erase_module(d) @ d.
trying to erase a module from itself in erase_module(d)
Abort
[eclipse 5]: module(c).               
WARNING: creating a new module in module(c)
[c 6]: module(eclipse).
[eclipse 7]: erase_module(d) @ c.

Yes (0.00s cpu)
[eclipse 8]: 

The point is, in your case, that you don't have to compile stuff into module
'eclipse'. Hope this helps.

josh

Developer, Parc Technologies Limited
josh.singer@parc-technologies.com
http://www.parc-technologies.com

This e-mail message is for the sole use of the intended recipient(s)
-its contents are the property of Parc Technologies Limited (or its
licensors) and are confidential. Please do not copy, review, use
(except for the intended purposes), disclose or distribute the e-mail
or its contents (or allow anyone else to do so) without our prior
permission. Parc Technologies Limited does not guarantee that this
e-mail has not been intercepted and amended nor that it is
virus-free. You should carry out your own virus checks before opening
any attachment.  Any opinions expressed in this e-mail message are
those of the author and not necessarily Parc Technologies Limited.


> -----Original Message-----
> From: Cornelius Hagen [mailto:cornelius.hagen@wiai.uni-bamberg.de]
> Sent: Wednesday, March 12, 2003 5:26 PM
> To: eclipse-users@icparc.ic.ac.uk
> Subject: WG: [eclipse-users] Problem with repeatedly compiling files
> with partly the same content and EmbeddedEclipse
> 
> 
> Hi Joachim,
> 
> Thank you (and your colleages) for your advice.
> In the long run I will use queues. But now I have to stick on 
> my current
> concept.
> 
> While trying to follow the advice using erase_module/1, I still have a
> problem:
> 
> My Java-program uses an EmbeddedEcipseEngine-object for iteratively
> compiling files (containing facts and relations) and querying via the
> rpc-funciton. The first statement in each of my files is ":-
> use_module(library(ic))." But this obviously does not affect the main
> active module. Every time I want to get rid of the file 
> contents, I call
> the rpc-function with the argument erase_module(eclipse), and in the
> following call with the argument erase_module(eclipse).
> 
> I get the exception: trying to erase a module from itself in
> erase_module(eclipse), which is not surprising.
> 
> Analogously I compiled the same file in TKEclipse and got the same
> behavior. But if I change the module (drop-downlist directly below the
> File menu) everything works fine. I the source of 
> tkeclipse.tcl I could
> not find the called function that makes things work. 
> 
> Now, after lenghty explanations, my question: 
> How can I change the active module (didn't find a suitable 
> predicate in
> the documentation)? Or where am I wrong?
> 
> Thanks in advance
> 
> Cornelius
> 
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: owner-eclipse-users@icparc.ic.ac.uk
> [mailto:owner-eclipse-users@icparc.ic.ac.uk] Im Auftrag von Joachim
> Schimpf
> Gesendet: Donnerstag, 30. Januar 2003 14:34
> An: Eclipse Users List
> Betreff: Re: [eclipse-users] Problem with repeatedly compiling files
> with partly the same content and EmbeddedEclipse
> 
> 
> > Cornelius Hagen wrote:
> >
> > I am writing a Java-application that iteratively poses requests on
> > eclipse. Because I need good performance, I use an
> EmbeddedEclipse-object following the mapcolorour-example. I always
> create a file which usually contains some predicates as the
> > file(s) before (and, of course, some different ones).
> 
> If you need good performance then
> 
> 1. don't use files. File I/O is slow. Instead send the
>    data via a queue like in the mapcolour example.
> 
> 2. dont compile your data as predicates unless you really
>    need them to be predicates. Compilation takes time.
>    Just write your request data (e.g. in the form of a list)
>    into a queue on the Java side, and read it out using
>    read_exdr/2 on the Eclipse side. If you absolutely
>    want to compile predicates, you can still do that
>    using compile_term.
> 
> 
> > Then I hand over the file to the rpc function.
> > Eclipse sends warnings, that some relations habe been 
> replaced by new
> > ones with the same signature, and after a few iterations,  I get a 
> > "Throw"-Exception thrown by the rpc method.
> 
> If you don't compile, you won't get these warnings :-)
> 
> Other ways to suppress the warning are:
> - abolish/1 the predicate before recompiling, or use
>   erase_module/1 as already suggested
> - disable the warning via :- set_event_handler(145,true/0).
> 
> 
> -- 
>  Joachim Schimpf              /             phone: +44 20 7594 8187
>  IC-Parc                     /      mailto:J.Schimpf@imperial.ac.uk
>  Imperial College London    /    http://www.icparc.ic.ac.uk/eclipse
> 
> 
> 
>