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
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
