#emc-devel | Logs for 2010-12-17

Back
[00:00:23] <andypugh> Ever worked with spalted beech? I have seen some very spectacular stuff done in that
[00:02:44] <dgarr> not beech but spalted maple, hackberry, buckeye i've done
[00:03:08] <andypugh> I have seen it (and cursed it) in structural oak.
[00:08:13] <andypugh> The Burl vases etc, do you turn them ignoring the missing bits, or are they removed later? I really like http://www.panix.com/~dgarrett/phpv1/index.php?img=%2Fuserdirs%2Fdgarrett%2Fphpv1%2F13-Burl%2F0009.jpg
[00:09:56] <dgarr> you ignore them, largish holes are helpful as, with bright lighting, you can see the tool inside, and you can clear chips easier (when stopped)
[00:12:39] <andypugh> Rather like these (metal) machining videos? http://www.phorn.com/products/grooving/ (you need to click the "Film" link)
[00:17:49] <dgarr> yes, sort of -- hollow turning in wood was pioneered by David Ellsworth, he hollows by hand large bowls through an opening of an inch diameter or less to a uniform thickness of about 1/8 inch http://www.ellsworthstudios.com/david/gallery.html
[00:19:52] <andypugh> Yes, I was looking at that in a book I just found "New masters of woodturning" (which you seem to be in)
[00:22:54] <dgarr> yes ( an honor to be included)
[00:24:11] <andypugh> I can see mechanistic solutions to that problem (turn the OD, then use a curved chisel with a guide roller a diminishing distance away) but I suspect that is not how it is done
[00:26:32] <dgarr> Ellsworth and many others use just hand tools, new develpments inlcude devices that arrest or resist torque and keep the tool on center.
[00:28:29] <dgarr> the big problems are removing chips, patience, and measurment. now days, many use a laser pointer rigged onto the cutting tool so it points on the work where tool tip is and measuring is made easier
[00:29:13] <andypugh> Clever, but by that point you might as well use CNC :-)
[00:29:45] <dgarr> it's a slippery slope
[00:30:20] <andypugh> Talking of which, I think I might have had a patentable idea today
[00:30:52] <andypugh> I am thinking of a quirk on the conventional automatic boring head
[00:32:08] <dgarr> we were always advised to keep a good hardbound notebook, date all entries, and use ink for those kind of ideas
[00:33:04] <andypugh> I am never sure whether online discussion means that you can never patent, or have proof of patent
[00:36:57] <andypugh> Of course, it has probably already been done, and is already for sale in eBay
[01:48:14] <jepler> dgarr: perhaps it would be better design to routinely return "break" from those python functions called for events, but I don't think anything else is looking for F1 keypresses anyway.
[01:48:30] <jepler> dgarr: so the shortest answer to "why" is "I didn't know of a specific reason to do it there"
[01:49:05] <jepler> whenever tkinter binds an event to a python function, it includes the 'break' comparison so seeing it in the tcl side of the binding doesn't necessarily mean the python author intended to ever "break"
[01:50:43] <dgarr> i copied the bindings in an embedded tab and unknowningly had the function executed twice because of two bindtag entries. when executed twice, the toggle had no net effect.
[01:51:00] <dgarr> would you consider a patch that added return "break" to those two functions?
[01:56:13] <dgarr> returning "break" would ensure that no subsequent bindings will be executed -- seems like a reasonable expectation for the estop_clicked
[01:56:56] <dgarr> but i can add a break to my binding too, maybe that's safer
[02:30:29] <jepler> if adding the break in axis is the best solution I'll put it in
[02:35:33] <dgarr> i'm not sure what's best -- i was surprised seeing python insert the test and really surprised when i got two toggles. i think i understand what's happening now and that is probably sufficient for my purposes -- it did take a while to see what's happening there
[02:42:55] <jepler> ok
[10:14:51] <mhaberler> psha: around?
[10:15:53] <psha> yes
[19:24:11] <psha> jepler: what do you think about using gladevcp in similar place to pyvcp?
[19:24:21] <psha> besides that it's crap by design :)
[19:25:34] <alex_joni> psha: I like the extra tab (along with preview, and large digits)
[19:27:21] <psha> alex_joni: extra tabs are already there :) i hope keyboard issues are solved now so maybe it makes sense now to allow using gladevcp panel where pyvcp one is placed
[19:29:54] <jepler> having pyvcp *and* gladevcp is worse than having just one of them
[19:32:07] <psha> and -- having them bot displayed or having ability to display one or another?
[19:32:21] <andypugh> Hmm, serial.c Zero kB. That's not good.
[19:32:57] <andypugh> Somehow the entire contents of the file have disappeared
[19:33:06] <jepler> psha: I mean, if a user wants VCP tabs and VCP at the right, it's better if it's the same VCP
[19:33:12] <jepler> andypugh: ouch
[19:33:49] <andypugh> Is there an easy way to check just that file back out of the last commit?
[19:34:12] <psha> git log serial.c
[19:34:24] <psha> git checkout serial.c - if you changes are local
[19:34:56] <andypugh> It's sserial.c actually, my poor typing skillz might explain the problem.
[19:35:04] <psha> git checkout COMMIT file.c - for given commit
[19:35:14] <andypugh> The whole file is local...
[19:35:49] <psha> is it in git?
[19:36:15] <psha> then just git checkout sserial.c
[19:36:22] <psha> this will restore it to HEAD
[19:36:33] <psha> or from - from which side too look :)
[19:36:46] <andypugh> It's not in HEAD
[19:36:51] <andypugh> (I don;t think)
[19:37:36] <psha> heh, if it's not recored in git (even not in index) then git won't help you :)
[19:37:54] <psha> open disk device and look for strings from that file
[19:38:07] <psha> :)
[19:38:11] <psha> and then install git-wip
[19:39:21] <andypugh> Git gui shows that the changes to that file involve deleting all of it. Worst case I can copy and paste from the diff window and delete all the leading "-" signs :-)
[19:40:18] <psha> then it's in git :)
[19:40:26] <psha> you don't need to copy them
[19:40:40] <psha> if 'git diff sserial.c' shows same then just pipe it to 'patch -p1'
[19:41:10] <psha> 1 is number of dirs to strip
[19:47:37] <andypugh> git checkout brought it back, I just need to remember what I changed last time I looked at it (2 weeks ago)
[19:49:12] <psha> git-wip will help you in such cases
[19:52:02] <mhaberler> wip?
[19:52:45] <psha> https://github.com/bartman/git-wip
[19:52:49] <psha> work in progress
[19:54:02] <psha> tool that stores all intermidiate work into wip/* branches
[19:54:44] <andypugh> Hmm, well, currently I am looking at using the diff as the actual file. I just need to find a way to erase all the leading "-" signs, without totally messing up any maths.
[19:55:12] <psha> git diff | patch -p1 -R
[19:57:54] <andypugh> When I say "diff" I mean "what I copied out of a git-gui window.
[19:59:19] <psha> heh, you may obtain that data without 'copy' - issue cli command doing what gui does
[20:00:39] <andypugh> My situation is a little complicated by the fact that I do my development on a Mac...
[20:01:10] <skunkworks> WHAT!?
[20:01:13] <skunkworks> ;)
[20:01:20] <andypugh> Well, sort-of.
[20:02:57] <andypugh> The EMC machine is a pile of loosely-bonded parts on the floor in the corner, and I edit the code in XCode on a Mac with the EMC src remotely mounted. I compile in an ssh terminal.
[20:03:25] <andypugh> The Mac has a nice big screen and a comfy chair.
[20:04:08] <psha> andypugh: and Jobs will come to your house and break your mac if you use cli? :)
[20:04:23] <andypugh> Yes
[20:05:05] <andypugh> Anyway, I am back to where I was now.
[20:45:34] <alex_joni> ?dmkk mjk jmjk;kjkl.,
[20:47:15] <alex_joni> sorry bout that
[20:47:27] <alex_joni> * alex_joni hides the laptop from his son again
[21:13:18] <psha> bb