Re: [Ecls-list] Large set of changes (~29 commits)
On Sun, Dec 2, 2012 at 4:22 AM, Matthew Mondor mm_li...@pulsar-zone.netwrote:
On Sun, 2 Dec 2012 01:09:15 +0100
Juan Jose Garcia-Ripoll juanjose.garciarip...@gmail.com wrote:
Last week I got a bit mad trying to read out the C code generated by ECL
and so I decided to clean it up a bit. The result is a rather large set
of
patches which are being uploaded as I write. Testing of these patches
will
proceed in the following days, but I expect no major divergences.
I'll have to look at this, as I frequently looked at the C code
Please report any thing you find odd about it, such as unoptimized or weird
C code.
The extra labels and gotos were of course optimized out by GCC,
Hopefully, but ECL works with a variety of compilers and I am not sure it
always performed so well. Analysis of code becomes cumbersome in that
situation.
various utility macros in the public interface
to setup exception frames etc, but the C generated code didn't use
those macros.
Yes, it would be nice to use those macros now that the code is indented,
but before it did not make much sense. Note also that the macros are not
always as good as the generated C code (which may for instance save unused
branches in CATCH, UNWIND-PROTECT, etc.
One thing which at first surprised me were these macros expanded from
the corresponding eclh like { VT1 VLEX1 CLSR1 STCK1 ...
This is a very old artifact dating back to KCL to be able to output the
function declarations _after_ the body of the function has been built. Will
be fixed soon.
The other thing that I remember is that when the code refers to data,
via VV and an offset within a huge array,
Noted.
Another possibility would be to have multiple data
arrays, which perhaps might also mitigate the issue when using inline
constants vs the 64K limit of the Microsoft compiler?
I recall having tried this in the past.
Not that any of this really matters however, they're very low priority
things.
If you need to analyze the generated code it becomes quite important after
some time.
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
--
Keep yourself connected to Go Parallel:
DESIGN Expert tips on starting your parallel project right.
http://goparallel.sourceforge.net/___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Large set of changes (~29 commits)
On Sun, Dec 2, 2012 at 9:43 AM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@gmail.com wrote:
One thing which at first surprised me were these macros expanded from
the corresponding eclh like { VT1 VLEX1 CLSR1 STCK1 ...
This is a very old artifact dating back to KCL to be able to output the
function declarations _after_ the body of the function has been built. Will
be fixed soon.
These macros have disappeared. They are now replaced with actual C
declarations, but in functions and in the toplevel forms.
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
--
Keep yourself connected to Go Parallel:
DESIGN Expert tips on starting your parallel project right.
http://goparallel.sourceforge.net/___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] slime-edit-definition does not work perfectly with ECL
On Fri, Nov 30, 2012 at 1:31 PM, Stanislav Frolov frolosof...@gmail.comwrote: slime-edit-definition foo - No known definition for: foo The expected behavior - move cursor to start of (defun foo... https://sourceforge.net/p/ecls/bugs/220/ Thanks for reporting -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net/___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL Closer-mop
Hi, OK, I can report a success: All my test cases run through now (almost, see below ;). However, there are still some remaining bugs: 1) extract-specializer-names is not correct for eql specializers. Consider: (extract-specializer-names '((s (eql 's = ((EQL S)). However, the result should be ((EQL 'S)), the quote should not be removed! 2) When an accessor method is initialized, it should be passed a :slot-definition argument to the slot it is supposed to access. This doesn't seem to happen. 3) When ADD-METHOD has to remove a method because of agreeing on specializers and qualifiers with the new method, it is specified to do so by invoking REMOVE-METHOD rather than by doing it by itself. However, this doesn't seem to be the case. 4) DEFMETHOD doesn't call MAKE-METHOD-LAMBDA to determine the method function body. [My guess is that this is not easy to change due to the deviation from the MOP specification in how method functions are called.] 5) (setf generic-function-name) is specified to invoke reinitialize-instance to do its job, rather than doing it by itself. However, this doesn't seem to be the case. 6) Many of the metaobject classes expose slots with names that are exported from some package or visible in CL-USER. This shouldn't be the case. (See Restrictions on Implementations in the MOP specification.) Most of these should be very easy to fix (except for 4 probably). I could do most of them (except for 4 and 6) in Closer to MOP, but I guess it's better if you do them directly in ECL. Depending on how we agree, my internal development version of Closer to MOP for the next ECL is ready to be released. Please give me a sign when I should do that. [I will skip support for the 12.7.1 because that is too much work and will be only of temporary value.] Pascal On 26 Nov 2012, at 23:35, Juan Jose Garcia-Ripoll juanjose.garciarip...@gmail.com wrote: On Mon, Nov 26, 2012 at 7:38 PM, Pascal Costanza p...@p-cos.net wrote: I don't think the HyperSpec allows for that interpretation. The entry for slot-value is specific that slot-unbound is called when a slot is unbound, and the entry for slot-unbound specifies that the default method signals an error of type unbound-slot. There are no exceptions specified for unsafe code. This is actually important, since the whole slot-unbound and slot-missing protocols can be used to define reasonable semantics, for example to define hash-table-based slots, and user code needs to be able to rely on the correct workings of user-defined extensions here even for unsafe code. As I said, this optimization is taking place only for accessors over standard classes. In any case I have deactivated it because again we run into the eternal two problems that cannot be solved without dynamic recompilation: 1) users might define methods with the same name over their own classes, even for the accessors that are defined in the CL package. 2) as discussed in the pro mailing list, it is a nightmare to determine the actual class of an accessor argument -- the type declaration names only the parent class, but user's subclasses might not fullfil the same contracts as their parents. It is really a nightmare trying to introduce any optimization with MOP around. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- Pascal Costanza -- Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net/___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL Closer-mop
On Sun, Dec 2, 2012 at 9:11 PM, Pascal Costanza p...@p-cos.net wrote: 4) DEFMETHOD doesn't call MAKE-METHOD-LAMBDA to determine the method function body. [My guess is that this is not easy to change due to the deviation from the MOP specification in how method functions are called.] I will look into the other issues, but this is definitely not true. In ecl/src/clos/method.lsp, line 82, ... (multiple-value-bind (fn-form options) (make-method-lambda generic-function method lambda-form env) (when documentation (setf options (list* :documentation documentation options))) (multiple-value-bind (wrapped-lambda wrapped-p) (simplify-lambda name fn-form) ... ECL calls make-method lambda and then looks at the output to see whether it can be transformed into the C-optimized dispatch that we use. It would be important to have a test case that shows when make-method-lambda is not working. What in particular made you think so? Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net/___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL Closer-mop
On 2 Dec 2012, at 22:48, Juan Jose Garcia-Ripoll juanjose.garciarip...@gmail.com wrote: On Sun, Dec 2, 2012 at 9:11 PM, Pascal Costanza p...@p-cos.net wrote: 4) DEFMETHOD doesn't call MAKE-METHOD-LAMBDA to determine the method function body. [My guess is that this is not easy to change due to the deviation from the MOP specification in how method functions are called.] I will look into the other issues, but this is definitely not true. In ecl/src/clos/method.lsp, line 82, ... (multiple-value-bind (fn-form options) (make-method-lambda generic-function method lambda-form env) (when documentation (setf options (list* :documentation documentation options))) (multiple-value-bind (wrapped-lambda wrapped-p) (simplify-lambda name fn-form) ... ECL calls make-method lambda and then looks at the output to see whether it can be transformed into the C-optimized dispatch that we use. It would be important to have a test case that shows when make-method-lambda is not working. What in particular made you think so? Here is a test case: (use-package :clos) T (defclass my-generic-function (standard-generic-function) () (:metaclass funcallable-standard-class)) #The CLOS:FUNCALLABLE-STANDARD-CLASS COMMON-LISP-USER::MY-GENERIC-FUNCTION (defgeneric f (x) (:generic-function-class my-generic-function)) #my-generic-function F (defmethod make-method-lambda :after ((gf my-generic-function) (method standard-method) (lambda-expression t) (enviroment t)) (print :foo)) #standard-method MAKE-METHOD-LAMBDA (#The CLOS:FUNCALLABLE-STANDARD-CLASS COMMON-LISP-USER::MY-GENERIC-FUNCTION #The STANDARD-CLASS STANDARD-METHOD #The BUILT-IN-CLASS T #The BUILT-IN-CLASS T) (defmethod f ((x integer)) (+ x x)) #standard-method F (#The BUILT-IN-CLASS INTEGER) Pascal -- Pascal Costanza -- Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net/___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL Closer-mop
On Sun, Dec 2, 2012 at 11:00 PM, Pascal Costanza p...@p-cos.net wrote: Here is a test case: Thanks. The problem seems to be that make-method-lambda and defmethod live in the same file and the function call was done through a pointer, not through the symbol. I will upload a fix. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net/___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL Closer-mop
On Sun, Dec 2, 2012 at 9:11 PM, Pascal Costanza p...@p-cos.net wrote: OK, I can report a success: All my test cases run through now (almost, see below ;). Thanks once more for all your work on these issues. I really appreciate the effort that it implies. 1) extract-specializer-names is not correct for eql specializers. Consider: (extract-specializer-names '((s (eql 's = ((EQL S)). However, the result should be ((EQL 'S)), the quote should not be removed! Fixed in git/CVS. Will upload it tonight. 2) When an accessor method is initialized, it should be passed a :slot-definition argument to the slot it is supposed to access. This doesn't seem to happen. Fixed also. 3) When ADD-METHOD has to remove a method because of agreeing on specializers and qualifiers with the new method, it is specified to do so by invoking REMOVE-METHOD rather than by doing it by itself. However, this doesn't seem to be the case. The early versions of ADD- and REMOVE-METHOD lived in the same file. They were calling each other, but not the generic function version. Fixed. 4) DEFMETHOD doesn't call MAKE-METHOD-LAMBDA to determine the method function body. [My guess is that this is not easy to change due to the deviation from the MOP specification in how method functions are called.] Same as in 3) 5) (setf generic-function-name) is specified to invoke reinitialize-instance to do its job, rather than doing it by itself. However, this doesn't seem to be the case. Thanks, I had overlooked that generic-function-name names just a reader, not an accessor. 6) Many of the metaobject classes expose slots with names that are exported from some package or visible in CL-USER. This shouldn't be the case. (See Restrictions on Implementations in the MOP specification.) I will fix this along the coming days. It requires a bit more work to compute the list of offending slots and ensuring I do not screw everything in other parts of ECL. But this should not be a stopper for the release of Closer-mop, is it? [I will skip support for the 12.7.1 because that is too much work and will be only of temporary value.] I did not expect you to do that. 12.12 should be released any time soon, once these issues are solved and I verify the Windows ports. Thanks again. Cheers, Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net/___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] Merging asdf-bundle into asdf
I haven't heard any objection to my plan of merging asdf-bundle into asdf, but I have not any actively supporting mention either — just the fact that it will moderately enhance the lives of Quicklisp, ECL and MKCL maintainers. I'm leaving you a few more days to send me feedback before I actually do it. In the meantime, I added a precompiled-system feature to asdf-bundle. You can distribute a library as fasl-only, by first (1) compiling it with fasl-op on your build image: (asdf:operate 'asdf::fasl-op :my-library) Then copying the output file (first (asdf:output-files (make-instance 'asdf::fasl-op) (asdf:find-system :my-library)) to some destination of your choice. (2) in your user's image, have a .asd that looks like that, or better, evaluate the form as part of your initialization, without the need for a .asd: (defsystem :my-library :class :precompiled-system :fasl #p/path/to/my-library.system.fasl) The fasl argument can be a logical pathname or an expression that will be evaluated later. This way, user libraries can use defsystem :depends-on and find the library whether its source is present or whether a .fasl was made available. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org We are always in anarchy. But we pay a hefty price maintaining the illusion that we aren't, and another one being misled by the illusion. On Thu, Nov 29, 2012 at 9:50 PM, Faré fah...@gmail.com wrote: On Thu, Nov 29, 2012 at 11:18 AM, Juan Jose Garcia-Ripoll juanjose.garciarip...@gmail.com wrote: On Thu, Nov 29, 2012 at 2:41 PM, Faré fah...@gmail.com wrote: Now, do we want to distribute asdf-bundle.lisp as a separate system asdf-bundle.asd? Do we want to distribute it as part of asdf.asd the way we used to do asdf-ecl.lisp? Do we want to just add its contents to asdf.lisp, a growth of a bit over 10% in size, for additional functionality on many platforms and much less headaches on ECL? ECL will pledge to whatever means of distribution you choose. Just keep me informed. After carefully considering the headache for users of Quicklisp and ECL, and the fact that asdf-bundle now supports load-fasl-op for all actively maintained implementations, except ABCL which has its own thing, I've decided that it's probably best to fold asdf-bundle into ASDF. (Note that I haven't tested the SCL, LispWorks or MKCL ports, and that the LispWorks port I just threw together probably needs some love). The only objection I can imagine is file size, but somehow, I fear we're past the point of being able to complain. I fully assume the creeping featuritis since ASDF 1. wc stats are as follows: 4534 19011 200127 asdf.lisp 597 2138 21861 asdf-bundle.lisp 5131 21149 221988 total So the increase is a bit under 11% increase in character file size. I'll give a few days for people to issue objections, and if none is raised, I'll go ahead with the merge some time next week, after hopefully testing on more implementations. Hopefully, I will add some tests to the ASDF test suite. -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
