Back
[06:53:48] <skunkworks> interesting..
http://www.cnczone.com/forums/linuxcnc-formerly-emc2-/285606-cnc-tormach.html
[06:54:19] <skunkworks> sounds like the gui stops but the machine keeps on running?
[06:56:26] <skunkworks> the computer hardware seems decent..
[06:56:55] <archivist> I have had the gui slow to a crawl on my 5 axis, does also mean it fails to see key presses for a while
[06:58:31] <archivist> ask him if he has enough ram to avoid swapping
[07:06:30] <micges> looks like memory leak
[07:22:26] <jthornton> a guy wanted me to make a configuration change to his Path Pilot until I found out it takes over your computer competently when installed
[07:23:00] <jthornton> seems to be very heavily modified and nothing like what we know
[08:35:17] <jepler> makes it hard to offer good advice about it even if you wanted to
[09:22:12] <mozmck> Interesting, I ran across this while looking up php vs other web languages:
http://blog.websecurify.com/2014/08/hacking-nodejs-and-mongodb.html
[09:25:46] <jepler> the state of security is pretty depressing. two systems developed years after we knew about SQL injection in CGI scripts have exactly the same class of bug
[09:28:03] <mozmck> apparently the newer technologies are not really any better even though a lot of people apparently think so.
[09:28:07] <archivist> it is the idiots thinking $laguage/library/prepared statements will wipe their butt and provide security, wrong, check incoming data is in range and does not contain something you dont expect
[09:35:00] <ssi> mozmck: I have some opinions about that class of technology :P
[09:35:14] <mozmck> nodejs and mongo?
[09:35:16] <ssi> yeah
[09:35:25] <mozmck> I know nothing about it really.
[09:35:31] <ssi> that world has come about because web developers want to be backend developers now,
[09:35:50] <ssi> and companies would rather pay web developers to be "full stack" than pay honest to god backend developers, who are 3x more expensive
[09:36:00] <mozmck> ah, I see.
[09:36:45] <mozmck> maybe that's because web "developers" at least historically were basically document editors :)
[09:36:48] <ssi> so you have a generation of kids who have never touched a language like C or C++, and never properly learned relational databases
[09:36:53] <archivist> also they are shoving processing onto the clients to waste your battery and not their power costs
[09:37:15] <ssi> and they're trying to solve all the problems that they think are brand new, and things like nosql and nodejs are the result
[09:37:21] <mozmck> relational - isn't that old?!? old is bad....
[09:37:24] <ssi> yep
[09:37:41] <archivist> relational still works!....best
[09:38:14] <ssi> there are use cases where nosql makes a lot of sense
[09:38:20] <ssi> but you can't shoehorn every problem into one or the other
[09:40:11] <mozmck> We often drastically underestimate the intelligence of those who came before us - probably because we don't fully understand the scope of the problem or their solution.
[09:40:48] <ssi> indeed
[09:41:00] <archivist> the stupidity of a 900k js page on google images to show an 90k jpg
[09:41:15] <mozmck> ouch!
[09:41:45] <archivist> and I get a white screen at that with a few bits on
[09:41:52] <jepler> it seems to be the nature of computer systems that we effortlessly use up 99% of all performance increases without improving anything
[09:42:28] <mozmck> That's the kind of reason I use fltk for small utilities. Pickit2 is a tiny utility that required a 60+Mbyte .net download to install and run.
[09:43:23] <mozmck> fltk statically linked adds ~400kbytes to the executable - and it's fast and cross platform
[09:44:31] <jepler> if everyone just agreed on which 60MB runtime all the software would use, it wouldn't matter
[09:45:00] <mozmck> hah! seems like every time I needed a .net program, it required a different .net than I had.
[09:45:25] <archivist> I think boost is as bad as .net for that
[09:46:07] <jepler> oh don't get me started about C++
[09:46:08] <mozmck> that may be, and seems like boost is pretty buggy too
[09:46:36] <jepler> mozmck: which compilers are you using boost with?
[09:47:02] <jepler> at $DAY_JOB we use it with gcc (4.6) and while it makes the compiler dog slow, we rarely encounter runtime bugs that we trace back to boost
[09:47:10] <mozmck> :) I like c++ - some of the c++11 features do make things nicer.
[09:47:45] <ssi> I never really got deep into c++, never liked it much
[09:47:49] <archivist> jepler, but do they break the api regularly
[09:47:54] <ssi> did a lot of C, lot of Java, some objc, and mostly golang these days
[09:48:08] <mozmck> jepler: I've not personally run into boost problems, but the kicad project has had to maintain several boost patches for bugs.
[09:48:55] <mozmck> I think some of them have been fixed in the latest boost, but iirc it took quite a while to get them fixed.
[10:31:02] <pcw_home> jthornton: when people ask me PathPilot config questions I just try and steer them to LinuxCNC
[10:31:03] <pcw_home> I dont mind making our hardware work with PathPilot on non Tormach equipment but thats about
[10:31:05] <pcw_home> as far as I feel like going
[10:49:24] <skunkworks> I installed the probing screen from the forum this weekend. that is as far as I got - looks cool.
[10:49:39] <skunkworks> That and features and I think I have everything I would want.
[10:50:11] <skunkworks> (I haven't tried features yet..)
[11:39:53] <seb_kuzminsky> skunkworks: you got farther than me
[11:41:33] <seb_kuzminsky> i feel like we have a policy decision to make - should we aim to absorb other projects like Features and build/test/package/distribute them along with LinuxCNC, or should we encourage those other projects to build/test/package/distribute them by themselves? (or should we do something else that i haven't thought of?)
[11:42:22] <seb_kuzminsky> i lean towards the "absorb them and make them part of linuxcnc" side, because it lowers the activation energy of getting them into the hands of users
[11:43:15] <jepler> let me start off by saying something that I hope is obvious: we shouldn't absorb what doesn't want to be absorbed
[11:43:34] <seb_kuzminsky> yes
[11:44:06] <seb_kuzminsky> and we should be wary of absorbing code that doesn't come with a maintainer who wants to join our project
[11:45:53] <jepler> the code needs to be high quality, it needs to be properly licensed, it EITHER needs to build on all platforms we support OR degrade gracefully (such as by not building/installing at all) when a dependency isn't met
[11:46:12] <jepler> I also really don't want building linucnc to pull in every GUI toolkit, which is what happens after you absorb one project using each toolkit
[11:46:58] <jepler> and the maintainers need to be content with our release cycle and our generally high requirements for forward compatibility
[11:47:45] <jepler> and even more than now (cough, tklinuxcnc and mini) about what happens when these absorbed projects don't keep pace with the rest of linuxcnc
[11:50:16] <jepler> ... personally, I wish that the thing we could do was facilitate putting debs of these other projects on wlo
[11:50:52] <jepler> oh yeah I didn't mention that debian packaging is mandatory in the pull request to absorb the other project
[11:51:11] <seb_kuzminsky> and documentation
[11:51:52] <seb_kuzminsky> i agree that facilitating separate projects building separated debs would be awesome, but i dont want to be a launchpad/ppa
[11:52:16] <jepler> I know
[11:52:23] <seb_kuzminsky> i feel like a can barely keep up with building/testing/packaging/distributing *one* project
[11:52:50] <jepler> am I setting a needlessly high bar for contributions? the perfect being the enemy of the good and all
[11:53:07] <seb_kuzminsky> your point about toolkits is good
[11:53:56] <seb_kuzminsky> maybe along with "we'd like to absorb your code" we should have some kind of schedule of deprecating and removing unmaintained code (tklinuxcnc, mini, etc?)
[11:55:53] <jepler> we have never removed anything as big as a whole UI before to my recollection
[11:56:22] <seb_kuzminsky> aachooo*redis*ooo
[11:57:02] <jepler> that was never a part of a stable release though
[11:57:10] <jepler> was it?
[11:57:14] <seb_kuzminsky> no it wasnt
[11:57:28] <seb_kuzminsky> you removed that usrmotintf program, that's the only 'git rm' of consequence i remember
[11:57:33] <seb_kuzminsky> for some definition of consequence
[11:57:47] <jepler> in my mind: if no maintainer steps forward, then deprecate in one major release and remove in the next
[11:58:06] <seb_kuzminsky> sounds about right
[11:58:34] <jepler> where "major" means 2.x -> 2.(x+1)
[11:58:42] <jepler> which is a funny definition of major
[11:58:47] <jepler> we should just call the next one "linuxcnc 8"
[11:58:48] <seb_kuzminsky> if enough users say they use a UI without a maintainer, i can imagine taking on maintainership of it
[11:58:53] <jepler> sure
[11:59:09] <seb_kuzminsky> jepler: i agree about dropping one set of digits frmo the release number
[11:59:36] <seb_kuzminsky> i proposed that mozmck call his stable release "3", but i'm fine with "8" too
[11:59:59] <seb_kuzminsky> actually i dont care what the number is, as long as it's "X" instead of "Y.Z", and X is clearly larger than 2.7
[12:00:29] <jepler> well we've got to get ahead of m-ch in version number </troll>
[12:00:58] <seb_kuzminsky> because numbers are more important than features & stability?
[12:01:10] <skunkworks> heh
[12:01:35] <jepler> because numbers are easier to give a total ordering to than "features & stability"
[12:01:40] <seb_kuzminsky> yeah
[12:02:38] <mozmck> does mk even do version numbering anymore?
[12:02:45] <seb_kuzminsky> i dont care
[12:02:47] <jepler> aaannnyyywwaaaayyyy if the developer(s) of features (or any other linuxcnc-adjacent project) think it would serve everyone better to get it into linuxcnc.git then I think we should have that discussion with them.
[12:03:22] <seb_kuzminsky> we talked about it on emc-developers back on September 14
[12:03:35] <seb_kuzminsky> i immediately derailed the conversation by complaining about the name :-(
[12:03:39] <seb_kuzminsky> bad seb
[12:03:59] <mozmck> I think it would be very nice to have a central location of some sort for all linuxcnc related projects, but would that mean they have to be in the same git repo?
[12:04:07] <jepler> it's easy to be snarky and negative, just look at me
[12:04:55] <skunkworks> maybe it is just me - but jepler has mellowed over the years..
[12:04:58] <jepler> (as the release manager for the next linuxcnc major version, it occurs to me that mozmck has an outsized stake in this issue)
[12:04:59] <mozmck> Maybe a separate deb for "features" and it could be in the apt repo, and also linked on the website?
[12:05:27] <jepler> mozmck: yes I was sort of suggesting that; seb rightly said that it creates more work for whoever maintains the apt repo (and also buildbot)
[12:05:37] <seb_kuzminsky> well lets be careful here
[12:05:45] <seb_kuzminsky> separate deb != separate git
[12:05:57] <mozmck> that's true too
[12:06:15] <jepler> one git = one source package
[12:06:15] <seb_kuzminsky> features could live in our git repo and build along with our code into a separate deb, like we currently do with docs
[12:06:21] <seb_kuzminsky> jepler: right
[12:06:24] <mozmck> Perhaps things like features would not need to be built on the buildbot though.
[12:06:57] <skunkworks> has anyone looked at it? (what it is using, build dependencies and such..)
[12:07:05] <jepler> one source package = one set of build dependencies, and back to the tookit issue (which I don't know if it exists with features) that impacts all users who use the mk-build-deps way of preparing to build RIP builds of linuxcnc
[12:07:33] <seb_kuzminsky> skunkworks: speaking sense, as always
[12:07:45] <seb_kuzminsky> i sure havent cloned their git repo and looked at it
[12:07:53] <seb_kuzminsky> i think it runs inside gladevcp?
[12:08:01] <skunkworks> maybe it would 'just work' ;)
[12:08:09] <seb_kuzminsky> https://github.com/cnc-club/linuxcnc-features
[12:08:49] <seb_kuzminsky> is that the one?
[12:08:59] <seb_kuzminsky> that was the git repo that was mentioned in our email thread
[12:09:08] <jepler> > sudo gedit /usr/share/pyshared/gladevcp/hal_pythonplugin.py
[12:09:23] <jepler> ow ow ow
[12:10:08] <seb_kuzminsky> that's solved by merging it into linuxcnc.git
[12:10:10] <jepler> I don't know the answer, but I hope there's a better way to accomplish whatever adding that import is accomplishing
[12:11:15] <seb_kuzminsky> i would greatly prefer if the Features developer did the job of merging it with linuxcnc in some sane way and offered us a pull request to discuss
[12:11:39] <seb_kuzminsky> rather than offering a stand-alone repo (with "sudo edit this installed linuxcnc file") and us doing the merge/cleanup
[12:11:55] <jepler> yes
[12:12:38] <jepler> and it's easy to see why, without a policy about this sort of thing, no one would spend the time preparing that pull request
[12:12:47] <seb_kuzminsky> yeah
[12:12:57] <jepler> you'd go to all that effort and then .. ???
[12:14:46] <seb_kuzminsky> i will email nick and tell him that if he makes a clean PR and offers to maintain it in our git repo, we'll merge it for the next stable release
[12:14:59] <seb_kuzminsky> does anyone mind? mozmck?
[12:16:21] <jepler> - deb packaging - autoconf checks (for lxml?) - documentation - tests ? - license compatibility - promise to maintain
[12:16:35] <seb_kuzminsky> i wonder what our "Contributing to LinuxCNC" document has to say about this kind of thing
[12:16:59] <jepler> oh ugh, they will be unable to actually merge their git repository's history with ours due to the SOB requirement
[12:17:06] <seb_kuzminsky> tests might be hard (i dont know how to test guis, but maybe there's underlying code that can be tested stand-alone)
[12:17:22] <jepler> they would have to either squash their history or rewrite it all to introduce SOB
[12:17:24] <seb_kuzminsky> jepler: are you sure? i merged the non-SoB huanyang vfd driver
[12:17:51] <jepler> IIRC we check the author-date of a commit and if it's older than a threshold we don't require SOB
[12:18:16] <jepler> so that might be how it worked in that case, but features has recent commits
[12:18:37] <seb_kuzminsky> July 2015 is the most recent one, hrm
[12:18:53] <jepler> I don't know how important their history is to them
[12:19:06] <mozmck> sorry, had to step out, reading back now.
[12:21:00] <seb_kuzminsky> haha, the cnc-club github avatar is a stick figure leaning back drinking a beer while a cnc mill makes a part
[12:21:46] <mozmck> seems like there was a different repo from fernv...
[12:22:04] <jepler> afk, in search of lunch..
[12:22:23] <seb_kuzminsky> https://github.com/FernV/linuxcnc-features
[12:22:29] <seb_kuzminsky> This branch is 31 commits ahead, 9 commits behind cnc-club:master
[12:22:46] <seb_kuzminsky> mozmck: good point, that'll have to be figured out first
[12:25:43] <mozmck> This fernv seems to be making releases:
http://www.linuxcnc.org/index.php/english/forum/40-subroutines-and-ngcgui/26578-linuxcnc-features-a-kind-of-ngcgui?start=260
[12:27:40] <seb_kuzminsky> but nick drobchenko is the one that replied on emc-developers
[12:28:09] <seb_kuzminsky> (grr, github search for "linuxcnc-features" does not find FernV's fork)
[12:28:12] <mozmck> yes, so I don't know which one is "official", or what. I think nick started the thing.
[12:28:20] <mozmck> github search :)
[12:28:38] <jepler> on another note, this is interesting --
https://blog.mister-muffin.de/2015/10/25/unshare-without-superuser-privileges/
[12:29:10] <jepler> it looks like by unsharing net and ipc namespaces it might be possible to make runtests go in parallel
[12:33:51] <jepler> I think mah had actually achieved something similar to this
[12:34:02] <seb_kuzminsky> bbl
[12:48:30] <CaptHindsight> I've been thinking about some mods to sync motion to SVG files to sync video/images to motion
[12:48:46] <CaptHindsight> yikes let me restate that
[12:49:33] <mozmck> you want your machine to dance to music videos?
[12:49:46] <CaptHindsight> I've been thinking about some mods to sync video/motion (svg files) to motion
[12:50:08] <CaptHindsight> mozmck: that could be another application :)
[12:50:14] <seb_kuzminsky> is this for one of those dlp 3d printers?
[12:50:40] <CaptHindsight> this is for more advanced versions of DLP printers
[12:50:57] <CaptHindsight> where you have more than just DLP or a laser
[12:51:20] <seb_kuzminsky> the only "motion" you need is to raise the print one layer after each exposure, right?
[12:51:21] <CaptHindsight> nozzles, inkjet, laser and DLP
[12:51:44] <CaptHindsight> https://github.com/andypugh/SVG_Slicer
[12:51:46] <seb_kuzminsky> oh, that sounds like more motion than just 1 Z-step per image
[12:52:15] <CaptHindsight> seb_kuzminsky: or you never stop the Z at all, except at the finish of the print
[12:52:54] <CaptHindsight> you can do continuous Z motion while just changing the video as the Z reaches the next slice
[12:53:35] <seb_kuzminsky> what i'm trying to say is, if you just need "one Z step per image" as your only motion, or "move Z continuously while changing images", then you probably don't want motion and interp and all that, you can probably do it easier just using hal
[12:54:18] <jepler> what z velocity might be used in this case? >1in/min?
[12:54:35] <CaptHindsight> but you might want to move Z while changing the video, then stop the Z and perform other operations like move a printhead, spindle, nozzle etc
[12:55:08] <CaptHindsight> then move Z again while synchronizing video
[12:55:44] <CaptHindsight> the printers are DLP/SLA hybrids with inkjet, FDM, spindles etc
[12:55:52] <seb_kuzminsky> wow
[12:56:29] <CaptHindsight> I've been doing it all with separate controllers until now
[12:56:53] <CaptHindsight> but I'd like to unify it all under Linuxcnc
[12:57:40] <CaptHindsight> andy has that python routine for HAL
[12:58:04] <CaptHindsight> so you can have a slideshow of SVG layers synced to Z motion
[13:00:00] <CaptHindsight> but I need to stop the part after some layers are built with a DLP and photopolymer and then have say and inkjet head make a few passes over the part then go back to DLP+resin for some 1 or more layers
[13:00:14] <CaptHindsight> and/an
[13:03:24] <CaptHindsight> maybe use Andy's way of synchronizing video while Z is moving and maybe custom m-codes to trigger images when just straight DLP printing is not occurring
[13:07:16] <CaptHindsight> I've used m-codes to trigger the start and stop of inkjet scans where the printheads were using the X and Y encoders for position
[13:20:41] <skunkworks_> Just replaced 8 blown caps on a mission critical motherboard. Sucess!
[13:21:15] <skunkworks_> (after blowing up a new psu because I forgot the machine was italian and runs 220...)
[13:21:32] <skunkworks_> it went BANG!
[13:26:48] <skunkworks_> If I would have grabbed one of the new psu's that don
[13:27:02] <skunkworks_> 't have the switch - I would have been golden...
[13:27:18] <seb_kuzminsky> nice recovery tho
[13:29:23] <CaptHindsight> done that myself
[13:29:59] <CaptHindsight> but it's usually been a 120V 60hz supply on 240V 50hz when traveling
[13:43:44] <skunkworks_> it was a hack job.. I just pull them off the top of the board and soldered them to tails left over.
[13:44:36] <skunkworks_> I don't have good luck pulling the caps through the board..
[13:45:12] <ssi> once you pop 'em off desoldering the tails should be pretty easy
[13:45:29] <ssi> I revived my tek tds420 scope years ago by replacing all the surface mount caps in it
[13:47:14] <skunkworks_> I tried that on 1 or 2 just to see. I have pulled them through and then drilled the holes back out before.
[13:48:17] <archivist> good hot iron and a solder sucker
[13:48:45] <ssi> yep
[13:49:11] <archivist> and asbestos fingers
[13:49:18] <ssi> or tweezers :)
[13:49:27] * ssi has asbestos fingers though
[13:49:36] <archivist> fresh blob of solder on both pins
[13:49:46] <ssi> or some flux
[13:51:39] <skunkworks_> next time
[13:52:11] <ssi> tonight I have to pull and replace a qfp64 arm
[13:52:14] <CaptHindsight> I've worked at places where the standard operating procedure was to just tack the new caps onto the opposite side of the pcb if there was room
[13:52:54] <skunkworks_> thought about that.. ;) not enough room between the botom of the board and the case..
[13:54:01] <CaptHindsight> funny thing is about it is that those shops are still in business where the ones that did a good job got bought out by the hacks
[15:39:47] <mozmck> Is there a way to unload a gcode file so there is nothing loaded?
[15:39:58] <seb_kuzminsky> alt-ctrl-del
[15:40:14] <mozmck> power button? :)
[15:40:30] <seb_kuzminsky> i dont think there's a gentler way
[15:40:36] <seb_kuzminsky> you could load an empty file maybe?
[15:40:44] <seb_kuzminsky> err, one consisting of just m2
[15:40:50] <seb_kuzminsky> or maybe that will crash the system, i dont know
[15:41:01] * seb_kuzminsky <-- very helpful
[15:41:13] <mozmck> Hmm, I'll see if I can tell it to load an empty file.
[15:41:56] <mozmck> We need to close it because if we have a file open, we apparently cannot overwrite it with an external CAM program.
[16:07:01] <micges> mozmck: file with just m2 works fine
[16:07:32] <mozmck> micges: thanks.
[16:24:08] <seb_kuzminsky> mozmck: there is an EMC_TASK_PLAN_CLOSE message (from the GUI to Task), which sounds related to the EMC_TASK_PLAN_OPEN that opens a gcode file, but Task does not implement EMC_TASK_PLAN_CLOSE, so who knows whats up with that
[16:24:37] <mozmck> Hmm, somebody thought of it but never finished?
[16:24:50] <seb_kuzminsky> mmmaybe
[16:25:43] <mozmck> where is the code that becomes the linuxcnc.so python module?
[16:26:22] <mozmck> I find emcmodule.cc under usr_intf/axis/extensions - and it seems to have the right stuff in it
[16:26:41] <mozmck> But that's a rather odd location?
[16:26:56] <seb_kuzminsky> yep, that's the one
[16:27:00] <seb_kuzminsky> and yep, that's an odd location
[16:27:07] <mozmck> well, ok.
[16:27:29] <micges> probably it's from times when axis was standalone program
[16:28:15] <mozmck> makes sense. would it be hard to move to a more obvious location?
[16:29:16] <seb_kuzminsky> another odd thing about the python module: it makes a status object in python that is like the status struct in shared memory that C uses, but it renames a bunch of the fields
[16:29:33] <mozmck> oh, interesting.
[16:29:45] <seb_kuzminsky> it would not be that hard to move it, and it would probably be a good cleanup to do in master
[16:30:14] <micges> also opengl stuff could be factored out
[16:30:33] <mozmck> I wonder if all the python module code could go in their own subdirectory. canonmodule.cc, gcodemodule.cc, etc.
[16:30:53] <seb_kuzminsky> oh yeah, theres a bunch of gremlin(?) stuff in the linuxcnc.so python module
[16:31:08] <mozmck> interesting.
[16:31:16] <seb_kuzminsky> mozmck: that would make sense to me
[16:31:41] <seb_kuzminsky> is that all jepler code? i suggest you let him weigh in, he may think of something you and i dont
[16:32:19] <mozmck> I'm pretty ignorant so that would not be hard on my part :)
[16:39:52] <mozmck> seb_kuzminsky: sounds like you made eric happy
[16:41:58] <jepler> you can't take away names from Python without breaking code
[16:42:22] <mozmck> take away names?
[16:42:35] <jepler> "it renames a bunch of fields"
[16:42:47] <mozmck> oh, that, yes.
[16:42:48] <jepler> if you change the names so that they match C++, you break the software that uses the current names
[16:43:08] <mozmck> what about moving the python module files to different locations?
[16:43:15] <seb_kuzminsky> you could make new names that match the C field names, without taking away the old backwards-compatible renamed names
[16:43:34] <jepler> seb_kuzminsky: yes if the C++ names are better
[16:44:07] <seb_kuzminsky> i dont know if one's better than the other, but if they're the same i wont be surprised when i switch languages ;-)
[16:44:30] <jepler> yes
[16:44:42] <jepler> younger me thought each name he was choosing in Python was better than the one in C++
[16:45:09] <jepler> similarly, removing opengl related stuff from linuxcnc module to a new module will break code in the wild
[16:45:18] <jepler> because the name linuxcnc.logger or whatever it is will be gone
[16:45:32] <seb_kuzminsky> i won't get involved in a fight between young-jepler and old-jepler
[16:45:42] <jepler> so you will at least need to deprecate first and move later
[16:46:08] <seb_kuzminsky> maybe add the external opengl module, mark the internal one as deprecated, wait a release cycle for out-of-tree guis to catch up, then remove the internal one
[16:46:13] <jepler> i.e., create new module linuxcnc.gl, and have linuxcnc module import linuxcnc.gl.* during the deprecation period
[16:46:20] <seb_kuzminsky> heh
[16:46:57] <jepler> and another thing: if we think we're going to get back to the lui project, then why have churn now that we're going to re-churn soon
[16:47:17] <seb_kuzminsky> oh yeah
[16:47:19] <mozmck> hmm.
[16:47:23] <seb_kuzminsky> i was thinking about that just earlier today
[16:47:30] <mozmck> I wouldn't mind helping on that project.
[16:48:05] <seb_kuzminsky> i think it's an easy project to jump in and help with now - just pick one of the NML-interface commands and convert it
[16:48:31] <seb_kuzminsky> but part of the linuxcnc.so cleanup can happen in parallel with lui: the move to a less axis-centric place
[16:48:34] <mozmck> What is it being converted to? I saw discussion here about a "wire" protocol vs API
[16:48:53] <seb_kuzminsky> an API for now
[16:48:56] <jepler> stage 1 is to define a "C" API
[16:48:58] <mozmck> ok
[16:49:06] <jepler> the implementation will be NML
[16:49:10] <seb_kuzminsky> if you look at the liblinuxcnc-ui branch you'll see where it's all taking place
[16:49:30] <mozmck> I pulled it the other day but haven't looked yet :(
[16:49:44] <seb_kuzminsky> there's individual commits that move each NML command from a hodge-podge of duplicated, hand-coded C to a single copy of hand-coded C
[16:50:14] <seb_kuzminsky> plus jeplers auto-generated functions to access status fields
[16:50:50] <mozmck> thinking of status, is there a HAL pin to indicate a probing move?
[16:51:13] <jepler> mozmck: probably, did you read the motion manpage?
[16:51:38] <mozmck> I see a motion.motion-type mentioned under debugging and subject to arbitrary removal
[16:52:01] <jepler> anyway, in a second stage a developer can replace the lui-to-task communication with something besides NML, like json or whatever is fashionable now
[16:52:11] <mozmck> and the note at the bottom "This manual page is horribly incomplete."
[16:52:17] <seb_kuzminsky> haha
[16:52:22] <seb_kuzminsky> we rock
[16:52:29] <mozmck> oh, and the date of 2007
[16:52:36] <mozmck> :)
[16:53:00] <jepler> then I guess there's not
[16:53:01] <mozmck> I'll look more.
[16:53:53] <seb_kuzminsky> "it probably wouldn't be hard to add" he said, not having looked at the relevant code