freenode/#lisp - IRC Chatlog
Search
9:01:54
moon-child
lukego: it's not about mixins and documentation strings--you can have those either way--it's just row vs column approach to the expression problem
9:11:27
lukego
It's an interesting problem that unfolds. The first pins are easy, like "This pin has to be connected to ground", "this pin should not be connected", "this pin should have a wide copper trace." but now it gets interesting with "this pin should be connected to that other pin with a 1kΩ resistor in between" and so now I need a way for a pin on one part to "imply" a whole other part and a pair of connections
9:13:46
flip214
lukego: in the past, I've often started with keywords; went to lists; and then structure or classes as the amount of data to store became too unwieldy in a list.
9:13:51
lukego
and in a traditional CAD package you might leave this informal for the designer to worry about, or make it a design rule that is checked, but it would be neat to just do it automatically "defmacro style"
9:16:29
lukego
I think the fact that I'm using CLIM in this application makes me also lean towards using classes. Since then the types I'm defining also have a meaning in that universe e.g. to create presentation methods and so on. I noticed this with Smalltalk - whole classes might feel like overkill but they are darned handy places to hang extension methods for things like graphical inspectors.
9:41:17
lukego
pve: CAD package for "algorithmic design" of PCBs. Like a KiCad clone but instead of torturously routing the traces by clicking the mouse, you torturously route the traces by tweaking the heuristics
9:44:08
loke[m]
flip214: In a way it was a good thing that C64 BASIC implementation was so dumb. It forced people to learn assembler.
9:46:17
loke[m]
flip214: But Pascal wasn't used much. In fact I have never heard of anyone using Pascal on C64 (that doesn't mean noone did, jsut that this is my experience)
9:48:10
lukego
I didn't learn assembler on the C=64 and that's a lasting regret. I think I was just a bit young though, learned it on the Amiga instead.
9:53:21
beach
flip214: "yeah, right" is the only case in English that turns a double positive into a negative. :)
9:54:28
flip214
beach: sorry. I'm just a lowly non-native-english speaker, so I wouldn't know about all these fine points...
9:54:55
flip214
(but you're right - I already knew that, just didn't #'apply the knowledge when answering. Sorry.)
9:54:57
beach
No need to be sorry. I know you are a non-native speaker. So I wanted to let you know.
9:57:49
lukego
"yeah, nah" is my favorite english-ism, but I think it might only be aus/nz. it means "actually no"
10:01:01
jmercouris
As another native speaker I would like to also point out that depending on how you stretch out the “yeah” in “yeah, right”, it may be a affirmation OR a negation. A long “yeah” typically signifies negation
10:17:04
lukego
I am for the moment resisting renaming these pins from short abbreviations like "pg" and "fb" to proper names like "power-good" and "feedback" but I'll do that later if I think it won't be too confusing wrt referencing specifications.
10:57:28
VincentVega
Is there a way to get access to a class-allocated slot value without instantiation?
12:04:41
splittist
lukego: you can have multiple accessors for a slot, so you can have the short AND the long names (:
14:55:54
lukego
I'm veering towards having a separate PACKAGE for each kind of IC now and maybe that is accelerating the descent into madness? but I'd quite like to represent each type of pin as its own class, and ICs tend to have pins with the same names but different properties
15:00:44
X-Scale
lukego: are you trying to simulate hardware modules and their interconnections in LISP ?
15:02:02
lukego
no, I'm trying to do design rule checks (enforce requirements specified informally in the datasheet) and to automate the busywork (e.g. add external resistors/capacitors that are required but not interesting enough to bother a human about)
15:04:10
lukego
also I'm trying to blur the line between "schematic" and "board design." I'll do both at the same time as a single operation. So my "schematic" will include board-related requirements e.g. that certain traces can't have vias, must be short, must be wide, etc.
15:22:14
X-Scale
beach: I've been in this channel for around 16 years. I just don't talk much. I mostly lurk :)
15:22:22
flip214
lukego: have the _classes_ of pins (vcc, gnd, GPIO) in one package; and an IC has an array of pins, which are instances of these classes.
15:23:12
flip214
you can also model the pins via multiple inheritance - a specific pin could be an anonymous class with parents (GPIO MISO ANALOG-IN PWM), for example.
15:23:43
lukego
flip214: That's what I'm thinking. But then each IC is different, and a "GPIO" pin for IC FOO is not the same as for IC BAR, so I'm thinking I'll have separate foo:GPIO and bar:GPIO classes (and factor as much as make sense into common superclasses and mixins)
15:25:00
lukego
This might be a bit extreme but it would seem to give maximum flexibility for adding weird and wonderful design rules based on quirks described informally in data sheets
15:26:37
lukego
(Of course I can redo all this later, at the moment I'm just thinking aloud as I make a first pass through a set of datasheets, trying to find some notation for writing down details that I want to capture but aren't really sure about how yet)
15:31:37
flip214
lukego: perhaps it would be more sane to fix quirks by having some additional superclass IC-FOO-QUIRKS-2021/3.2? that would also help to reference the special quirk...
15:32:03
lukego
yeah could be so. I guess that this also fits with having a separate class per pin per IC
15:32:28
lukego
I am maybe a bit drunk on the apparent cheapness of defining classes, we'll see how the hangover is tomorrow...
15:34:20
flip214
lukego: in case of such special quirks, you could simple have a _named_ class for this pin - and override methods on it. for "normal" pins without quirks (are there any?? ;) an anonymous class with inherited behaviour is used.
15:37:25
flip214
but (at least from a debugging POV) it might be much easier to just name them after the IC and pin.
15:37:45
flip214
do you also plan to have multiple revisions of ICs, with slightly different behaviour?
15:46:24
flip214
so you might need a way to clone an IC revision but with a few pins being a different class...
15:48:37
lukego
Just now I have a (pins IC) method that returns the pins i.e. does a make-instance on the appropriate pin classes and assigns them IDs (numbers) to match the datasheet. So I guess for revisions and errata I could make subclasses of the IC and override the PINS method to apply the tweaks
16:27:48
jmercouris
I can "who-calls" and see if there are any entries, of course this is not bulletproof
16:28:09
jmercouris
I'm not looking for a perfect suggestion, just a way to find candidate orphaned defuns
16:37:17
Bike
it's hard to gauge what's actually unused, and what is just used in code you haven't loaded yet, or is intended for repl use
16:37:49
Bike
i suppose if you wanted to mechanize it you could make a list of non exported symbols from your package, see what's fbound, and grep for those
16:40:30
Nilby
Yes, it's probably better to say CCL warns about unused functions in some limited circumstances.
17:27:08
_death
stumbled on https://groups.google.com/forum/message/raw?msg=comp.lang.lisp/O2rT-3JY/5oEQdSWXNy8J
17:43:02
jackdaniel
swank::function-name would be an answer, but as you have pointed out, it is just a conveniance hack (i.e returns a name with which the function was defined)
17:44:00
jmercouris
this list of actions can be a function, a lambda, a symbol (which should point to a function)
17:45:22
heisig
jmercouris: Sounds like a case for funcallable standard objects with additional metadata.
17:48:18
heisig
Of course this means you'll have to wrap closures somehow. But this wrapping is kind of the point, because you want to add additional information for your users.
17:50:58
heisig
You could also have a custom DEFUN-like macro that does the wrapping for top-level definition. Bonus points if that macro supports (interactive ...) clauses :)
17:52:53
Nilby
I do something like that where a user action can just be a form, which can be internally cached as function.
17:53:52
jmercouris
(list "description" 'function1 "description2" #'function3 "description3" (lambda (i) "tomato"))