Re: Delivery and MM::RECOVER-NAME-FROM-FILE

Unable to parse email body. Email id is 3201

Re: Delivery and MM::RECOVER-NAME-FROM-FILE

Hi Nick!

On Fri, 10 Dec 2004 09:40:34 GMT, Nick Levine <ndl@ravenbrook.com> wrote:

> It looks like :symbol-names-action doesn't do anything on level 4.

Yes, sorry, that was just a typo.  I should have copied my original
delivery file.

> Also, mm::recover-name-from-file only takes one argument - the
> symbol.

OK, that helped - a bit.  See below.

> Try the following:
>
> [...]

I now have this:

  (defun run ()
      (handler-case
        (progn
          (init-my-app)
          (run-my-app)
          0)
        (error (e)
          (with-open-file (s "error.txt"
                             :direction :output
                             :if-exists :supersede)
            (format s "Error message: ~A~%Symbol: ~S~%" e
                    (mm::recover-name-from-file (slot-value e 'conditions::name)))))))

  (deliver #'run "test"
           5
           :compact t
           :redefine-compiler-p nil
           :keep-symbol-names '(rdnzl::LispCallback rdnzl::ReleaseDelegateAdapter conditions::name)
           :symbol-names-action :dump
           :keep-lisp-reader t
           :console :input)

After starting my program I get this in error.txt:

  Error message: Undefined function SYSTEM::|%!/{-4-!a:| called with arguments (#S(#:!/{)).
  Symbol : "%!/{-4-!a:"

That's, cough, not much more helpful than the original message... :)

Any other ideas?

Thanks,
Edi.

Re: Delivery and MM::RECOVER-NAME-FROM-FILE

Unable to parse email body. Email id is 3203

Re: Delivery and MM::RECOVER-NAME-FROM-FILE

Unable to parse email body. Email id is 3206

Re: Delivery and MM::RECOVER-NAME-FROM-FILE

On Fri, 10 Dec 2004 11:28:01 GMT, Nick Levine <ndl@ravenbrook.com> wrote:

> I noticed that - according to your email - you hadn't compiled the
> function run.

No, it was compiled.  I once again "censored" my email in an attempt
to be brief.  Sorry for that.

> After running it, error.txt contained:
>
>     Error message: Undefined function #:!\"\" called with arguments ().
>     Symbol: "INIT-MY-APP"

That was what I hoped to see but I didn't.  However, if I use your
example it does work for me as well.

Re: Delivery and MM::RECOVER-NAME-FROM-FILE

On Fri, 10 Dec 2004 11:33:19 GMT, Nick Levine <ndl@ravenbrook.com> wrote:

> a) turn off :symbol-names-action until you've fixed all other
> problems

Yes.  I think I have fixed all other problems.  The app works fine at
delivery level 4, I just want it to be smaller.

> b) if there's a problem associated with :symbol-names-action but
> it's slow work writing handlers all over the place to call
> recover-name-from-file, then it's not too hard to access the symbols
> file from a development image and use it to convert three-character
> codes into real symbol names.

I had thought about ways to access the .syms file because it's
unreadable in a text editor.  But how would you do that?
RECOVER-NAME-FROM-FILE isn't even there in a normal image (or do I
have to require some module for it)?  And how does the function know
which .syms file I want it to look at?

Thanks,
Edi.

Re: Delivery and MM::RECOVER-NAME-FROM-FILE

Unable to parse email body. Email id is 3209

Re: Delivery and MM::RECOVER-NAME-FROM-FILE

On Fri, 10 Dec 2004 13:06:16 GMT, Nick Levine <ndl@ravenbrook.com> wrote:

> CL-USER 1 > (require "delivery")
> ;; [output from the load]
> T
>
> CL-USER 2 > (setf mm::*symbols-file* "c:/Program Files/Xanalys/LispWorks/test.syms")
> "c:/Program Files/Xanalys/LispWorks/test.syms"
>
> CL-USER 3 > (mm::recover-name-from-file "!\"\"")
> "INIT-MY-APP"

Great, thanks!  However, it still doesn't work for the particular
symbol my app is complaining about.  If I take the completely
unrelated symbol from /your/ example it works (I guess because all
three-character symbols are used) but it doesn't work for the crappy
symbol I want to know more about:

  CL-USER 1 > (require "delivery")
  ; [blablabla]
  T

  CL-USER 2 > (setf mm::*symbols-file* "c:/Documents and Settings/edi/Desktop/RDNZL Eliza 2/Eliza.syms")
  "c:/Documents and Settings/edi/Desktop/RDNZL Eliza 2/Eliza.syms"

  CL-USER 3 > (mm::recover-name-from-file "!\"\"")
  "FOREIGN-ARRAY-PTR-TESTED-VALUE"

  CL-USER 4 > (mm::recover-name-from-file "%!/{-4-!a:")
  "%!/{-4-!a:"

  CL-USER 5 > (mm::recover-name-from-file 'SYSTEM::|%!/{-4-!a:|)
  "%!/{-4-!a:"

Argh!

Further guessing: I'm using the FFI, could that be the reason for this
behaviour?  Maybe it's a gensym that's created by the compiler?  I
noticed that my app can only be delivered if I set
:REDEFINE-COMPILER-P to NIL, probably because of
FLI:DEFINE-FOREIGN-CALLABLE.

Thanks,
Edi.

Re: Delivery and MM::RECOVER-NAME-FROM-FILE

Unable to parse email body. Email id is 3211

Re: Delivery and MM::RECOVER-NAME-FROM-FILE

On Fri, 10 Dec 2004 13:36:46 GMT, Nick Levine <ndl@ravenbrook.com> wrote:

> Note that the symbol-name lookup through the symbols file works only
> for symbols with 3-character names. I think that if you give
> recover-name-from-file a symbol it can't find in the file (and
> anything longer than 3 chars will fit this description) then it
> simply returns the name it was given.
>
> Can you pursuade the compiler to compile your foreign callables
> before delivery?

It does that.  I only call FLI:MAKE-POINTER at runtime which is needed
because I have to tell the DLL I'm loading where the callback is
located.  It seems that for this step the compiler must be there?

> The symbol name you gave above looks rather long for a gensym. I
> don't think it's a result of a 3-character name mangling (because it's
> >3 chars long). I don't remember name mangling taking place post
> delivery (but it's - uhm - 8 years since this code was written and
> it may have changed several times since then). So I'm fresh out of
> ideas.

Ah, but I've now found the culprit!  I played around a little bit more
and realized that I had a call to LW:DEFINE-ACTION at runtime which
wasn't needed.  I have removed it and now it works.  Yeah!

Thanks for your help!
Edi.

Re: Delivery and MM::RECOVER-NAME-FROM-FILE

Unable to parse email body. Email id is 3214

Re: Delivery and MM::RECOVER-NAME-FROM-FILE

Unable to parse email body. Email id is 3216

Re: Delivery and MM::RECOVER-NAME-FROM-FILE

On Fri, 10 Dec 2004 14:16:38 GMT, Nick Levine <ndl@ravenbrook.com> wrote:

>    It does that.  I only call FLI:MAKE-POINTER at runtime which is
>    needed because I have to tell the DLL I'm loading where the
>    callback is located.  It seems that for this step the compiler
>    must be there?
>
> I'm unsure about the need for this. We have a couple of applications
> (only delivered at level 0, mind) in which external code quite
> happily invokes foreign-callables by name:
>
>     (fli:define-foreign-callable ("StartLisp" :calling-convention :cdecl)
>       ...)
>
> The lisp is a dll, and the invocation looks a bit like this:
>
>     [...]
>
> Not a make-pointer in sight. (Maybe your app is different in some
> other & significant way.)

I guess so.  The Lisp app is a .exe file which loads a DLL and the DLL
is supposed to call into Lisp.  I'm using the technique described here:

  <http://www1.xanalys.com/support/lisp/kbase.nsf/51fe6e1cdfe748a180256639005a2ba9/404d1bad7fe771f3802568c400540b50?OpenDocument>

Is there a better way than computing and providing the pointer at run
time?  My intuition was that the result of MAKE-POINTER before
delivery wouldn't be the same as at run time.

> Hmm. Well, define-action does all sorts of name-mangling of its own
> (try inspecting sys::*all-action-lists*). Although I _think_ your
> names are on the short side (!) to look like fallout from that, it's
> well possible as the implementation is rather ugly.

Hmmm, the only thing I'm sure of is that removing the call to
DEFINE-ACTION and leaving everything else as is made the problem with
the strange symbol go away.

Cheers,
Edi.