freenode/#clim - IRC Chatlog
Search
16:00:45
admich
I have seen that recently the mirror of a sheet is no more the x11 window but an object clx-mirror. Is it correct respect to the spec? What is the benefit of this indirections?
16:02:00
jackdaniel
admich: it is correct, spec says that the mirror is not defined (so it is a backend-specific object)
16:02:32
jackdaniel
regarding benefits, I'm implementing xrender-based mechanism with double buffering, so I want to put a pixmap in clx-mirror as a backbuffer
16:05:06
jackdaniel
admich: regarding sheet geometry: http://turtleware.eu/static/paste/3a5704e8- (demo wip)
16:05:26
jackdaniel
slyrus was interested in it, afaik Krystof did implement it partially, but the source code is lost :)
16:07:34
lukego
jackdaniel: Here's a quick hack approach to converting CLIM output records back into geometry (rectangles) tagged with metadata (presentation objects). maybe not so nasty? https://imgur.com/a/bS0rmaM
16:11:40
admich
Eventually if I want to try to write a svg backend, what is the dependency policy? Can I use a library as spinneret or cl-who to produce xml code or better to use only format?
16:12:21
jackdaniel
admich: it is fine for backend to have dependencies (especially if it saves time and maintanance burden)
16:15:22
lukego
(Could also be that there's a simpler and more convenient drawing abstraction that I should be using e.g. turtle graphics instead of affine transformations.)
16:15:36
jackdaniel
I'm not sure how much of javascript is required for svg, but maybe cl-javascript (as a compiler) could be a sensible dependency too
16:17:35
admich
for an output only backend like pdf and postscript, I think javascript isn't necessary.
16:35:10
jackdaniel
lukego: I'm thinking about something like this: http://turtleware.eu/static/paste/be799619-legs.lisp.txt
16:35:38
jackdaniel
since all output is presentations, you could define commands - i.e add-pin and add-leg that works on the empty slot
16:36:07
jackdaniel
notice, that in the function #'draw we position the board, and the board operates in its own coordinate systems
16:36:22
jackdaniel
moreover, the board introduces yet another (inner) coordinate system for its pins etc etc
16:37:23
jackdaniel
you could get fancy and store the output record references inside each object (i.e leg holds in a slot a reference to its own presentation output record), however that doesn't seem to be necessary
16:38:59
jackdaniel
moreover, since these are presentations, you could define a multi-point drag-and-drop translator to manually set a route between pins
16:41:46
jackdaniel
now, if you define a command like this: (define-app-command (com-foo :keystroke #\space) ())
16:42:01
jackdaniel
then you may recompile the function draw, and after pressing space in the application window, it will get redrawn
16:48:19
lukego
jackdaniel: Is there an easy way to see the output records for this example? e.g. once it's already loaded on the screen can I somehow grab the output records in the SLIME inspector to see what CLIM did?
16:50:37
lukego
re: interactive commands, I'd like to be able to write a lot of commands for understanding what's going on in the diagram, e.g. showing all the pads that should be connected to GROUND, etc, but I don't want to do any "imperative" changes to the design e.g. placing pads or routing traces. I want to do that purely algorithmically.
16:52:01
lukego
but that's maybe also a grey area e.g. maybe I could click on something to change the parameters of the algorithm that routes it e.g. quickly test what happens if I'd rotate a part by 90deg and then if I like it I could add that constraint to the board-layout code.
16:52:58
lukego
(Maybe it's double gray area. If the board design "code" turns out to be mostly constraint expressions and parameters then interactively tweaking them might make sense while looking for the values to keep.)
16:59:42
jackdaniel
when you press space, it gets redisplayed, but if you press control+space, it will print all output records
17:04:12
lukego
So I think the next step for me is to write drawing routines for the different shapes of chips, then draw the ~100 chips that make up my design, then extract the ~1000 pin/pad locations, then write a function to create routes between them.
17:07:10
jackdaniel
this is somewhat improved example with interactivity: http://turtleware.eu/static/paste/85cbb9a8-legs.lisp.txt
17:07:50
jackdaniel
my old house collapsed, so this time I will build it starting from the smoke on the chimney
17:08:18
pjb
lukego: I would guess modern datasheets include the drawing and pin/pad positions. You can just download a database for them…
17:10:14
lukego
pjb: Genreally I'm doing the hardest and riskiest parts first but there are dependencies e.g. I need to define all the parts that I need, define what they look like, define guesstimated positions of them. that's what I've been working on. then I can route 'em.
17:12:09
lukego
yeah there will need to be some kind of a feedback loop there. I'm doing my placements using Screamer at the moment and I'm thinking that will be flexible for incrementally adding constraints ("move that towards bottom-left", "pick rotations for these that minimize intersections", etc)
17:12:12
pjb
lukego: you may have some constraints for the connectors for example, but the rest can be subject to the routing.
17:13:07
jackdaniel
n.b I'm quite satisfied with the defpresent macro, I will add it to my repl-hack-utilities :)
17:13:10
lukego
but I've spent enough time thinking about routing to identify an initial strategy to take from the litetrature ("Contour") so it's not a complete unknown.
17:14:30
jackdaniel
see how I've defined another view class that is default for the stream I'm drawing on
17:14:41
jackdaniel
otoh, when I right-click on the pin, the "textual" representation appears in the menu
17:15:37
lukego
"Contour" router is basically to shop the board up into tiles representing used and empty space and then find the pairs of things that need to be connected and do A* search from both ends in parallel until they meet. rinse and repeat. see how that goes... it's designed for VLSI and not PCB
17:18:37
lukego
I'm also currently "floorplanning" the board into discrete modules. that's mostly for divide-and-conquer purposes e.g. to have small enough domains to do Screamer backtracking searches usefully in. but also because a lot of good PCBs seem to be designed that way in practice. https://twitter.com/lukego/status/1363497447532675077
17:34:12
lukego
oh also, experience so far suggests it's easier said than done to import geometry from vendor datasheets, which means e.g. diagrams like this in pdf files https://imgur.com/a/aKsigfY and I'm still thinking hard about how to get accurate and reliable footprints. I think though that I'll start with cartoonish approximations for writing the router and then get the fine details right at the end.