Dear Wolfgang,
I tried to extend your code navigation tool, but I cannot get it
working. Whenever I extend or replace the environment of your
internal compiler, then I obviously break your tool completely -- it
does not find anything anymore.
More specifically, I try to edit your procedure
LookupInStandardEnvironment (in ProcedureFinder.oz). With your
original version, finding standard procs like Map works, but very
many procs are not found. So, I tried simply extending the
environment of the compiler created by LookupInStandardEnvironment.
For example, I imported OPIEnv at 'x-oz://system/OPIEnv.ozf' and
extended your procedure to the following.
fun {LookupInStandardEnvironment Id}
Engine = {New Compiler.engine init}
in
%% NEW: add OPI environment
{Engine enqueue(putEnv(OPIEnv.full))}
try
Result = {Engine enqueue(lookupInEnv(Id $))}
in
%% lookupInEnv has a bug: it does not return if the name is not
found
{WaitAtMost Result 50}
if {IsDet Result} then just(Result) else nothing end
catch _ then
nothing
end
end
As a result, your tool did not find anything anymore, not even Map
("Error: cannot find procedure"). Any idea why this little change
completely breaks your tool? BTW: I noticed that the behaviour
(always "Error: cannot find procedure") occurs also when I remove
your line {WaitAtMost Result 50}. Why is it necessary to limit the
time for processing a request? When I try lookupInEnv in the OPI, it
seems to work fine.
declare
[OPI] = {Module.link ['x-oz://system/OPI.ozf']}
%% returns Map
{OPI.compiler enqueue(lookupInEnv('Map' $))}
%% throws an exception
{OPI.compiler enqueue(lookupInEnv('Foo' $))}
%********************** compiler engine error *******************
%**
%** undeclared variable Foo
%**
%** Query: lookupInEnv('Foo' _<optimized>)
When does the bug concerning lookupInEnv you mention in the code occur?
Thank you!
Best
Torsten
On Mar 1, 2008, at 1:02 PM, Wolfgang Meyer wrote:
Dear Torsten,
thanks a lot for your feedback!
I will discuss your questions and the bugs you found below:
(just using a self-compiled Mozart did not work),
I did not test this myself but I'm a bit surprised because my tool
just
exploits the source location information that the Oz compiler puts
into
the compiled functors.
Could you please execute the following code in the OPI and tell me
what
it shows:
declare
[Debug] = {Module.link ['x-oz://boot/Debug']}
in
{System.show {Debug.procedureCoord Map}}
Other procedures, however, are not seen: the tool responds "ERROR:
cannot find procedure" for procedures like Value.'=<' and Number.'+'.
There is a problem with single quotes. The Emacs lisp function
"current-word" does not like them. I will fix this.
It responds "ERROR: source for built-in procedure not available" for
procedures like Value.toVirtualString, New and FD.decl. Also,
String.tokens works whereas String.toAtom results in "ERROR: source
for built-in procedure not available".
Indeed: The source code for native (C++) procedures like
Value.toVirtualString cannot be found with my tool. For such
procedures,
Debug.procedureCoord throws a type error exception.
I don't think there is an easy way around this. At least not without
integrating a full-blown C++ parser ;-)
I will change the error message to make this more clear.
Also, many functors which are usually available in the OPI are not
seen by the tool. Could we perhaps extend the environment of your
internal compiler? Actually, I already tried to do that, but then I
ran into weird emacs behaviour opening files in dir mode. Still, I
can
offer some code which imports everything available in the OPI.
That would be cool and I agree that the environment should be
extended.
Is this code available online somewhere?
Emacs opening files in dir mode usually means that the tool crashed.
To see the actual error message, you can comment out both calls to
"(kill-buffer nil)" in the find-procedure Lisp code and then switch to
the "TEMP" buffer in Emacs.
Moreover, I would like to be able to extend the environment in some
configuration file -- would it be possible to load the OZRC file into
the internal compiler, so that everything I usually import is seen by
the compiler?
Yes, I will implement this (should be easy).
This brings me to another question. I found out that Module.link
works
fine, but the variant I am using does not (see below).
Module.link works because of a simple hack: The program searches
for the
regex
"\\["#OptSpace#Functor#OptSpace#"\
\]"#OptSpace#"="#OptSpace#"{"#OptSpace#"Module.link"#Space#"\\
["#OptSpace#"(\"|')[^\"']+(\"|')"#OptSpace#"\\]"#OptSpace#"}"
If you change it to
"\\["#OptSpace#Functor#OptSpace#"\
\]"#OptSpace#"="#OptSpace#"{"#OptSpace#"(Module.link|
ModuleLink)"#Space#"\\["#OptSpace#"(\"|')[^\"']+(\"|')"#OptSpace#"\
\]"#OptSpace#"}"
it should work (in function FindDynamicallyLinkedModule).
It would be nice to make this more general/configurable but I'm not
yet
sure how to do that.
Finally, I am usually using Oz procedures defined in functors from
various (sub-)projects. Your README says that functors which are not
part of Mozart itself must be linkable from within the current
dictionary. I understand that it is currently not possible to link
such functors with addresses like 'x-ozlib://...'. What is the reason
for that -- is there a principle problem?
That's a misunderstanding. I referred to functors which are linked
with
a relative URL. I will update the README.
Accessing functor with URLs like 'x-ozlib://...' should work fine.
ProcedureFinder.oz simply calls Module.link with the given functor URL
and accesses the exported procedures to feed them to
Debug.procedureCoord. So every functor which is normally found with
Module.link should be found by the tool, too.
Cheers,
Wolfgang
______________________________________________________________________
___________
mozart-users mailing list mozart-
[EMAIL PROTECTED]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
--
Torsten Anders
Interdisciplinary Centre for Computer Music Research
University of Plymouth
Office: +44-1752-233667
Private: +44-1752-558917
http://strasheela.sourceforge.net
http://www.torsten-anders.de
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
