Dear Stelian, Dear Lispers,
in Gitlab MR !37 I try to address some fundamental bugs regarding the proper treatment of incrementality for defsystem dependencies. See for instance the test I just added, that still fails at this time, test-defsystem-depends-on-change.script. https://gitlab.common-lisp.net/asdf/asdf/merge_requests/37
Now, the good news is that it's a generally understood problem, analogous to proper phase separation of macro evaluation in e.g. Racket, or of proper stratification of dynamic computation graphs in reactive programming: "just" have an operation define-op for every primary-system, that can represent in the graph the definition of other computations, and its dependencies. Many current open ASDF bugs can be fixed, and ASDF will correctly handle the incremental rebuilding of systems when a defsystem-depends-on dependency is out of date.
The bad news is that it becomes even harder than before to support a system that has defsystem-depends-on on another system defined in the very same file, a feature currently relied upon by iolib.
Indeed, if every reference to a system by operate now triggers a dependency on define-op, then loading a file already being read while defining a system triggers the circular dependency detector. To solve that while preserving some semblance of atomicity for the perform seems hard. Stelian had a proposal to defer the evaluation of the defsystem forms, which could help if done well, but itself is not a trivial change, and might not help that much when methods are defined on (eql (find-system ...)). We'll see.
Stelian, how sad would you be if you have to segregate defsystem-depends-on to refer to systems in separate files?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Malthusianism: because growth may stop within centuries, we must use extreme violence to put an end to it now and make everyone poor today.
Dear Stelian, dear Lispers,
in Gitlab MR !37 I try to address some fundamental bugs regarding the proper treatment of incrementality for defsystem dependencies. See for instance the test I just added, that still fails at this time, test-defsystem-depends-on-change.script. https://gitlab.common-lisp.net/asdf/asdf/merge_requests/37
The test now passes, and !37 is working, though I'll probably cleanup the code some before I mark it WIP no more.
The bad news is that it becomes even harder than before to support a system that has defsystem-depends-on on another system defined in the very same file, a feature currently relied upon by iolib.
And indeed !37 fails to compile iolib, for this reason. Glancing at Quicklisp, iolib might be the only system affected (but I'd need a better test, and many systems fail to load on my machine due to CFFI being unable to find some .so, which is about any system depending on any .so, since I'm using NixOS).
Stelian, how sad would you be if you have to segregate defsystem-depends-on to refer to systems in separate files?
Stelian, what do you think?
I could try to *also* implement deferred evaluation of defsystem forms, but that would be a pain: now ASDF would need an additional registry, for unevaluated defsystem forms.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org There's no worse blasphemy than to claim authority on telling what pleases or displeases God. Hence prophets and priests are the most impious men on earth. — Faré
Dear Stelian, dear Lispers,
[...]
Stelian, how sad would you be if you have to segregate defsystem-depends-on to refer to systems in separate files?
Stelian, what do you think?
I would be quite sad, because from my point of view as a user the whole point of the slash-systems was to have all systems in a library in a single file. That said, it's mostly an æsthetic concern, I can live with it.
I suppose this shows one more time the limits of the naively parsing .asd files using CL:EVAL. One can't easily do a two-pass evaluation of the definitions therein.
On Tue, Nov 29, 2016 at 4:01 PM, Stelian Ionescu sionescu@cddr.org wrote:
Stelian, how sad would you be if you have to segregate defsystem-depends-on to refer to systems in separate files?
I would be quite sad, because from my point of view as a user the whole point of the slash-systems was to have all systems in a library in a single file. That said, it's mostly an æsthetic concern, I can live with it.
OK, I'll try harder and see if I can salvage this feature somehow. Sigh.
I suppose this shows one more time the limits of the naively parsing .asd files using CL:EVAL. One can't easily do a two-pass evaluation of the definitions therein.
Well, you know the saying: "if it's not backwards, it's not compatible."
Using CL:LOAD was "the simplest thing that works", and it's hard to restrict things after the fact.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I have never killed any one, but I have read some obituary notices with great satisfaction. — Clarence Darrow
-
Faré -
Stelian Ionescu