Dear all, me and Fare clearly can't reach a consensus about the changes I've recently proposed to ASDF: https://gitlab.common-lisp.net/asdf/asdf/merge_requests/13 I acknowledge a possibility, that I'm totally wrong here (and if that's true, my deepest apologies to Fare for using vast amount of his time), but my conviction is that this is a step forward and a good proposition. I would appreciate 3rd party opinions, because I'm clearly not objective here since I've wrote the code in question. The code isn't in final shape yet, but it proves no regressions wrt tests shipped with ASDF right now (tested on ABCL, CCL, ECL, SBCL 1.2.0, SBCL and MKCL). I'm planning to write a proper regressions and feature tests and document the behaviour in question in the manual, but only if there is sense in it (i.e it will be merged after fixing the potential issues). Thanks, Daniel Kochmański -- Daniel Kochmański ;; aka jackdaniel | Poznań, Poland TurtleWare - Daniel Kochmański | www.turtleware.eu "Be the change that you wish to see in the world." - Mahatma Gandhi
I'd just like to give a description of some of our use-cases which might not be totally reflected in standard regression tests (maybe they should be somehow). What I know is that we depend heavily on immutable-systems behavior in production (e.g. for making pre-built Gendl distributions which won't try to re-compile and re-load Gendl and its dependencies on top of an image which already has them built-in, when quickloading other systems which have :depends-on :gendl). We also depend (daily) on the monolithic-compile-bundle operations for making builds which don't end up including asdf themselves (but our builds do include uiop). On Mon, Sep 12, 2016 at 4:34 AM, Daniel Kochmański <daniel@turtleware.eu> wrote:
Dear all,
me and Fare clearly can't reach a consensus about the changes I've recently proposed to ASDF:
https://gitlab.common-lisp.net/asdf/asdf/merge_requests/13
I acknowledge a possibility, that I'm totally wrong here (and if that's true, my deepest apologies to Fare for using vast amount of his time), but my conviction is that this is a step forward and a good proposition. I would appreciate 3rd party opinions, because I'm clearly not objective here since I've wrote the code in question.
The code isn't in final shape yet, but it proves no regressions wrt tests shipped with ASDF right now (tested on ABCL, CCL, ECL, SBCL 1.2.0, SBCL and MKCL).
I'm planning to write a proper regressions and feature tests and document the behaviour in question in the manual, but only if there is sense in it (i.e it will be merged after fixing the potential issues).
Thanks, Daniel Kochmański
-- Daniel Kochmański ;; aka jackdaniel | Poznań, Poland TurtleWare - Daniel Kochmański | www.turtleware.eu
"Be the change that you wish to see in the world." - Mahatma Gandhi
-- My Best, Dave Cooper genworks.com, gendl.org +1 248-330-2979
On 9/12/16 Sep 12 -8:40 AM, Dave Cooper wrote:
I'd just like to give a description of some of our use-cases which might not be totally reflected in standard regression tests (maybe they should be somehow).
Yes, they should!
What I know is that we depend heavily on immutable-systems behavior in production (e.g. for making pre-built Gendl distributions which won't try to re-compile and re-load Gendl and its dependencies on top of an image which already has them built-in, when quickloading other systems which have :depends-on :gendl).
I believe we could test this by building an image, loading it, and trying to load a pre-loaded system that is marked as immutable. We'd have to have the loaded system execute some code that would detect (incorrect) updates to the immutable system, but that should not be impossible.
We also depend (daily) on the monolithic-compile-bundle operations for making builds which don't end up including asdf themselves (but our builds do include uiop).
I'm less certain about how to test this. What is the behavior we should be testing here? thanks, r
On Mon, Sep 12, 2016 at 4:34 AM, Daniel Kochmański <daniel@turtleware.eu <mailto:daniel@turtleware.eu>> wrote:
Dear all,
me and Fare clearly can't reach a consensus about the changes I've recently proposed to ASDF:
https://gitlab.common-lisp.net/asdf/asdf/merge_requests/13 <https://gitlab.common-lisp.net/asdf/asdf/merge_requests/13>
I acknowledge a possibility, that I'm totally wrong here (and if that's true, my deepest apologies to Fare for using vast amount of his time), but my conviction is that this is a step forward and a good proposition. I would appreciate 3rd party opinions, because I'm clearly not objective here since I've wrote the code in question.
The code isn't in final shape yet, but it proves no regressions wrt tests shipped with ASDF right now (tested on ABCL, CCL, ECL, SBCL 1.2.0, SBCL and MKCL).
I'm planning to write a proper regressions and feature tests and document the behaviour in question in the manual, but only if there is sense in it (i.e it will be merged after fixing the potential issues).
Thanks, Daniel Kochmański
-- Daniel Kochmański ;; aka jackdaniel | Poznań, Poland TurtleWare - Daniel Kochmański | www.turtleware.eu <http://www.turtleware.eu>
"Be the change that you wish to see in the world." - Mahatma Gandhi
-- My Best,
Dave Cooper genworks.com <http://genworks.com>, gendl.org <http://gendl.org> +1 248-330-2979
There is some minimal testing of immutable systems in test-force and test-preloaded, but it could be much improved. Dave, if you have time to submit test cases sufficient to cover your uses of immutable, it would be great. (Or then again, bless the existing tests as covering your needs.) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The problem with being a citizen of the world is that you don't get to travelling abroad much.
participants (4)
-
Daniel Kochmański -
Dave Cooper -
Faré -
Robert Goldman