libera/#clim - IRC Chatlog
Search
6:56:13
lukego
ACTION will endeavour not to make so many annoying comments while wrestling with clim :)
7:29:53
lukego
I have a very basic first version of CLIM-driven PCB layout now: https://twitter.com/lukego/status/1404701638581968898
7:31:30
lukego
Here the CLIM output records are the primary representation of the CAD data. Presentations keep track of e.g. what is an IC and which are its pins/pads. Schematic is drawn with CLIM putting all parts at (0,0) and then SMT solver is used to compute proper non-overlapping placements for the parts.
7:33:54
lukego
Hopefully this will be a productive little environment to iterate in. I think that I'll need to try a bunch of different constraints and solvers to see what is practical, and also e.g. do each module of the PCB separately and revise them so that they fit together
7:42:59
lukego
This feels a analogous to the "object-relational mapping" problem when I need to bidirectionally map object properties like position and rotation to external state like variables in a Z3 model.
7:45:17
lukego
Maybe I'll allow the output-history to contain multiple presentations for the same object and in that case the solver has to pick which ones to use. So e.g. the code that currently draws all the parts at (0,0) prior to layout could draw multiple versions of each part e.g. rotated in 90 degree steps.
7:54:33
splittist
If the solver is picking a translation, it could pick a rotation, too, couldn't it?
8:08:13
lukego
Yeah, I'm planning to write that code next. Just now I have constraints like (AND (= X2 (+ X1 20)) ...) defining the geometry of each part. I'll change that to (OR (AND ...) (AND ...) ...) so that the solver can consider several options.
8:09:47
lukego
Maybe I can also assign weights to the options e.g. so that the solver will prefer 90-degree orientations rather than 45-degree ones, or that all other things being equal it would prefer to use larger sizes of capacitors/resistors that are easier to assemble, etc.
10:50:42
jackdaniel
lukego: visibility-wise you may add # before lisp and clim (for sake of discoverability by other lispers)
10:52:47
jackdaniel
contrapunctus: you've mentioned restructuring the documentation to follow a principle of four different modules in it - I can see there 3 (and if we take off "introduction", then it is 2)
11:04:38
scymtym
jackdaniel: i think contrapunctus was referring to the four modes in the document they linked: https://diataxis.fr/
11:05:02
contrapunctus
jackdaniel: ah, right. The four are tutorials, how-to guides, explanation, and reference. I usually add an introduction alongside them, as is the case here. How-to guides are about "real world" tasks which can be achieved through the software...and I can't really think of any just yet (I'm not very experienced with GUI work). But I'd definitely like to separate some of the explanation from the tutorial
11:10:15
contrapunctus
(I saw that there's a reference, but I have not looked into that yet, so I kept it out of the "partial outline for the content I've read so far".)
11:12:55
jackdaniel
using views (if I understand that chapter correctly) definetely belongs to how to
11:13:35
jackdaniel
building mcclim along with bundled applications would a reference too, eventually how-to (how to build mcclim)
11:14:10
jackdaniel
output recording, display time, commands, incremental redisplay and views indeed belong to explanation, I'd add frames there too
11:14:46
jackdaniel
pjb: yes, I've fixed the issue you have mentioned in the mcclim repository; my point of leaving a comment that the pixmap representation is unspecified was strictly informative
11:21:12
contrapunctus
jackdaniel: cool ^^ I guess the installation process in the tutorial can be the quick and easy way (quicklisp), and building can go to how-to, as you say. (But McCLIM already has a README outlining installation, so maybe one can just link to that to avoid duplication and "drift".) It's okay to cover the same topic in different sections (each probably linking to the others); each section just has a diff
11:22:01
jackdaniel
I don't think that the documentation should rely on information provided in readme