Back
[10:49:07] <archivist> interesting GCC problem
http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf
[11:35:53] <seb_kuzminsky> andypugh: if i were doing the tooltable work (which i'm not), i'd be tempted to create the api first, and leave the current implementation behind it
[11:36:24] <seb_kuzminsky> that'll show you exactly how linuxcnc currently accesses the tool table, and it'll make it more testable
[11:36:45] <seb_kuzminsky> *then* you'll be in a good position to experiment with different backends
[11:40:29] <andypugh> This was the main rationale behind startting with a database exactly like the tool file.
[11:41:33] <andypugh> But I think you are talking about an API which accesses the current tool array?
[11:42:41] <andypugh> One drawback with that otherwise sensible approach is that it precludes the "delete the tool array and see what complains" method of development :-)
[11:43:53] <andypugh> Back in a bit, I feel the need to use a machine tool for a few hours :-)
[11:46:03] <andypugh> I can't work out whether to write the API in Python (ameanable to user/integrator tweaks) or C++ (Which leaves a lot less cruft in the C++ code).
[11:53:22] <seb_kuzminsky> the tools are currently used inside the C core of linuxcnc, so that's what i'd write the api in
[11:54:17] <seb_kuzminsky> make a tooltable.h and tooltable.c, and move all the tooltable code in there
[11:54:47] <seb_kuzminsky> you can still remove the current tooltable array and see what breaks, then teach the broken stuff to use the api instead of direct access
[11:54:54] <seb_kuzminsky> bbl, going sledding with the kids
[14:03:28] <JT_Shop> all the links to the pdf 2.5 docs are borked
http://linuxcnc.org/docs/LinuxCNC_Getting_Started.pdf returns a 404
[14:05:11] <JT_Shop> I figured it out
[18:23:12] <seb_kuzminsky> JT_Shop: the link you pasted shouldn't appear anywhere in the w.l.o/docs webspace