Re: Code navigation in Emacs

Thu, 13 Mar 2008 10:37:09 -0700 

Dear Torsten,

I will release a new version really soon now where this problem is fixed.
In my current code, I do not use lookupInEnv anymore, but something like this: 

Environment = {OPICompiler enqueue(getEnv($))}
in
{CondSelect Environment Id nothing}

This works much more reliable.

Cheers,
Wolfgang


Torsten Anders wrote:

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



_________________________________________________________________________________
mozart-users mailing list                               
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users






















					Reply via email to