James at al., Thank you for posting. I can never remember if this group prefers top, bottom, or inline posting -- I have various groups that vehemently insist that their way is better/best, but each group has its preferences... Anyway, I see nothing wrong with the post.
I have kept quiet on the tool table front because for me it is not a big issue as long as it works. That said lets discuss what a tool table needs to do, and lets find a simple quick and fast way to do it. I'm just about willing to bet that the SQL route is the fastest, but does the little bit of extra speed give us enough to benefit over the costs and complexity of maintaining an extra tool (and I seem to break postgress every other time I need to upgrade). I am not sure which of JSON or YAML would be the easiest to maintain, or which would be the fastest. As a note, I consider speed an issue only when doing an operation takes a perceptible delay. I seriously doubt that any of these solution will take enough time that we have to wait an extra 0.1 seconds for a tool change. The one thing that I do consider that will be a real problem is maintaining specialized tools will either end up getting people sucked into to trying to maintain them, or it will suffer from bitrot (which I see as the most likely). James, would you be willing to propose, design, and prototype a JSON or YAML implementation? Having someone willing to jump into that would probably be all it takes. EBo -- On Oct 25 2016 2:24 AM, James Waples wrote: > Hi all > > First post to this list so apologies if I'm doing something wrong. > > While I agree that the current tool table implementation is quite > limited, I have some reservations about using SQLite as a > replacement. > As maintainer and developer of (the admittedly little-used but still > useful) FusionToolTranslator > (https://github.com/jamwaffles/FusionToolTranslator), I'm concerned > that my tool and tools like it will have a hard time importing tools > into LinuxCNC if the tool table is moved into SQLite. It's also quite > useful to be able to version control the tool table when it's > plaintext. > > It's reasonably trivial to generate an SQL import file, but importing > it correctly and without conflicts would be the tricky/messy bit I > think. Are there any plans around automated tooling for an SQLite > tool > table? How would schema changes be communicated to other tools that > want to integrate with the tool table? > > Was JSON (or YAML or other plaintext) considered as a possible > solution? This may be the web dev in me talking but for third party > access, it would make working with the tool table far easier. > > James > > On 24 Oct 2016, at 19:55, andy pugh > <bodge...@gmail.com<mailto:bodge...@gmail.com>> wrote: > > On 22 February 2015 at 17:12, Sebastian Kuzminsky > <s...@highlab.com<mailto:s...@highlab.com>> wrote: > > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ToolDatabase > > Can you post your branch again? > > Maybe Norbert will review it and see if it satisfies his need? > > I'll try to review it too. > > Has anyone found time in the last 18 months to look at this? > I only ask as Stuart just asked me about it. > > The branch there is probably a bit of a dead-end, I don't think that > there is any need to support more than one database format, and the > one described here should cover everything. > (note that I do have a multiple-spindle patch to go in, and one > advantage of the full tool database is that it supports multiple > spindles and changers). > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ToolDatabase > > The assumption would be that the basic tooledit would look just the > same, but would write to the database instead of a fixed-format text > file. > > -- > atp > "A motorcycle is a bicycle with a pandemonium attachment and is > designed for the especial use of mechanical geniuses, daredevils and > lunatics." > — George Fitch, Atlanta Constitution Newspaper, 1916 > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > ________________________________ > TotallyMoney.com is the trading name of Media Ingenuity Ltd (company > number 06205695). Registered Office: Eastcastle House, 27-28 > Eastcastle Street, London W1W 8DH. Registered in England and Wales. > This email and its attachments are confidential. If you are not the > intended recipient, please do not copy or disclose its content but > contact the sender immediately upon receipt. > > ------------------------------------------------------------------------------ > The Command Line: Reinvented for Modern Developers > Did the resurgence of CLI tooling catch you by surprise? > Reconnect with the command line and become more productive. > Learn the new .NET and ASP.NET CLI. Get your free copy! > http://sdm.link/telerik > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
