Back
[01:32:14] <jmkasunich> any interp folks in here?
[01:32:44] <jmkasunich> thinking about error messages for the g90.1/g91.1 command
[01:32:56] <jmkasunich> it is an error if you don't supply both center coords
[01:33:17] <jmkasunich> that can result in one of 6 messages, or I can compress them to 3, or even 1
[01:33:41] <jmkasunich> "I word missing for absolute center arc in XY plane" <--- 1 of 6
[01:33:59] <cradek> "missing I J or K in G2 command in absolute center mode"
[01:34:11] <jmkasunich> s/G2/arc
[01:34:46] <jmkasunich> but yeah, thats the question - detailed but many, or generic?
[01:34:47] <cradek> btw, for new errors, use ERM("the string here") instead of the list
[01:35:23] <jmkasunich> hmm
[01:35:27] <cradek> maybe I mean ERS
[01:35:30] <cradek> whichever it is
[01:35:44] <jmkasunich> I see ERM(NCE_BUG_PLANE_NOT_XY_YZ_OR_XZ)
[01:35:51] <jmkasunich> that must be the one that takes a code
[01:35:57] <cradek> ERS("Cannot set reference point with cutter compensation in effect");
[01:36:12] <cradek> bbl
[01:36:16] <jmkasunich> you're saying I don't need to define a string in _errors.cc and a code in _return.cc?
[01:36:19] <cradek> right
[01:36:31] <cradek> that makes it so easy, make them as specific as you want
[01:36:43] <jmkasunich> how does translation work with ERS
[01:36:56] <jmkasunich> I thought the reason for _errors was to get them all in one place for translation?
[02:19:06] <cradek> jmkasunich: ERS strings are marked for translation too - see definition of ERS
[02:20:51] <jmkasunich> I did look at the definition, I didn't see anything that screamed out "translate me"
[02:21:03] <cradek> _(string)
[02:21:16] <jmkasunich> oh
[02:21:40] <jmkasunich> if I invoke ERS in two places with the same string, will that result in two identical strings to be translated?
[02:21:56] <cradek> no they should be jonied in the catalog
[02:22:00] <cradek> or joined
[02:22:12] <jmkasunich> right now I have "I word missing in absolute center arc", as well as J and K versions of that
[02:22:18] <jmkasunich> each is invoked twice
[02:22:29] <jmkasunich> I for XY and XZ planes, etc
[02:22:48] <cradek> if you rewrite it as "%c word missing" the translator will only have to deal with one message
[02:23:22] <jmkasunich> how do I pass the char?
[02:23:43] <jmkasunich> ERS("%c word missing in absolute center arc", 'I' )?
[02:25:17] <cradek> yes I think so
[02:25:26] <jmkasunich> guess I can try it and see
[02:25:47] <jmkasunich> I did test the version I have, G90.1/G91.1 are parsed, and the error messages are printed when appropriate
[02:26:07] <cradek> neat
[02:26:31] <jmkasunich> looking at the def of ERS, I don't see how I can get away with passing it a string and a char
[02:26:34] <jmkasunich> it just wants a string
[02:26:48] <cradek> it passes it to setError, which is varargs goo
[02:27:00] <cradek> between varargs, the preprocessor, and C++, I'm somewhat lost
[02:27:59] <cradek> oh maybe you have to use ERF
[02:29:30] <jmkasunich> emc/rs274ngc/interp_convert.cc:149:53: error: macro "ERF" passed 2 arguments, but takes just 1
[02:29:43] <cradek> hm
[02:29:57] <jmkasunich> maybe some extra parens...
[02:31:01] <jmkasunich> that made it compile, testing
[02:32:16] <jmkasunich> works
[02:32:57] <jmkasunich> ERF needs parens: ERF(("format", value, value))
[02:33:07] <cradek> huh
[02:33:41] <jmkasunich> makes sense, it does setError error_args;
[02:33:53] <jmkasunich> turns into setError ("format", value, value);
[02:34:04] <cradek> oh ok
[02:34:42] <jmkasunich> I've been looking at find_ends()
[02:35:07] <cradek> lovely isn't it
[02:35:13] <jmkasunich> I think I need something like find_center()
[02:35:29] <cradek> (our friend indent did that to it)
[02:35:35] <jmkasunich> I was originally thinking I could simply use find_ends() with different inputs, to get I and J after offsets, etc
[02:36:51] <jmkasunich> g53 is legal for arcs isn't it?
[02:37:12] <cradek> don't think so
[02:37:40] <cradek> http://www.linuxcnc.org/docs/devel/html/gcode_main.html#sub:G53:-Move-in
[02:37:56] <cradek> error if: G53 is used without G0 or G1 being active,
[02:38:28] <jmkasunich> yeah - I was thinking of G53 as being a modifier that could apply to any motion
[02:39:27] <jmkasunich> so my find_center doesn't have to worry about that
[02:40:37] <jmkasunich> actually it will be pretty simple
[02:41:30] <jmkasunich> this is gonna have a ripple effect tho
[02:46:19] <cradek> howso?
[02:46:56] <jmkasunich> right now the arc_data functions expect to be passed offsets, but I'm gonna be getting the actual center, not offsets, in find_center
[02:47:15] <jmkasunich> it won't be hard to fix the arc_data functions to expect absolute centers
[02:47:49] <jmkasunich> I suppose I could make find_center return offsets from current position, but that just seems wrong
[02:48:03] <jmkasunich> especially since find_ends returns absolute
[03:02:30] <jmkasunich> cradek: am I confused here? I originally thought that the interp did its work in machine coords, and that find_ends was responsible for removing offsets,etc, to reduce the g-code numbers to raw machine coordinates
[03:03:09] <jmkasunich> but it seems the other way around - find_ends returns the values in the g-code unaltered, UNLESS you are in G53, then it applys offsets
[03:03:24] <jmkasunich> applies
[03:17:53] <jmkasunich> this code is weird
[03:18:28] <jmkasunich> convert_arc2 is called to deal with either ij arcs, or r arcs
[03:19:20] <jmkasunich> the block is passed into it, as well as the i and j values, but not the r value
[03:19:50] <jmkasunich> if its an r arc, the value is extracted from the passed in block, if an ij arc, it uses the args
[03:20:14] <jmkasunich> I understand the reason - because they want to use one function for all three planes
[03:20:23] <jmkasunich> but eww
[03:21:28] <cradek> the interp works in the coordinate systems that are currently active
[03:21:54] <jmkasunich> yeah, that threw me for a loop, but ok
[03:22:05] <jmkasunich> when _are_ the coords converted to machine space?
[03:23:34] <cradek> between the canon calls and the motions being added to the interp_list
[03:24:37] <cradek> the interp lets the canon level know the offsets with ST_OROGIN_OFFSETS and SET_TOOL_LENGTH_OFFSET etc
[03:24:49] <cradek> SET_ORIGIN sheesh
[03:25:01] <jmkasunich> so basically at this level I can ignore offsets
[03:25:27] <jmkasunich> "this level" = convert_arc() and the stuff it calls, like arc_data()
[03:26:17] <cradek> I think so
[03:27:11] <cradek> like find_ends you have to handle only a few things: what to do if the number is not specified in the block (error), what to do if cutter comp is in effect (nothing special in this case?)
[03:27:43] <jmkasunich> find_ends doesn't do any error checking
[03:28:01] <cradek> yes but it handles the case where some words are missing
[03:28:14] <cradek> (by using the old value)
[03:28:28] <cradek> you'll handle that differently (earlier, probably)
[03:28:39] <jmkasunich> the checks for missing words are earlier
[03:28:44] <cradek> are you deciding you don't need find_center because it doesn't do anything?
[03:28:57] <jmkasunich> well, it does a little
[03:29:33] <jmkasunich> I'm debating whether it should be finding the center, or finding offsets
[03:30:56] <jmkasunich> http://www.pastebin.ca/1250042
[03:31:01] <jmkasunich> that is the center version
[03:34:04] <jmkasunich> this hurts my head
[03:34:06] <cradek> that looks right to me I think
[03:34:18] <cradek> took me a while to see that the comp stuff is right
[03:34:28] <jmkasunich> in convert_arc_comp1 if(move == G_2) move = G_3; else move = G_2;
[03:35:25] <jmkasunich> oh, duh, that is just changing 2 to 3, and 3 to 2
[03:35:40] <cradek> right
[03:36:29] <jmkasunich> why isn't radius comp allowed in YZ?
[03:36:48] <jmkasunich> oh, XY is for mill, XZ is for lathe
[03:37:29] <jmkasunich> still, the code seems to imply that I could do a compd move in XZ on a mill
[03:37:52] <cradek> yes you could
[03:38:04] <cradek> that's the cost of having only one interpreter
[03:38:41] <jmkasunich> in reality, XZ and YZ are equally bad for mill, and XY and YZ are equally bad in lathe
[03:39:06] <jmkasunich> we error on one and not the other
[03:39:16] <jmkasunich> why not allow all?
[03:39:51] <jmkasunich> never mind, if I keep digressing I'll never get anywhere
[03:40:02] <jmkasunich> what is scaring me is the amount of coupling between all these routines
[03:40:16] <cradek> yeah it's all icky in there
[03:40:22] <jmkasunich> I don't dare touch most of it
[03:40:31] <jmkasunich> I think I want to get rid of find_center
[03:41:04] <jmkasunich> instead, in abs mode I should find the incremental values that will result in the desired center, and then feed them into the remainder of the code
[03:41:49] <cradek> haha, /* compute other data */ ... then a dozen lines of inscrutable crap
[03:42:33] <jmkasunich> / tread not here, let ye be consumed
[03:42:41] <jmkasunich> lest
[03:43:00] <jmkasunich> * jmkasunich runs away
[03:44:01] <jmkasunich> what worries me is that neither of the convert_arc_comp functions is passed any center info
[03:44:36] <jmkasunich> they pick the info right out of block->i_number, etc
[03:44:53] <jmkasunich> which means, I'll have to actually modify that
[03:44:56] <jmkasunich> shudder
[03:45:08] <cradek> the only place it's used is to pass arc_data_comp_ijk
[03:45:29] <cradek> pass to
[03:46:39] <jmkasunich> hmm, so maybe I should do what you suggested in the first place, leave well enough alone until it gets all the way down to the arc_data functions?
[03:48:20] <cradek> there are lots of nice tests with arcs in them, in the test suite
[03:48:30] <jmkasunich> lol
[03:48:55] <jmkasunich> IOW, "stop talking and do something, then see if it works"
[03:50:09] <cradek> cam-nisley has 257 arcs in it, I bet most of them are comped
[03:50:30] <jmkasunich> none of them use absolute centers
[03:50:37] <cradek> true
[03:50:42] <cradek> first goal: don't break anything
[03:51:33] <cradek> you could change some to use absolute centers and it should not change the output
[03:51:58] <jmkasunich> testing is all well and good
[03:52:11] <jmkasunich> but I'm trying to decide what is the best way to write the code
[03:52:48] <jmkasunich> where "best" = least likely to break things, least likely to make a future maintainer say "wtf?", and oh yeah, most likely to work
[03:53:17] <jmkasunich> that middle criteria doesn't seem to have been all that important in the past
[03:53:21] <cradek> is this like "pick any two"?
[03:53:33] <cradek> yeah I was going to suggest picking #1 and #3 if so
[03:54:05] <jmkasunich> the idea of adding another coat of wtf on top of what is already there makes me cringe
[03:54:15] <jmkasunich> I'd rather be removing a layer if possible
[03:55:55] <cradek> we may have a style difference. I always make the minimum change possible. I still think you could change just those 4 lines and patch up the hypot()s and it would work correctly
[03:56:09] <jmkasunich> probably
[03:56:19] <jmkasunich> but at a bare minimum there are comments that need changes
[03:56:21] <jmkasunich> d
[03:56:32] <jmkasunich> double i_number, //!< first coordinate offset of center from current
[03:56:37] <jmkasunich> will be wrong
[03:56:37] <cradek> yes it would be nice to fix them
[03:56:46] <jmkasunich> "would be nice" ?
[03:57:06] <jmkasunich> you mean "a future maintianer will have the right to shoot me if I don't fix them:
[03:57:46] <cradek> (I rarely read and certainly never trust those comments)
[03:58:02] <jmkasunich> then how do you figure out the code?
[03:58:31] <cradek> dig, mostly
[03:58:32] <jmkasunich> if you don't know what a functions inputs and outputs are, you are totally blind
[03:59:37] <jmkasunich> crap, 11pm
[03:59:48] <cradek> EOW (end of weekend)
[03:59:52] <jmkasunich> yeah
[04:00:23] <jmkasunich> so far (aside from the parsing code already committed) the checks for missing IJK words, and the probalby useless find_center
[04:00:47] <jmkasunich> I'm tempted to remove find_center, and commit what I have, then start fresh tomorrow evening with the actual implementation
[04:01:11] <jmkasunich> missed some words there....
[04:01:22] <jmkasunich> meant to say "I have the checks"
[04:05:41] <CIA-38> EMC: 03jmkasunich 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc: checks for required IJK words in absolute center mode
[04:06:57] <jmkasunich> goodnight
[04:08:31] <cradek> goodnight
[13:50:37] <jepler> I've noticed on my 64-bit/sim system that I don't get thread or function times or tmaxes in halcmd show.
[13:50:43] <jepler> I should look into that..
[13:58:58] <alex_joni> I think I remember they show up on i386/sim
[15:14:09] <CIA-38> EMC: 03cradek 07TRUNK * 10emc2/docs/src/gcode/main.lyx: clarify G10 L2
[15:14:32] <jepler> Realtime Threads:
[15:14:32] <jepler> Period FP Name ( Time, Max-Time )
[15:14:32] <jepler> 1000000 YES thread1 ( 0, 0 )
[15:14:32] <jepler> 1 encoder.update-counters
[15:14:50] <jepler> but the thread is running; encoder.0.rawcounts changes
[15:18:18] <SWPadnos> is a hal_s32_t a long on 64-bit systems?
[15:57:52] <CIA-38> EMC: 03cradek 07TRUNK * 10emc2/docs/src/gcode/main.lyx:
[15:57:52] <CIA-38> EMC: Document additional UVW planes, make it explicit that G91 does not affect G10,
[15:57:52] <CIA-38> EMC: clean up plane-specific stuff in the canned cycles, be more explicit about how
[15:57:52] <CIA-38> EMC: repeats work, clean up G92 by describing the behavior instead of the
[15:57:52] <CIA-38> EMC: implementation.
[16:14:05] <CIA-38> EMC: 03cradek 07TRUNK * 10emc2/docs/src/gcode/main.lyx: argh, missed one
[20:16:18] <CIA-38> EMC: 03eric-johnson 07TRUNK * 10emc2/src/emc/usr_intf/emclcd.cc: Intermediate update, added command line handling and additional features
[20:52:02] <alex_joni> hi seb
[20:52:14] <seb_kuzminsky> hi alex
[20:52:17] <seb_kuzminsky> http://nappy.colorado.edu/buildbot/waterfall
[20:52:54] <alex_joni> wheee
[20:52:59] <seb_kuzminsky> hmmm...
[20:53:11] <seb_kuzminsky> i built that before i saw jmk's new compile farm work...
[20:54:33] <alex_joni> need to fix the runtests
[20:54:35] <alex_joni> Runtest: 25 tests run, 23 successful, 1 failed + 1 expected
[20:56:20] <seb_kuzminsky> alex_joni: you made the 8.04 livecd, right?
[20:56:30] <cradek> trunk tests ran correctly last night when I tried them
[20:57:01] <alex_joni> cradek: I suspect it's based on the VM which has bad latency
[20:57:04] <alex_joni> seb_kuzminsky: yeah, why>
[20:57:05] <alex_joni> ?
[20:57:22] <jepler> I should review what the threads test is trying to test
[20:57:29] <alex_joni> --- /home/farmer/BuildBot/slave/ubuntu-8.04-rtai-x86/hardy-x86-trunk-realtime-rip/build/tests/overrun: overrun detected in sampler, re-running test
[20:57:41] <jepler> the overrun test is supposed to fail
[20:57:52] <jepler> I should figure out a better way to test that the overrun detector works
[20:59:03] <alex_joni> seb_kuzminsky: anything on your mind regarding 8.04 livecd?
[21:00:28] <seb_kuzminsky> alex_joni: well, i was thinking it'd be cool to test on amd64
[21:00:43] <seb_kuzminsky> and that would be much easier if there was an amd64 livecd ;-)
[21:00:47] <alex_joni> jepler did the amd64 packages :)
[21:01:02] <jepler> * jepler hides
[21:01:19] <seb_kuzminsky> * seb_kuzminsky seeks
[21:01:20] <alex_joni> I wonder if my laptop would run x86_64
[21:01:59] <jepler> threads.0 may also turn out to be a test of realtime latency, and it may test a stronger condition than rtapi threads provide
[21:02:06] <alex_joni> would that run on a T5300 core 2 duo?
[21:02:40] <jepler> alex_joni: yes, according to intel that has EM64T
[21:04:27] <jepler> alex_joni: I run 64-bit ubuntu on my T7500 laptop
[21:04:48] <alex_joni> ah, cool.. maybe I'll try some day :)
[21:04:54] <alex_joni> but right now I feel drained
[21:08:05] <alex_joni> seb_kuzminsky: but using a default ubuntu 64 install cd + emc2 install script should be just as easy
[21:08:21] <seb_kuzminsky> alex_joni: ok, i'll try that
[21:08:36] <seb_kuzminsky> if the buildbot work survives community scruitiny ;-)
[21:09:09] <alex_joni> this is a very fogiving community
[21:09:13] <alex_joni> also quite small :D
[21:09:46] <jepler> alex_joni: if I tag a 2.2.7 will you have time to build it?:
[21:09:52] <jepler> today or tomorrow, american time
[21:10:03] <alex_joni> yup..
[21:10:05] <seb_kuzminsky> what's the url to the amd64 .debs? i mostly need the kernel & rtai stuff i guess
[21:10:06] <jepler> OK
[21:10:15] <seb_kuzminsky> whoa hold on there jeff
[21:10:15] <alex_joni> the only thing I was partly worried is the stg stuff
[21:10:26] <alex_joni> but it's ok if it will go into 2.2.8 ;)
[21:10:41] <alex_joni> seb_kuzminsky: the apt list is the same for amd64 and i386
[21:10:43] <seb_kuzminsky> let me push the latest hostmot2 stuff into 2.2, i'll try to do it today or tonight ok? when are you tagging?
[21:10:58] <alex_joni> http://linuxcnc.org/hardy/dists/hardy/base/
[21:11:08] <seb_kuzminsky> thanks :-)
[21:13:35] <alex_joni> seb_kuzminsky:
http://www.linuxcnc.org/hardy/emc2-install.sh that should work for both x86_64 and x86
[21:15:46] <CIA-38> EMC: 03cradek 07v2_2_branch * 10emc2/docs/src/gcode/main.lyx: backport clarification of G10 L2
[23:38:09] <CIA-38> EMC: 03seb 07TRUNK * 10emc2/debian/rules.in: if files are left out of the debian packages, show what they are
[23:38:29] <CIA-38> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/Stepper_Diagnostics.lyx: add some content on common problems
[23:42:53] <CIA-38> EMC: 03seb 07TRUNK * 10emc2/src/Makefile: install the firmware for the other Hostmot2 boards too
[23:44:28] <CIA-38> EMC: 03seb 07TRUNK * 10emc2/debian/ (5 files):
[23:44:28] <CIA-38> EMC: Make debian packages for the firmware for all the Mesa Hostmot2 boards.
[23:44:28] <CIA-38> EMC: (sorry Jeff)
[23:45:46] <jepler> seb_kuzminsky: just so you don't bugger up the 2.2 packages, you're welcome to explore whatever you think makes sense in 2.3.
[23:47:29] <seb_kuzminsky> you want to keep all hostmot2 firmwares in emc2.deb in 2.2?
[23:47:50] <SWPadnos> it's bad to rearrange packaging during a stable release cycle
[23:48:02] <SWPadnos> IMO
[23:48:06] <jmkasunich> hi seb
[23:48:21] <seb_kuzminsky> SWPadnos: i agree, but this is not really rearranging anything, it's adding new packages for the firmwares for newly supported hardware
[23:48:22] <seb_kuzminsky> hi jmkm
[23:48:44] <seb_kuzminsky> jepler: i'll be happy to do whatever you think is right in 2.2 of course, but i'm not exactly sure what you want
[23:49:14] <jepler> seb_kuzminsky: scenario: a user has a working hostmot2 setup in 2.2.6 (ha ha). he upgrades to 2.2.7, but the firmwares are gone because they're in a separate package.
[23:49:21] <seb_kuzminsky> jmkasunich: i didnt see your compile-farm updates until it was too late!
[23:49:30] <SWPadnos> seb_kuzminsky, changing what packages provide what and/or the dependencies is rearranging stff :)
[23:49:34] <SWPadnos> stuff
[23:49:41] <jmkasunich> it seems we're rarely in here at the same time
[23:49:51] <jepler> having the main package depend on the firmware package defeats the purpose
[23:50:03] <jepler> so that leaves the only choice for 2.2 as "don't split the packages"
[23:50:12] <jmkasunich> it was probably a week from when I started (and was griping in here about memory issues) till the first pass message went out
[23:50:27] <seb_kuzminsky> jepler: emc2.deb recommends emc2-firmware seems to me to do the right thing
[23:50:38] <seb_kuzminsky> "if you just upgrade, you get everything including the new stuff"
[23:50:50] <seb_kuzminsky> "if you know what you're doing, you can remove the firmware without horking anything"
[23:51:03] <jmkasunich> is that the plan for 2.3 as well?
[23:51:11] <jmkasunich> seems that it defeats the purpose of a separate fw package
[23:51:17] <seb_kuzminsky> jmkasunich: that's what i put in trunk yes
[23:51:21] <jmkasunich> cause 99.9% of people do whatever the default is
[23:51:55] <jmkasunich> so everybody downloads and installs the whole thing, then 0.1% of them remove the stuff they don't need
[23:52:06] <seb_kuzminsky> that sounds right to me
[23:52:09] <seb_kuzminsky> the alternative is:
[23:52:23] <seb_kuzminsky> people upgrade to 2.2.7 or 2.3 or wahtever, but dont have the firmware and it looks broken to them
[23:52:32] <seb_kuzminsky> the firmware packages are not *that* big
[23:52:40] <seb_kuzminsky> "here's a nickle kid, buy yourself a better modem"
[23:52:45] <seb_kuzminsky> ;-)
[23:52:46] <jmkasunich> 2.2.7 and 2.3.0 are two totally different issues
[23:52:59] <jmkasunich> 2.2.6 -> 2.2.7 must be simple and transparent
[23:53:08] <jmkasunich> 2.2.x to 2.3.0 _will_ require config changes
[23:53:32] <jmkasunich> if it also means reading some docs and realizing that you need to install the fw packages, so be it
[23:53:42] <jmkasunich> probalby 5% of the users will want mesa stuff
[23:54:00] <seb_kuzminsky> jepler: i'll make 2.2 put all the firmware in emc2.deb, no prob
[23:54:15] <BigJohnT> is it too early to add g90.1 and g91.1 to trunk?
[23:54:15] <jmkasunich> 5% will have other high-end cards (stg, pico, motenc), and the other 90% will be doing software stepping
[23:54:17] <jepler> seb_kuzminsky: speaking of that, how are we for releasing a 2.2.7?
[23:54:20] <jepler> seb_kuzminsky: in terms of hostmot2
[23:54:21] <seb_kuzminsky> jmkasunich: would you accept emc2.deb Suggests emc2-firmware.deb?
[23:54:39] <seb_kuzminsky> jepler: i'll check it in later tonight, will that work?
[23:55:08] <jmkasunich> seb_kuzminsky: I'm just stating an opinion, I don't know the meaning of recommends vs suggests
[23:55:22] <jmkasunich> although I gather that recommends means will install by default, can be removed
[23:55:28] <jmkasunich> and suggests means will not install by default
[23:55:29] <jepler> seb_kuzminsky: it's mostly for hm2 that I think we need the release (we do, right?) so yeah I'll certainly wait for your say-so
[23:55:40] <seb_kuzminsky> jepler: yes
[23:55:45] <seb_kuzminsky> jmkasunich: that's right
[23:55:46] <jepler> seb_kuzminsky: I've just realized that if I don't do it tonight or tomorrow night, the next week or so is not going to give me the time..
[23:55:58] <jmkasunich> BigJohnT: if you want to write words for G90.1/G91.1, go ahead - I hope to have it coded in the next couple of days
[23:56:04] <seb_kuzminsky> i'll merge hm2 from trunk into 2.2 tonight
[23:56:10] <seb_kuzminsky> gotta go, see y'all later
[23:56:11] <BigJohnT> ok thanks jmkasunich
[23:56:12] <jepler> seb_kuzminsky: see you
[23:56:16] <jepler> I should run too
[23:56:33] <jepler> no work and all play
[23:59:00] <CIA-38> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gcode/main.lyx: add G90.1 and G91.1 and a bunch of spellos
[23:59:17] <jmkasunich> that didn't take long
[23:59:54] <BigJohnT> it was all ready there from the other day
[23:59:57] <BigJohnT> :)