freenode/#shirakumo - IRC Chatlog
Search
9:22:40
gingerale
Hmm.. Well this is a bother. This doesn't seem to work, (defcenum bar ... :bar-count) (defstruct foo (offset :uint16 :count (foreign-enum-value 'bar-format :bar-count)))
9:24:55
Colleen
https://github.com/bkaradzi... Website (HTML), Title: bgfx/bgfx.h at master · bkaradzic/bgfx · GitHub
9:26:25
Shinmera
You can pack the enum definition in an (eval-when (:load-toplevel :compile-toplevel :execute) ..) and then use #.(foreign-enum-value ...)
9:28:01
Shinmera
alternatively, and stylistically nicer, you could just use a defconstant for that count enum thing.
11:21:56
Shinmera
In the flowchart library you have nodes that represent the basic building blocks. Each node can have several ports, over which it can be connected to other nodes.
11:22:34
Shinmera
Now, what ports a node has and what kind of attributes a port has seems to very clearly be part of a definition, meaning the ports would be defined along with the class definition.
11:22:46
Shinmera
However, the port's value (the connections it has) very clearly are an instance thing.
11:23:10
Shinmera
This together lead me to the idea of modelling ports as slots of a particular class.
11:23:48
Shinmera
More concretely put, you'd do something like (defclass condition () ((in :port-type n-port) (true :port-type 1-port) (false :port-type 1-port))
11:24:21
Shinmera
Meaning you define a "condition" node with an "in" port that allows arbitrarily many connections, and "true" and "false" ports which each can have only one.
11:25:10
Shinmera
I'd like to be able to do something like (connect (port node 'foo) (port other-node 'bar)) or pass around nodes and look at them on their own
11:25:27
Shinmera
However, in order to be able to do that, the port would have to have knowledge of the particular instance it's "coming from".
11:25:46
Shinmera
Slots on the other hand are very clearly tied to the class, so I can't use them for that.
11:26:41
Shinmera
1. Require most port access functions to also include the node instance the port is in relation to
11:27:33
Shinmera
2. Materialise the ports as shim instances upon instante initialisation, meaning you have a separate "port" class entirely that gets automatically instantiated when a node class is instantiated.
11:28:20
Shinmera
Now, 1. is not really appealing because it means you need to keep track of two objects a lot of times and need to call with seemingly irrelevant information too
11:29:19
Shinmera
2. is not really appealing either because you either make the "port" a shim and have the actual values still exist as a slot and thus duplicate information, or you make the port instance keep the value as well, getting rid of the slots again, creating an entirely separate, but mostly analogous, slots system entirely