Back
[01:30:27] <terkaa> Hi everyone
[01:30:39] <terkaa> I am just trying to learn working with git
[01:30:49] <terkaa> Is this usable
https://github.com/terkaa/linuxcnc
[07:07:36] <jthornton> where are the predefined parameters in the code? The docs seem to be behind...
[07:08:43] <jthornton> never mind I found #<_feed> in the docs
[08:21:08] <KGB-linuxcnc> 03John Thornton 052.7 c28692e 06linuxcnc 10docs/src/gcode/overview.txt Docs: correct misleading descriptions * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c28692e
[09:10:22] <seb_kuzminsky> terkaa: yeah that's on the right track
[09:11:27] <seb_kuzminsky> it would be easier for you if you did your work on a feature branch, not on the default "master" branch, but it's not a show-stopper
[09:12:38] <seb_kuzminsky> it'd be easier for us if your commit messages had more detailed descriptions of what the commit did
[09:12:56] <seb_kuzminsky> we have some guidelines on "effective use of git" here:
http://linuxcnc.org/docs/devel/html/code/contributing-to-linuxcnc.html#_effective_use_of_git
[09:13:43] <seb_kuzminsky> and finally, your commits need to be "signed off":
http://linuxcnc.org/docs/devel/html/code/contributing-to-linuxcnc.html#_signed_off_by_policy
[09:15:59] <terkaa> Ok I will study these
[09:39:09] <seb_kuzminsky> i still haven't read your code in detail, these are all just simple mechanical issues
[12:14:32] <terkaa> Added more comments, signed off
[13:31:44] <mozmck> seb_kuzminsky: have you had a chance to look at issue #177?
[13:31:59] <mozmck> https://github.com/LinuxCNC/linuxcnc/issues/177
[13:32:43] <mozmck> I was able to duplicate that just now. I'm somewhat surprised I didn't figure out how to trigger that problem myself sooner.
[13:45:25] <KGB-linuxcnc> 03John Thornton 052.7 9708593 06linuxcnc 10docs/src/config/integrator-concepts.txt Docs: add info about the basic directory structure * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9708593
[14:13:11] <pcw_mesa> seb_kuzminsky: yeah I forgot to install numpy on that system, but it (Mint18) still has
[14:13:12] <pcw_mesa> (Python version?) issues
[14:14:24] <pcw_mesa> File "/usr/lib/python2.7/dist-packages/PIL/Image.py", line 695, in tostring
[14:14:26] <pcw_mesa> "Please call tobytes() instead.")
[14:14:28] <pcw_mesa> Exception: tostring() has been removed. Please call tobytes() instead.
[14:28:05] <skunkworks> mozmck, do you think that is what your customer was seeing?
[15:01:32] <seb_kuzminsky> pcw_mesa: whoops!
[15:01:46] <seb_kuzminsky> do you know if the wheezy (et al) numpy has tobytes()?
[15:20:12] <pcw_mesa> let me check
[15:43:19] <pcw_mesa> Not exactly sure where to look
[16:19:24] <seb_kuzminsky> pcw_mesa:
[16:19:26] <seb_kuzminsky> python -c "import PIL.Image; print 'tobytes' in dir(PIL.Image.Image)"
[17:01:05] <cradek> False
[17:10:45] <cradek> ... , 'tell', 'thumbnail', 'tobitmap', 'tostring', 'transform', 'transpose', 'verify']
[17:50:43] <micges> mozmck: about issue #177: tp reset blending to g64 after aborting
[18:23:10] <seb_kuzminsky> cradek:
https://cdn.meme.am/instances/500x/9158596.jpg
[18:23:32] <seb_kuzminsky> mozmck: i've abandoned my effort to fix that and thrown my lot in with state-tags
[18:26:57] <cradek> I sympathize with that sentiment 99%
[18:37:34] <mozmck> seb_kuzminsky: I really need to fix it in 2.7 one way or another. I will probably have some questions for you later. Got the flu right now :-(
[18:37:56] <mozmck> micges: any ideas on it?
[18:39:32] <micges> I have patched this to reset to g64 p0.01 after abort
[18:40:21] <micges> then I'm always on g64 p0.01
[18:42:08] <mozmck> micges: that was one option I was thinking of, but I would have to find where to do it.
[18:42:22] <mozmck> Is that patch something you could share?
[18:42:39] <micges> sure
[18:42:58] <mozmck> I would think ideally it would leave that setting alone on abort - but no idea how hard that would be.
[18:44:04] <cradek> without statetags there's no such thing as leaving settings alone, because they're dependent on how far you've read ahead
[18:44:38] <cradek> if you read ahead to m2, everything is reset
[18:48:04] <jepler> provide a function image _tobytes that calls one method if it exists otherwise the other one. that is gratuitous breakage on the part of pil/pillow
[18:58:39] <pcw_mesa> why would they not just leave it backwards compatible
[18:59:09] <mozmck> cradek: I would have though G64 state would have remained until changed - at least for a session?
[18:59:15] <seb_kuzminsky> pcw_mesa: because they hate our freedom
[18:59:20] <seb_kuzminsky> too soon?
[18:59:34] <pcw_mesa> :-)
[18:59:45] <seb_kuzminsky> mozmck: yes, it stays put until changed by an explicit g61/g64 gcode
[19:00:41] <mozmck> or if there is abort :-)
[19:00:42] <seb_kuzminsky> cradek's saying (i think) that if you're running a program that has those gcodes in it, your interpreter state will reflect the read-ahead point, not where in the stream motion is (which is what the user expects and wants)
[19:01:41] <seb_kuzminsky> yeah, problem (as i understand it) is that when you abort or m2, you get the g61/g64 state of the read-ahead point, not the point of the program that corresponds to where the controlled point currently is
[19:01:43] <mozmck> I guess it is possible that someone could change G64 in the middle of a file
[19:01:45] <seb_kuzminsky> if that makes sense
[19:02:23] <mozmck> I don't think the readahead is the problem unless it gets reset on M2 like cradek said.
[19:02:39] <seb_kuzminsky> what does m2 do with tolerance? i'd assume it leaves it alone (so it retains whatever state it had just before m2), is that not what happens?
[19:02:39] <mozmck> I only set it at the beginning of a file.
[19:02:51] <seb_kuzminsky> well me too, that's the non-crazy thing to do ;-)
[19:03:04] <mozmck> (06:18:58 PM) cradek: if you read ahead to m2, everything is reset
[19:03:19] <seb_kuzminsky> hmm
[19:04:22] <seb_kuzminsky> i'll take a look at it after dinner
[19:05:18] <seb_kuzminsky> issue #170 doesn't mention m2 or normal program end, just abort (via estop)
[19:05:25] <seb_kuzminsky> argh no, dinner first, then hacking!
[19:05:27] <seb_kuzminsky> bbl!
[20:08:49] <KGB-linuxcnc> 03Dewey Garrett 05master b1113ad 06linuxcnc 10lib/hallib/sim_lib.tcl sim_lib.tcl: reduce setp cmds for equiv hal file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b1113ad
