Skip to content

Instantly share code, notes, and snippets.

;; A function to help generate graphs made from cons cells.
;; target is either a symbol representing a nodename or the form (v xxx) where
;; xxx is some value we want for the car/cdr of the node. Don't make mistakes
;; when specifying the dsl, there is no error checking.
;; (a :r a)
;; (a :l b :l c :l (:v 42))
;; and so on.
;; If there are no computable roots, then one must specify the roots with
;; (:roots a b c ... z)
(defun gen-cons-graph (dsl)
ATTRIBUTE-BAG> (make-attribute-bag :supersede (u:dict :a 1 :b 2) :alist '((:c . 3) (:d . 4)) :plist '(:e 5 :f 6) '(:d 100))
#<ATTRIBUTE-BAG {101D50C053}>
ATTRIBUTE-BAG> (dump-attribute-bag *)
Attribute bag:
name: :A
attr semantic value is 1, computed value is "UNBOUND"
name: :B
attr semantic value is 2, computed value is "UNBOUND"
name: :C
attr semantic value is 3, computed value is "UNBOUND"
(defun sieve (pred sequ &key (key #'identity)
(values t)
(pred-range-sort (constantly nil))
(initial-key-pool nil) ;; ensure all buckets present!
(result-transformer-func #'identity)
(decorate-position nil))
(let ((result (make-hash-table :test #'equal)))
;; Initialize the key pool if supplied.
(when initial-key-pool
;; Experimental v:define-texture-map description.
;;
;; The v:define-texture-map DSL is a means to define how texture maps are
;; stored and organized. In this discussion, a "texture-map" is all of the data
;; associated with an opengl texture. A 2d texture map, for example, can have
;; many mipmaps associated with it. A 3d texture maps has mipmaps of a
;; different format than a 2d texture. A cube map has 6 faces, each a
;; texture-map, and each face might also have mipmaps.
;;
;;
;; Experimental v:define-texture-map description.
;;
;; The v:define-texture-map DSL is a means to define how texture maps are
;; stored and organized. In this discussion, a "texture-map" is all of the data
;; associated with an opengl texture. A 2d texture map, for example, can have
;; many mipmaps associated with it. A 3d texture maps has mipmaps of a
;; different format thatn a 2d texture. A cube map has 6 faces, each a
;; texture-map, and each face might also have mipmaps.
;;
;;
;; TODO: It is the case that we could observe when we're not in a running
;; core and indicate a "previously defined" warning.
;;
;; Behold if we put this form into this macro:
;;
;; (format t "*load-true-name: ~A, *compile-file-truename*: ~A~%"
;; *load-truename* *compile-file-truename*)
;;
;; Notice under these conditions:
;; *ltn* *cft* Observation
<mfiano> Gleefre: No, there was a time when I rewrote crawler like 5 times
under various brand names :) I have no idea what I was smoking at
that point in my life. Nothing voluntary, that's for sure. [17:12]
<mfiano> THe latest incarnation was https://github.com/mfiano/dungen [17:13]
<mfiano> But the answer to your question was actually "yes". It at one point
moved from axity.net to bufferswap's repos. [17:14]
<mfiano> I think that was the first nameless jump [17:15]
<mfiano> ah no, the first was actually a python codebase, named crawlr,
without the "e". #2 was the original CL project on axity. #3 was
crawler2 rewrite to be more efficient with psilord's help on the
## Source Centric Editing (No Dispersed UI-Only State)
We found that encoding large amounts of app structure and state in the IDE
itself was both highly convenient and also a strong anti-pattern for
understanding, maintanance, and evolution of the app code. It is trivial for
the IDE interface to cause deviations from standard coding practices (for
example, initializer data held only in an IDE instead of the source code),
for the IDE to produce garbage in its representation when the underlying code
changes, and for the IDE to be poor at telling you when this has happened.