| … | … | @@ -196,7 +196,7 @@ Where is this API description kept? Well, the `*-description-*` message |
| 196 | 196 | sent to the `(OpenclKernelNode "vec_add")` node should return this. |
| 197 | 197 | I guess this is hand-coded, for now. |
| 198 | 198 | |
| 199 | | TODO: Should this be published as |
| 199 | TODO: ?? Should this be published as ?? |
| 200 | 200 | ``` |
| 201 | 201 | (Section (OpenclNode "...") (ChoiceLink (Section ...))) |
| 202 | 202 | ``` |
| … | … | @@ -208,6 +208,21 @@ could be ambiguous in general, as other `Section` might pop up. |
| 208 | 208 | By contrast, `*-description-*` is unambiguous and is a reserved keyword. |
| 209 | 209 | So OK, leave as-is. |
| 210 | 210 | |
| 211 | Update 11 Sept 2025: The OpenCL program code is now parsed to extract |
| 212 | function signatures, and these signatures are converted to Atomese. |
| 213 | See `genIDL.cc` for that code. The Atomese signatures are now published |
| 214 | in `*-description-*`. When user code attempts to invoke a kernel, the |
| 215 | arguments created by the user are checked against the kernel interface. |
| 216 | An error is thrown, if they don't match up. |
| 217 | |
| 218 | The current implementation is rudimentary; only the simplest kernels are |
| 219 | handled. But its a proof of concept. Seems to work, and seems not to be |
| 220 | horrible. |
| 221 | |
| 222 | At any rate, this is a win: having the `*-description-*` available |
| 223 | should allow the introspection that we've long been dreaming of and |
| 224 | blabbering about. We'll see how that works out. |
| 225 | |
| 211 | 226 | Open Discussion |
| 212 | 227 | --------------- |
| 213 | 228 | Some philosophical questions remain as to "object permanence". Vectors |