Greetings! The first compile deduces (nil fixnum) for the signature, which is then noticed as being changed by the second compile. This is correct at the current level of functionality.
Your earlier reported problem of our-getcharn is apparently due to some proclaims somewhere asserting a return type of t when the caller is compiled, but then which is overriden as return fixnum when the function is actually compiled. The easiest workaround is likely to get rid of the proclaim for our-getcharn, or to make sure our-getcharn is compiled befoe the caller in the same running image. I'm working on a more comprehensive solution. Recompiles from partially macroexpanded source stored on the plist are triggered when conflicting call signatures are loaded. Thought/suggestions on this approach always most appreciated. Its almost working here now. Take care, Robert Boyer <[EMAIL PROTECTED]> writes: > Here's a mysterious warning. > > Bob > > GCL (GNU Common Lisp) 2.7.0 ANSI May 20 2006 13:25:20 > >(defun foo () (char-code (char "abc" 1))) > (compile 'foo) > (defun foo () (code-char (char-code (char "abc" 1)))) > (compile 'foo) > > FOO > > > ;; Compiling /tmp/gazonk_22282_0.lsp. > #<compiled-function FOO> > NIL > NIL > > > > FOO > > > > ;; Compiling /tmp/gazonk_22282_0.lsp. > ; (DEFUN FOO ...) is being compiled. > >>>>>>>>>>>>>>>>>;; Warning: ret type mismatch in auto-proclamation (INTEGER > >>>>>>>>>>>>>>>>>-2147483648 > 2147483647) -> T > > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel