Dear Wolfgang,

thank you very much for your reply. Also, sorry for my late response.

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}}

Ha, you obviously caught me there :) It turns out I am not using my own compilation, your code shows

def('PC':4244272 column:0 file:'/usr/staff/raph/devel/trunk/mozart/ share/lib/base/List.oz' line:76)



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.

Never mind, I found 'x-oz://system/OPIEnv.ozf' which conveniently
exports the full environment as "OPIEnv.full".


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).

Here is some code for doing this.

   local
/** %% Returns ozrc file according conventions (cf. oz/doc/opi/ node4.html).
      %% */
      fun {GetInitFile}
         if {OS.getEnv 'OZRC'} \= false
         then {OS.getEnv 'OZRC'}
         elseif {Path.exists {OS.getEnv 'HOME'}#'/.oz/ozrc'}
         then {OS.getEnv 'HOME'}#'/.oz/ozrc'
         elseif {Path.exists {OS.getEnv 'HOME'}#'/.ozrc'}
         then {OS.getEnv 'HOME'}#'/.ozrc'
         else nil
         end
      end
   in
/** %% Feeds OZRC file to MyCompiler. The OZRC is search for at the usual places according conventions (cf. oz/doc/opi/node4.html).
      %% */
      proc {FeedInitFile MyCompiler}
         InitFile = {GetInitFile}
      in
         if InitFile \= nil
         then {MyCompiler enqueue(feedFile(InitFile))}
         end
      end
   end


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.

I see: you don't want to feed the source file to the internal compiler, as it could contain errors. Anyway, if loading the OZRC to the internal compiler works find, then that should be sufficient for me for most cases :)


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.

OK. I can now confirm that your tool does indeed also find my own code. It works both if it linked with a relative path, and if I use a path starting with x-ozlib://.

However, it appears this presently only works from within a functor definition file, but not within a plain OPI file (which is probably why I did not realise it before).


BTW: I changed the key-bindings you suggested to the usual M-. (i.e., I overwrote find tag in Oz mode):

(add-hook 'oz-mode-hook
          '(lambda ()
             (local-set-key (kbd "M-.") 'oz-find-procedure-in-new-window)))



BTW: Would you like to add this tool to Collozeum? Then others could collaborate in the development.

http://gforge.info.ucl.ac.be/projects/collozeum/


Again, thank you very much for working on this tool. This has the potential of greatly increasing the productivity for writing Oz code!

Best
Torsten



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

Reply via email to