Dear Wolfgang,
thank you very much for this contribution (and sorry for my late
reply). I played around with your code navigator.
After I specified the pathes to the Mozart sources on my machine with
the option --replace (just using a self-compiled Mozart did not
work), your software amazingly found the definition of various Oz
primitives -- even if they were defined in the source as anonymous
procedures, like Record.map. Great!
You discuss some limitations and offer some troubleshooting in your
README file. However, I don't quite understand the limitations yet.
I assume that the tool internally uses some compiler with the default
environment. Therefore, procedures like Map are seen, because these
are available by default to a compiler. Other procedures, however,
are not seen: the tool responds "ERROR: cannot find procedure" for
procedures like Value.'=<' and Number.'+'. 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".
I don't quite understand yet why some procedures work and others
don't and how I could help the tool to find source. I understand that
the tool makes use of the environment defined in the present file.
For example, the tool will not find Regex.search by default, but it
works in a functor file which imports Regex. Also, it works in the
OPI if I have a call
[Regex] = {Module.link ['x-oz://contrib/regex']}
within the same file. Great!
However, why result so many procedures in "ERROR: source for built-in
procedure not available". Is this the case for all Oz procedures
which are actually defined in C++ (as FD.decl)? Are there further cases?
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.
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?
This brings me to another question. I found out that Module.link
works fine, but the variant I am using does not (see below). I want
ModuleLink behave completely declarative: if I call it multiple times
(e.g., because I work with multiple files which are not functors) I
always want to link the _same_ functor, and not a new copy where all
stateful entities within the functor are new copies. Actually, I feel
Module.link should behave this way, and when the user wants to create
multiple module managers she should do this explicitly -- not the
other way round as it is now. Anyway, with the following at the top
of my file your tool did not find Regex.search, and I don't
understand why.
local
ModMan = {New Module.manager init}
in
/** %% ModuleLink is like Module.link except that multiple calls
of ModuleLink share the same module manager (and don't create new
managers as Module.link does). For instance, when ModuleLink links
multiple functors which refer to a stateful datum in some functor,
then all refer to the same datum instance. By constrast, linking with
Module.link results into multiple stateful datum instances.
%% */
fun {ModuleLink UrlVs}
{Map UrlVs fun {$ Url}
{ModMan link(url:Url $)}
end}
end
end
[Regex] = {ModuleLink ['x-oz://contrib/regex']}
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?
Again, thanks a lot for your contribution, and sorry for such a long
mail.
Best
Torsten
On Feb 26, 2008, at 8:06 PM, Wolfgang Meyer wrote:
Dear all,
inspired by the "Improving the Emacs OPI" thread on the hackers
list, I
implemented some basic code navigation for Oz.
The implementation is based on the "Debug.procedureCoord" function
which
already does most of the work. Consequentially, my implementation only
works with procedures and functions, not with classes and methods.
Download: http://oz-code.googlecode.com/files/CodeNavigation.zip
See the README file for details and installation instructions.
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
