<div dir="ltr">Hi Peter,<div><br></div><div>thanks for the reports. I will answer them one by one below.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 5, 2013 at 7:48 PM, Peter Salvi <span dir="ltr"><<a href="mailto:salvipeter@gmail.com" target="_blank">salvipeter@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">1) CL-PPCRE<br>
===========<br>
<br>
The test suite fails, because the ~x FORMAT directive gives a<br>
lowercase string in ECL,[...]<br>
This is not limited to FORMAT, but concerns printing in general, e.g.[...]<br>
The HyperSpec (22.3.2, 22.4) does not clarify this ("For radices above<br>
10, letters of the alphabet are used to represent digits above 9."),<br>
but for the above example gives "#24rN", so I believe that's the<br>
intent.<br></blockquote><div><br></div><div style>An example is not the same thing as a rule, but in any case, since all other implementations use uppercase letters, we will do the same. Thanks for the patch.</div><div><br>

</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2) CL-NUM-UTILS<br>
===============<br>
<br>
Loading fails when a method is defined, which does not have one of the<br>
generic function's key arguments. As a simplified example, take:<br>
<br>
(defgeneric test (&key my-key &allow-other-keys) (:method (&key) t))<br></blockquote><div><br></div><div style>The list of allowed and required keys for an effective method is the combination of those from the generic function and those from each applicable method. If this key has to be supported by some method, it may add it, but deleting keys from the GF I think is wrong.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another problem arises, when a method specializes on FIXNUM, e.g.:<br>
<br>
(defgeneric test (a) (:method ((a fixnum)) t))<br>
<br></blockquote><div><br></div><div style>Puf, another non-ANSI thingy. Anyway, it is now part of ECL as well.</div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

As for the tests, they still fail, because LIFT's<br>
GET-BACKTRACE-AS-STRING is not ported to ECL.<br>
Something like this would work:[...]I've posted this to lift-devel as well.<br></blockquote><div><br></div><div style>Thanks a lot!</div><div style> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

3) CLOSER-MOP<br>
=============<br>
<br>
In ENSURE-GENERIC-FUNCTION, with (SETF GENERIC-FUNCTION-NAME) as name,<br>
and with CLOS as *PACKAGE*, execution seems to enter<br>
SPECIAL-OPERATOR-P, which should only be called with symbols.<br>
<br>
This is because the test<br>
  (si::instancep (fdefinition '(setf generic-function-name)))<br>
returns NIL, as this setter is a function in the CLOS package.</blockquote><div><br></div><div style>In fixup.lsp functions are converted into methods. I added one more line for (SETF GENERIC-FUNCTION-NAME), which is now a generic function.</div>

<div style><br></div><div style>Thanks for the great work and all the help, Peter!</div><div style><br></div><div style>Juanjo</div></div><div><br></div>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br>

<a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a>
</div></div>