Back
[03:58:07] <cradek> jepler:
[03:58:08] <cradek> If your bugfix is approved for v2.4_branch, then it will also be fixed on master when changes in the branch are merged up.
[03:58:25] <cradek> this doesn't follow from my step-by-step where the merge with master is already done
[13:26:04] <jepler> cradek: sorry, I probably muddled the waters by saying that.
[13:27:53] <jepler> cradek: I'm still looking for the optimum mix between our old cvs-style practices and what we can do with git. I want to try merging v2.3_branch into master as a way to get bugfixes done on both branches, but that plus my insistence on reviewing everything before it goes into v2.3_branch means that someone may wish to merge the fix into master while waiting for it to get my nod for 2.3.
[14:36:42] <cradek> jepler: what do you think of the rehoming patch?
[14:37:50] <cradek> I think the idea is fine, but I can't judge the implementation (except to say that "YES/Cancel" is right out)
[14:38:27] <jepler> so you think hardly anybody would be annoyed by having to confirm homing an already-homed machine?
[14:40:08] <cradek> on a machine with real homing I bet that is true (why do it more than once?)
[14:40:39] <cradek> if someone uses homing to set the origin willynilly, I bet it would be irritating
[14:40:53] <jepler> oh, well, that person I want to discourage :-P
[14:41:07] <cradek> yes I also think that's a poor way to handle origins
[14:41:50] <cradek> I hadn't thought of it before, but yes I bet we'd hear from them.
[14:44:58] <cradek> hmm, we can actually tell whether the machine has real homing
[14:45:11] <cradek> perhaps we could skip the confirmation if their velocities are zero
[14:46:07] <cradek> logger_dev: bookmark
[14:46:07] <cradek> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-02-09.txt
[14:47:45] <jepler> I guess I don't mind causing that user a little trouble
[14:47:49] <jepler> it is a teaching moment
[14:47:50] <ries> With my limited mind :D this was the only way I could think off I am willing to accept any change... The way I tied to implement is , was to show that dialog the least amouth possible...
[14:49:23] <ries> so, basicly if a user has a machine with real homing, then we don't want to show the dialog 'are you sure' right? Because it would always home at teh correct homing point, instead of in the middle of nowhere...
[14:49:36] <cradek> well I was thinking the opposite
[14:49:44] <cradek> I guess we don't know when the prompt is appropriate
[14:50:05] <cradek> some people (incorrectly, in some opinions) use homing to set the workpiece origin
[14:50:18] <cradek> on machines with no real homing setup
[14:50:27] <cradek> I think those people would be irritated, but I'm only guessing
[14:51:23] <ries> But they use the software incorrectly... since you need to touch off, not re-home..
[14:51:42] <cradek> that fact does not make us not hear them complain :-)
[14:51:43] <ries> then I wonder, are there any situations where a users needs home to set his workpiece?? (I don't think so but...)
[14:52:18] <cradek> I don't think so. in my thinking, homing establishes the machine origin, not any workpiece origin
[14:52:46] <cradek> but many people seem to work with no particular machine origin and therefore no soft limit protection
[14:53:28] <cradek> my experience is that often those folks are averse to any suggestion of a better way to do it
[14:54:16] <ries> yes I see, but don't these people have limits on there machine? Even a lathe has....
[14:54:45] <cradek> no they generally don't have limits
[14:56:22] <ries> I guess the reason might be that nobody complains about the re-homing issue is that most people uses ballscrews with mills in the EMC word (just a guess) they don't have big issues with jogging fast and a heavy gantry moving around.
[14:57:41] <ries> One thing that can be done to keep these people happy (and me :D ) is having the dialog pop-up only when some option in a ini file is set, but I wouldn't like to add more options for these stuff..... OR the dialog can have a tickbox that states 'don't ask me again'.... (just trowing out some ideas)
[15:04:18] <jepler> cradek's idea (base it on home velocity being zero) will not give this protection to the people who would benefit most from it: the ones who "home by eye" (so the home is good enough for soft limits to be helpful, but not repeatable enough that you'd want to do it during a run without good cause)
[15:05:26] <skunkworks_> sounds like it needs to be an ini setting. So the user can descide what happens when the home button is pushed. re-home or ask... maybe
[15:06:00] <ries> jepler: me as a newbie... what is "home velocity" ?
[15:06:18] <ries> just the velocity during a homing sequence or something else?
[15:06:25] <jepler> ries: it's an item in the inifile. I think it's spelled [AXIS_#]HOME_VELOCITY
[15:07:09] <JT-Work> http://www.linuxcnc.org/docview/html//config_ini_homing.html
[15:07:11] <jepler> When it's 0, then homing just takes the current position and uses it as the home position
[15:07:31] <ries> clear...
[15:08:28] <ries> cradek, you said : "some people (incorrectly, in some opinions) use homing to set the workpiece origin" how do you know?
[15:09:11] <jepler> * jepler has an "aha" moment about the image-to-gcode bug
[15:11:44] <jepler> w, h = im.size
[15:11:44] <jepler> nim = numarray.fromstring(im.tostring(), 'UInt8', (h, w)).astype('Float32')
[15:11:56] <jepler> obviously there's some confusion about whether arrays are row-major or column-major
[15:12:03] <cradek> ohhhh
[15:12:24] <cradek> ries: just that they've said so
[15:12:25] <jepler> I always tested with torus.png which happens to be square
[15:13:48] <ries> cradek: ok...
[15:14:50] <SWPadnos> the same people often continue by saying something like "I never have bad G-code, so why would I care about limits?"
[15:14:52] <cradek> I like the idea of "[ ] Don't ask me again"
[15:15:03] <cradek> SWPadnos: I wasn't going to name names...
[15:15:10] <SWPadnos> me either, I think :)
[15:16:48] <jepler> hm, I wonder if acemi ever tested my fix for empty ctrl_type
[15:19:11] <jepler> * jepler finds it in one of his trees
[15:19:49] <ries> SWPadnos: for me it's mostly a jogging issue actually...
[15:20:29] <ries> cradek: if I where to implement a 'don't ask me again' feature, where would I store the info if teh users want's to see it again or not?
[15:21:07] <SWPadnos> that could be per run, you don't need to save it
[15:21:12] <SWPadnos> so just a variable
[15:21:19] <cradek> disagree with SWPadnos
[15:21:33] <jepler> ap.getpref(), ap.putpref()
[15:21:39] <cradek> I think you'd want to use AxisPreferences
[15:21:41] <SWPadnos> you could also just add a menu item "disable home button"
[15:22:00] <ries> the idea was to prevent a other menu item....
[15:22:49] <jepler> when you get "never ask this again" checkboxes, you'll also inevitably need a way to restore all questions (typically a menu item)
[15:23:05] <cradek> I was just going to ask that (and ick).
[15:23:21] <ries> it also did pop up in my mind...
[15:23:23] <jepler> there's one other thing that is obvious to add a "don't ask again" checkbox to: "program exceeds limits", since that's unreliable on certain machines
[15:23:50] <cradek> hmm, true
[15:23:53] <jepler> (users will also want it for the must-home-before-running, but that they'll have to do in the inifile)
[15:24:08] <jepler> (since it's in task, axis can't override that)
[15:24:44] <ries> cradek: Actually, I like the idea of doing it per session, reason given is that usually you want to home only once per session anyways
[15:25:07] <ries> if you exit and restart axis you properly want to home again
[15:25:22] <jepler> right, but the prompt isn't shown when an axis is unhomed
[15:25:30] <jepler> at least that's how I understood the original patch
[15:26:47] <ries> that's correct, it only shows when teh axis was already homed, when auto homing is enabled it will only pop-up when any of the axis was un-homed
[15:26:55] <ries> sorry...
[15:27:08] <ries> when auto homing is enabled it will only pop-up when all the axis where already homed
[15:27:20] <ries> be back in 10 mins
[15:28:55] <JT-Work> if you have a stepper machine and turn off machine power you would/might want to home again
[15:29:27] <jepler> JT-Work: and if I'm not mistaken you can get that automatically in 2.4 with VOLATILE_HOME
[15:30:24] <jepler> so again that would work OK with this feature
[15:31:19] <JT-Work> yep, I forgot about that
[15:38:46] <jepler> I'd like to try setting the sf bugtracker to mail emc-developers for all bug activity, not just when a new bug is filed. I don't think this will generate a whole lot of traffic. Anyone have a strong opinion?
[15:39:18] <micges_work> agree
[15:41:18] <cradek> +1
[15:41:32] <ries> the current question is (I think) are we going to show a 'Don't ask me again' message? The only reason for doing that tick box is for teh people that uses the home button to position there workpiece. For all (I think) other pe
[15:41:57] <ries> All other people don't want to re-home when a machine is already re-homed, because there soft limits are screwed
[15:43:59] <jepler> yes, that's my understanding too
[15:44:09] <ries> adding a tickbox that is per session is easy, just a var you remember... But doing this across different sessions (start/stop axis) we need to have a framework to reset these variables.
[15:44:31] <jepler> I'd rather teach those people to use "touch off" than add the "don't ask again" button to the new homing dialog
[15:44:55] <jepler> (well, I'd rather they learn; I don't really want to teach them :-P)
[15:45:25] <cradek> I'm now mostly ambivalent - adding it is fine with me - not adding it is fine with me
[15:45:48] <ries> I think these people started to mis-use the home for positiong there workplace because the touchoff and home buttons are to close on the screen (and they don't read the manual)
[15:46:07] <cradek> if it takes focus and has the usual keyboard shortcuts, it's not going to be much pain for anyone, no matter what
[15:47:33] <ries> Good point, I don't think I tested keyboard shortcuts.. they are added, just not tested...
[15:47:58] <cradek> will this popup happen when pressing Home or Ctrl-Home on the keyboard too?
[15:48:03] <cradek> (imo it should)
[15:50:04] <ries> cradek: the question boxes are added to home_axis and home_all_axis
[15:51:13] <ries> Just tested, and they dialog pop's up
[15:51:37] <cradek> ok
[15:52:05] <ries> dialog box doesn't respond to keyboard shortcuts, so I will check that out and provide a new patch
[15:52:12] <cradek> bizarre, I get the same error running master that stuart reports, but I thought it ran before: AttributeError: 'cairo.ImageSurface' object has no attribute 'get_data'
[15:52:38] <cradek> ries: fix it so it says the standard OK/Cancel too, please
[15:52:56] <ries> ok...
[15:52:59] <ries> ok => enter
[15:53:08] <ries> cancel => escape
[15:53:10] <cradek> (even though it's a yes/no question, that's the standard that the world has picked)
[15:53:10] <ries> right?
[15:53:26] <cradek> yes, and space is also ok, I think
[15:54:44] <ries> np..
[15:54:54] <ries> auto of curiosity, what time zone are you guys in?
[15:55:31] <jepler> -0600, US Central
[15:55:48] <ries> -5 here, Ecuador
[16:00:49] <CIA-81> EMC: 03jepler 07master * r9110af6b2b5a 10/lib/python/glnav.py: work around absent ImageSurface.get_data
[16:01:05] <jepler> a lot of us are in the americas. alex_joni and micges are two european exceptions.
[16:02:14] <cradek> jepler: that fixes it, thanks
[16:04:01] <cradek> huh, my dro zeroes have dots here (6.06) - at home (9.?) they didn't
[16:04:37] <cradek> cursed dots
[16:05:17] <jepler> groan
[16:05:19] <jepler> I hate fonts
[16:05:43] <cradek> me too, especially most of them
[16:05:48] <jepler> if only nobody had ever discovered that we could make the "same" letters with slightly different shapes we wouldn't have this problem.
[16:06:06] <jepler> I mean, how is it possible that 0 can be shaped this way *and* that way? It flies in the face of logic.
[16:06:12] <jepler> bbl
[16:06:25] <cradek> that dot is really the only thing wrong with bitstream vera sans mono
[16:34:18] <jepler> hm, once I was able to repeatedly pop the "re home" window up, so that I had several showing at the same time
[16:41:23] <ries> Hmm should I create a patch against my last patch or a complete new patch?
[16:42:01] <cradek> probably a new patch is best
[16:42:12] <jepler> to add the "don't ask again"? I don't think it's clear that we want that.
[16:42:53] <ries> jepler: yes... I thought it was already clear... what are your against?
[16:42:58] <jepler> but if you have refinements to make, put them in the same commit with "git commit --amend"; that will help you get one patch that does all the changes for this feature.
[16:45:01] <jepler> the only problem we've identified in the patch (users who use "home" to set workpiece origin) is fixed by using touch off.
[16:47:24] <ries> My 'problem' (although I understand a bit against for the patch) is that users do use there software incorrectly, if used correctly it's not really a issue
[16:51:26] <ries> excuse me for asking stupid git questions... when I use git commit --amend it doesn't create a new patch file? (svn seems to work totally different)
[16:51:41] <jepler> you don't get a patch file until you use git format-patch
[16:51:49] <jepler> yes git is very different than svn
[16:53:18] <ries> jepler: if I use now git format-patch then I don't see my changes, only my old one... do I need to commit this locally?
[16:55:49] <jepler> right now, does 'git show' (which on its own shows just the most recent commit) show your original commit, the one you sent to the mailing list as a diff?
[16:55:59] <jepler> and 'git diff' shows the incremental changes you made since then?
[16:56:31] <ries> git show shows me teh difference between this change and my last change, not between the origional
[16:56:48] <ries> git diff shows nothing
[16:56:57] <jepler> OK, next let's look at what this shows: git log --oneline origin/master..
[16:57:21] <jepler> that will show one line for each commit you've made on your own system
[16:58:01] <jepler> are there two lines, one for the original commit that you sent as a patch and above it a line for the subsequent change?
[16:58:24] <ries> two lines
[16:59:11] <jepler> OK, that just means that when you made the second set of changes you did "git commit" alone, not "git commit --amend"
[17:00:41] <ries> may be I did something wrong teh last time? I was expecting to create a ptch against the online repro, not something I did locally
[17:00:55] <ries> Should I just delete git and download it again?
[17:01:41] <jepler> nah, that's almost never the solution
[17:02:14] <jepler> if you want, you can just send the second patch to the mailing list; if we decide to include it, I can make the two commits into just one
[17:02:44] <jepler> git format-patch -1 will create a new 0001-*.patch file for your most recent commit, which consists of your changes since the first message
[17:02:52] <ries> can I uncommit locally?
[17:03:27] <jepler> yes, there are at least two ways to change your two local commits into one commit. I'd be happy to tell you about them if you want to learn.
[17:04:26] <ries> I don't have a problem to learn... I have only used SVN in the past, git is new for me
[17:06:01] <jepler> OK. The way I would do it is: git rebase -i origin/master. on the second line, change "edit" to "squash", and edit the editor. revise the change message so that it describes the new commit accurately, and save/exit the editor again.
[17:07:53] <jepler> origin/master names the version you got last from git.linuxcnc.org with git clone or git pull, and so 'git rebase -i origin/master' means something like 'give me a chance to revise all the commits that come after origin/master' (i.e., your commits that you made locally with 'git commit')
[17:08:13] <ries> I just executed git rebase -i origin/master, then my editor poped up, you did mean I needed to edit something there?
[17:08:17] <jepler> oops, the instruction should have said 'change "pick" to "squash"'
[17:09:29] <ries> this is what I get :
http://pastebin.com/d7210598f
[17:09:56] <ries> taht I see in GNU nano...
[17:10:00] <jepler> change it to say:
http://pastebin.com/m6e63601d
[17:11:54] <jepler> (on line 2, change "pick" to "squash"; this means that git will turn the two commits into a single commit)
[17:13:33] <ries> done that... now it comes with a other editor, so now I must combine teh two commit messages, right?
[17:14:09] <jepler> yes, write one message that describes all the changes
[17:14:30] <ries> done
[17:15:10] <jepler> now 'git show' should show you all the changes together, and 'git format-patch -1' will give you a 0001-*.patch that contains all the changes suitable for mailing
[17:16:03] <ries> yes.. amazing, that worked...
[17:19:52] <jepler> git takes a while to learn, but I feel like it's worth it
[17:29:24] <ries> I think git has some great features indeed not found in svn... for example, I have used svn on fairly big trees (java, adobe flex stuff) and finding patches and stuff took ages, I am on a slow 512KB/sec connection
[17:30:57] <ries> last GIT question... what would have been the correct way to modify the code after I used git format-patch -M origin ?
[17:31:42] <jepler> to make incremental changes to the most recent commit, use 'git commit --amend'.
[17:34:23] <ries> Ahh ok...
[17:34:28] <ries> going to fool around with that
[17:34:37] <ries> just send a new patch to teh ML
[17:35:05] <jepler> will look at it later, bbl
[17:37:02] <ries> jepler: thanks...ttl
[18:03:29] <cradek> jepler: in master in the AXIS preview I'm only getting about 5 updates a second. I think it used to be a lot more smooth on this machine. If I keep it redrawing by slowly panning the display, it is very smooth.
[18:05:28] <cradek> ^ that was demo_sim_cl. sim/axis is smoother for some reason.
[18:07:56] <jepler> DISPLAY]
[18:07:58] <jepler> CYCLE_TIME = 0.200
[18:08:00] <cradek> duh, CYCLE_TIME
[18:08:02] <jepler> yeah, I bet about 5 updates per second
[18:08:14] <cradek> I just found that too. sorry.
[18:08:57] <jepler> np
[18:55:51] <seb_kuzminsky> gweetings, fwends
[18:57:05] <micges_work> hi seb_kuzminsky
[18:58:23] <micges_work> bbl
[19:14:19] <jepler> hi seb
[19:14:46] <cradek> hi seb!
[20:51:59] <cradek> seb_kuzminsky: I took my table apart and started boxing stuff up... the table is at the head of the lathe now, which is sure nice.
[21:45:12] <alex_joni> hi seb_kuzminsky
[22:16:51] <CIA-81> EMC: 03jepler 07master * r79c83be8fada 10/src/emc/usr_intf/axis/scripts/axis.py: Show a prompt when a user re-homes.
[22:19:05] <jepler> ries: congratulations, you're now a co-author of emc.
[22:19:35] <ries> jepler: cool... thanks.. :)
[22:19:44] <ries> this goes into 2.4?
[22:20:01] <jepler> so far I only put it in master, not 2.4.
[22:20:52] <ries> what's teh development runs?
[22:21:08] <ries> Current only bug fixes and now releases also contains new features?
[22:21:29] <ries> so 2.3 will only have bug fixes, 2.4 will have new features and trunc is just 'all' ?
[22:21:45] <alex_joni> ries: that was correct 2 weeks ago
[22:21:48] <jepler> there will probably be one more release of 2.3 which will have only bugfixes.
[22:22:05] <alex_joni> but now 2.4 is in feature freeze - preparing for 2.4.0
[22:22:16] <jepler> 2.4 has a bunch of new features, but the deadline to add them was supposed to be Feb 1, and after that only bugfixes ..we've bent that rule a little bit, though
[22:22:39] <alex_joni> jepler: we should probably send a call for translators for 2.4
[22:22:42] <ries> Oooo crap. I was a tad to late :D
[22:23:29] <alex_joni> I will try to get de and ro into shape these days
[22:23:35] <jepler> alex_joni: great, thanks
[22:23:38] <jepler> and you're right, I should send a messag
[22:23:40] <jepler> e about it
[22:37:05] <CIA-81> EMC: 03jepler 07v2.4_branch * r655325379df5 10/src/emc/usr_intf/axis/scripts/image-to-gcode.py: "extend image" crash on non-square image (SF#2947390)
[22:37:06] <CIA-81> EMC: 03jepler 07v2.4_branch * r5faccbbe8e0e 10/src/emc/usr_intf/axis/scripts/image-to-gcode.py: Merge branch 'extend-image' into v2.4_branch
[22:39:06] <CIA-81> EMC: 03jepler 07v2_3_branch * raab9f23dc2cb 10/src/emc/usr_intf/axis/scripts/image-to-gcode.py: "extend image" crash on non-square image (SF#2947390)
[22:39:21] <jepler> * jepler wonders which version(s) of emc he should put the workaround for the 64bit python-numeric bug in
[22:39:47] <jepler> (instead of slicing a numarray like x[a:b], which erroneously gives a slice with b items in it, slice it like x[a:][:b])
[22:40:15] <jepler> er, that's not right
[22:40:32] <jepler> instead of slicing like x[a:a+b] slice like x[a:][:b]
[22:58:59] <alex_joni> did that fix end up in master too?
[23:03:28] <jepler> not yet
[23:05:00] <alex_joni> ah, ok.. thought I didn't interpret it right :D