On 7/21/16 Jul 21 -5:47 PM, Andrew Sengul wrote: > Hi Fare, Robert and Dave, > > Thanks for your suggestions, I read Drew's paper and his chunks system > is close to the kind of thing I'm looking to implement. I also looked at > cells, Garnet and Gendl. I downloaded Garnet and have been looking > through the KR code; Robert, is there anything else you would suggest if > I'm going to try using KR?
Not really. I only ever used it as part of the Garnet system. Garnet, FWIW, is really awesome but.... (1) it's bitrotted (especially its X interaction and its pre-ASDF build system); (2) learning curve; (3) stock look and feel is so nasty that you don't realize how awesome it is (when I was using it, I had the great good fortune of working with a human interface expert who told me how to fix the default color scheme, widget shapes, and font choices, but all that customization was lost in a proprietary corporate filesystem :-() Are there any cells examples lying around? Recoding them might be reasonable. Or it should be trivial to find examples intended for a Truth Maintenance System and translate them into KR. Maybe something from Forbus & deKleer's "Building Problem Solvers" would be suitable. > > I'm going to use ASDF as the basis for this project at least to start > with. One of my goals is for the systems I'm building to be usable as > portable software modules, so implementing them as ASDF packages is a > natural choice. At least at the outset, I don't have a problem with > ASDF's model being filesystem-based; it's fine for the components of > each system to be defined in the form of files. I think requiring that a > file be saved whenever a change is made to a component is inefficient, > but that can be left for now. My eventual goal will probably be to > combine a constraint-solving system with ASDF; perhaps chunks can be > implemented as part of an ASDF extension. > I've got the chunks code but it doesn't compile for me with SBCL, so > more work will be needed on that front. I tried for a while to get Drew's yale tools to compile, but I never was fully successful. On my "someday I'd like to do this" list is extracting some of that stuff and making it more compatible with ordinary lisp usage. > > Any thoughts you have on this direction for the project are welcome. Thanks, Sorry, I'm afraid those were not too helpful. best, r > > Andrew > > On 07/19/2016 07:13 AM, Robert Goldman wrote: >> Drew McDermott made a build system called (IIRC) "chunks," that did just >> what you want: it put dependencies on arbitrary data structures and >> recomputed them on need. One challenge is that his build system is >> built on top of his "yale-tools" mega-library, which can be difficult >> for outsiders.... >> >> Here's Drew's paper, A Framework for Maintaining the Coherence >> of a Running Lisp: http://www.cs.yale.edu/homes/dvm/papers/lisp05.pdf >> >> I suggest you read this, and see if you could graft the ideas onto ASDF >> (with suggestions from asdf-devel). >> >> ASDF mostly uses the filesystem to track dependencies (although it has >> an internal db, as well), so there would be a little effort to extend to >> a non-file-centric build. >> >> Drew's key idea is that his system (and ASDF), unlike build systems like >> make or ant, have as a primary job maintaining the integrity of the >> running lisp image. [Faré may disagree with this claim: he comes to Lisp >> usage with a newer perspective than my old-school view.] >> >> Drew's system is less fine-grained than the cells system that Faré >> suggests. I don't think the cells system ever got mature enough for use. >> >> If you want a dependency-driven, lisp-based constraint system per Faré, >> I think you'd have better luck with the KR system developed a long time >> ago at CMU. It is primitive in some ways (hand-built on structures, >> rather than using CLOS), but was used for years in a very high-stress >> environment, so is much more likely to work than cells. KR is available >> as part of the Garnet UI system. Drop me a line if you are interested. >> >> Best, >> r >> >> >> > >
