1 --- !ditz.rubyforge.org,2008-03-06/issue
2 title: Integrate with and migrate algorithms to libale.
4 Core algorithms should probably be moved to the libale project, which has a
5 repository stored here:
7 http://repo.or.cz/w/libale.git
11 reporter: David Hilvert <dhilvert@auricle.dyndns.org>
14 creation_time: 2009-01-11 06:33:26.944793 Z
17 id: 4bcb1e64de1b6ec60b100350f32e8f98ea7f0279
19 - - 2009-01-11 06:33:28.329070 Z
20 - David Hilvert <dhilvert@auricle.dyndns.org>
23 - - 2009-03-04 17:00:25.730472 Z
24 - David Hilvert <dhilvert@auricle.dyndns.org>
27 Integration with Libale may involve changing certain interfaces (e.g., image,
28 render, etc.) to more closely resemble their Libale counterparts. (E.g., image
29 should no longer allow pixel access, and render should accept something like
30 a sequence of (transformation, image) pairs.)
31 - - 2009-03-05 02:50:22.970276 Z
32 - David Hilvert <dhilvert@auricle.dyndns.org>
35 Consider that, better than changing existing interfaces of image, render, etc.,
36 would be to replace instances of these classes with instances of their libale
37 counterparts, which approach would have the desirable side effect of
38 immediately using the modified and up-to-date interfaces within libale.
39 - - 2009-03-19 13:38:35.089275 Z
40 - David Hilvert <dhilvert@auricle.dyndns.org>
43 Note that certain aspects of current classes (esp. the render class) might be
44 desirable to keep, as their reproduction within Libale may be difficult. Code
45 designed to avoid duplication of incremental renderers on a rendering sequence
46 is one example where such maintenance of current classes may be preferable.