Back
[01:45:26] <cradek> hi jmk
[01:45:31] <jmkasunich> hi
[01:45:42] <cradek> I just fixed halcmd like we had been planning
[01:45:47] <cradek> can't check it in - cvs isn't working
[01:45:49] <jmkasunich> to use module helper?
[01:46:09] <cradek> yes
[01:46:15] <cradek> and removed all the setuid things from it
[01:46:52] <jmkasunich> I just did a cvs up with no probs
[01:47:22] <cradek> ah it's back
[01:48:08] <jmkasunich> something we need to think about: version numbers
[01:48:15] <jmkasunich> not what they are, but how to let users see them
[01:48:22] <jmkasunich> Help->About, etc
[01:48:32] <jmkasunich> or emc --version
[01:49:00] <cradek> dpkg -l emc2
[01:49:15] <jmkasunich> what if you didn't get a package
[01:49:31] <cradek> sorry, I was only half serious
[01:49:46] <cradek> probably help/about everywhere should have it, but that's kind of hard
[01:50:16] <jmkasunich> seems like we need a file in cvs called version.<something>
[01:50:24] <jmkasunich> version.h would get it into all C programs
[01:50:37] <jmkasunich> version.h:
[01:50:48] <jepler> ugh ugh ugh
[01:50:57] <jmkasunich> #define emc2_version "testing-2.0.1-fix3"
[01:51:09] <jepler> #define emc2_version "jepler forgot to update this"
[01:51:24] <jmkasunich> yeah, there is that
[01:51:34] <jepler> #define why_bother_having_dependencies_right_if_every_build_recompiles_this_file
[01:51:45] <jepler> er, s/recompiles/touches/
[01:52:10] <cradek> I don't think jmk is proposing it change every time anyone builds
[01:52:17] <jmkasunich> no, every released version
[01:52:21] <cradek> only when we have a "release" whatever that is
[01:52:31] <jmkasunich> everything we see fit to give a distinct version number to
[01:52:56] <jmkasunich> that addresses the second objection, not the first
[01:53:18] <jepler> It addresses the first, if you can assume that everyone who makes releases is less lazy than me
[01:53:22] <cradek> I think it really needs to be in help/about on the guis.
[01:53:37] <cradek> I have nfc how to do that right
[01:53:40] <jmkasunich> s/lazy/forgetfull
[01:53:47] <cradek> with some work, we could put it in the stat buffer
[01:53:59] <jepler> substitute it in emc.in, and set it in a standard environment variable that all GUIs can consult?
[01:54:11] <jmkasunich> assuming it is in some C program, the guis should be able to get it
[01:54:12] <cradek> yes, that could work too
[01:54:30] <cradek> env is definitely easier than C
[01:54:49] <jepler> it would be hard to access from the realtime code, but I don't imagine that matters much
[01:54:55] <jmkasunich> yes, C and GUI and bash can all use env
[01:55:23] <jmkasunich> RT code could only print it to dmesg anyway
[01:56:09] <jmkasunich> actually, it might be nice if RT modules printed a line to dmesg when loaded
[01:56:10] <jepler> jmkasunich: maybe rt code would output the version on the X axis stepper in morse code!
[01:56:18] <jmkasunich> lol
[01:56:42] <jmkasunich> we have several people who could actually understand that
[01:57:24] <jmkasunich> I'm thinking emc --version, and GUI Help-About would be the only places its really needed
[01:57:49] <cradek> that's going to be relatively easy
[01:58:10] <jmkasunich> and I'd be tempted to echo $version on startup of emc even if they don't give --version
[01:58:15] <jepler> If you provide an environment variable, I'll display it in AXIS's Help > About.
[01:58:35] <jmkasunich> so if somebody is having trouble, we can say "do a typescript" and not worry about them forgetting the version
[01:58:46] <jepler> jmkasunich: the emc script is so chatty anway, nobody'll notice without looking for the version number
[01:58:48] <cradek> for everything but the official release build/tag, though, it should report something other than that number
[01:59:26] <cradek> so when we tag a release in cvs, we have the version number set in the script. Immediately afterward, we change it to "something else" and check in a new version
[01:59:43] <cradek> so only if you check out -rTHE_RELEASE you get that number
[02:00:15] <cradek> because it's important to distinguish the release from "something a while after the release"
[02:00:35] <jmkasunich> yes
[02:00:40] <cradek> so I'm thinking now we can hardcode it in emc.in
[02:01:10] <cradek> if it's not hardcoded, maybe we can generate something useful from the cvs date??
[02:01:14] <jmkasunich> and emc.in (emc really) sets the env var for everybody else
[02:02:38] <cradek> # Makefile.inc. Generated from Makefile.inc.in by configure.
[02:02:38] <cradek> # on Mon Feb 13 19:44:32 CST 2006
[02:02:54] <cradek> we can get the configure date
[02:03:04] <jepler> cradek: but that will be different for everyone...
[02:03:05] <jmkasunich> that tells when it was compiled, but nothing about what code it is
[02:03:08] <cradek> well, that doesn't represent when cvs was upped
[02:03:12] <cradek> that's what we really want
[02:03:20] <jmkasunich> you could do cvs co -Dlastmonth
[02:03:24] <cradek> but I think we don't have that
[02:03:25] <jmkasunich> and we want "last month"
[02:03:43] <cradek> jmkasunich: preferably it would say January instead...
[02:04:07] <jmkasunich> I oversimplified
[02:04:24] <jmkasunich> we want the date that <lastmonth> resolved to
[02:04:41] <cradek> a while back I had to debug an email problem for someone at work, and they had a fax of a printout of the message from some terrible mailreader that said "Date: Yesterday 12:34 PM"
[02:04:58] <cradek> no date, no timezone
[02:05:05] <cradek> sorry, tangent
[02:06:20] <jepler> CVS just doesn't have a global "version number" which identifies a tree, unlike other newer versioning systems
[02:06:28] <cradek> I wonder what file gets touched every time you cvs up
[02:06:41] <cradek> well, written?
[02:06:47] <jmkasunich> CVS/*
[02:06:47] <cradek> configure could stat something
[02:06:49] <jepler> I looked at the files in CVS/ and if none of the files in that directory were changed by update, they aren't changed
[02:06:58] <cradek> drat
[02:07:09] <cradek> maybe we don't have the information we want.
[02:07:16] <jmkasunich> the tag used for the checkout is in there tho
[02:07:32] <cradek> jmkasunich: but the interesting case for us is when it's HEAD
[02:07:39] <jmkasunich> /README/1.8/Sun Jan 22 19:34:37 2006//TTESTING
[02:07:44] <cradek> jmkasunich: the case where it's a release is already solved
[02:07:54] <jmkasunich> how is it solved?
[02:08:10] <cradek> we hardcode the release number in emc.in and check in that special version corresponding to the release tag
[02:08:19] <jepler> find . -name Entries | grep CVS/Entries | xargs cat | awk -F/ '{print $4}'
[02:08:26] <jepler> now how do I find the latest of all these dates?
[02:08:40] <cradek> uhh
[02:08:57] <cradek> you rewrite cvs to use epoch times, and sort them
[02:08:58] <jmkasunich> I am not at all worried about the date of a HEAD checkout
[02:09:21] <cradek> I think it would be useful to have help/about report the approximate age of the build
[02:09:26] <jmkasunich> if someone shows up on IRC and says "I have a strange bug on my HEAD checkout", I will have one of two responses:
[02:09:45] <jmkasunich> if HEAD is stable right then, "checkout a fresh one and try that"
[02:10:00] <jmkasunich> if HEAD is not stable: "checkout TESTING and try that"
[02:10:31] <cradek> so help/about will report what for the non-release case?
[02:10:51] <cradek> it could say HEAD, I suppose
[02:10:53] <jmkasunich> I don't really care - date built? "non-released version"
[02:11:01] <jmkasunich> "head - built <date>"
[02:11:49] <jmkasunich> doesn't really matter
[02:12:13] <cradek> I agree it's not very important, but I would like the cvs up date there if possible.
[02:12:18] <jmkasunich> but if they are reporting a problem or asking for help with Testing or Released, we need to know what they are running
[02:12:19] <cradek> looks like it's not possible (easy)
[02:14:19] <jmkasunich> CVS version tags aren't really helpfull since they only address one file
[02:14:33] <cradek> that's why jepler was looking for the newest file
[02:14:54] <cradek> with that info, you could match the user's version exactly with up -D
[02:15:21] <jmkasunich> newest file as in "ls -l" date?
[02:15:31] <cradek> no, newest Entries date
[02:15:49] <jmkasunich> in the entire tree - not fun
[02:15:58] <cradek> yeah.
[02:16:02] <jmkasunich> but it would be effective
[02:16:10] <cradek> configure does worse
[02:16:38] <jmkasunich> it would be reasonable to have configure do the dirty work, wouldn't it?
[02:16:43] <cradek> yes
[02:16:56] <jmkasunich> of course, if they build from a source tarball, no CVS/Entries
[02:17:22] <jmkasunich> hmm, heres an off the wall idea
[02:17:24] <cradek> I don't care about non-release source tarballs
[02:17:29] <cradek> I think they're somewhat a bogus idea
[02:17:40] <jmkasunich> there are scripts at SF that are invoked on commit
[02:18:06] <jmkasunich> could one of them do "date -u >somefile" on every commit
[02:18:35] <jepler> you mean, another commit?
[02:18:38] <jmkasunich> the hard part is making "somefile" be something that you get when you do a checkout
[02:18:51] <jmkasunich> no, another commit would be bad
[02:18:57] <cradek> why?
[02:19:05] <jmkasunich> infinite loop, for one
[02:19:11] <cradek> SMOP
[02:19:13] <jmkasunich> ;-)
[02:19:13] <jepler> how do you put something in a file without making a commit?
[02:19:22] <cradek> you don't
[02:19:25] <jmkasunich> I have no idea, I'm just brainstorming
[02:19:40] <cradek> we know, and it's a reasonable idea
[02:19:49] <cradek> but it would involve a commit.
[02:20:08] <jmkasunich> what about the cvs history logs
[02:20:26] <cradek> cvs log is also for only one file
[02:20:28] <cradek> same problem
[02:21:31] <jmkasunich> not true (about it being only one file)
[02:21:39] <jmkasunich> cd to a checkout, do cvs history
[02:22:19] <cradek> huh, I'm not familiar with cvs history
[02:22:49] <cradek> what is this info? some of it is checkins I made in 2004
[02:22:58] <jmkasunich> history ;-)
[02:23:04] <cradek> I can't parse it
[02:23:11] <jmkasunich> neither can I
[02:23:20] <jmkasunich> there are a bunch of options that modify the output
[02:27:56] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/last.py
[02:28:31] <jepler> sample outputs include:
[02:28:31] <jepler> Tue Feb 14 02:27:00 2006 D2006.01.01.06.00.00
[02:28:50] <cradek> I'll buy that
[02:29:00] <jepler> Tue Feb 14 02:26:01 2006 TTESTING
[02:29:03] <jepler> etc
[02:29:13] <jepler> hm, that first date isn't a check-in date
[02:29:19] <jepler> I think it's a checkout date
[02:29:35] <cradek> hmm
[02:29:52] <jepler> but you know what -rTESTING was on that date, you can get it with -rTESTING -D...
[02:30:25] <jepler> cradek: how do I check out simple_tp?
[02:30:37] <cradek> cd src/emc/kinematics; cvs up -rsimple_tp
[02:30:58] <jepler> cvs update: Submakefile is no longer in the repository
[02:30:59] <jepler> oops!
[02:31:02] <jepler> I wonder if it'll even build
[02:31:03] <cradek> bonk
[02:31:14] <cradek> I patched it up pretty recently
[02:31:20] <cradek> but I think it has an arc bug
[02:31:31] <jepler> Tue Feb 14 02:30:34 2006 TTESTING Tsimple_tp
[02:31:34] <cradek> I have bomb.ngc somewhere if you're interested
[02:32:00] <cradek> oh you're not going to work on tp, are you
[02:32:03] <cradek> sigh
[02:32:15] <jepler> no, that was just to test my script on some pathological case
[02:33:27] <jmkasunich> well I screwed around with CVS history and couldn't make heads or tails of it
[02:33:46] <jepler> running "cvs history" at compile time is probably a bad idea, because it requires sf.net to be available
[02:33:59] <jmkasunich> I know,
[02:34:35] <jmkasunich> I didn't want to even think about "how do we get the history data" until I answered the easier question, is the history data usefull
[02:35:31] <cradek> for the sake of simplicity let's say we'll change it to represent "this is cvs from sometime after release x.y.z"
[02:35:53] <jepler> then for now let's do something that will work for released versions only, and wait 'till inspiration strikes
[02:35:54] <cradek> maybe this information isn't worth the complexity required
[02:36:02] <cradek> yes
[02:36:04] <jepler> to do something about identifying an exact CVS version
[02:36:48] <jmkasunich> I think the real information we want is "what released or testing version is this, or is it 'none of the above' "
[02:37:09] <jepler> both of which can be done by manually editing a file
[02:37:18] <jmkasunich> the only trick is remembering to do it
[02:37:31] <cradek> we almost need a "release engineer" like the books talk about
[02:37:42] <cradek> someone who's anal enough to keep a list of what things to do in what order
[02:37:49] <jepler> do we have anyone like that?
[02:37:55] <cradek> no
[02:37:58] <jepler> an untapped, uh, resource?
[02:38:34] <cradek> if I'm building packages, there's little point in it being someone other than me
[02:38:59] <jmkasunich> if we didn't have to worry about CVS checkouts (if everybody either downloaded a release tarball or a deb) we could almost do something like "./configure --with-version-tag emc2-testing-2006-02014"
[02:39:28] <jmkasunich> and let configure stick it into emc.in using @version-tag@
[02:39:42] <jmkasunich> if the tag is not specified, it would insert the compile date instead
[02:40:36] <jmkasunich> we have "make deb" now right?
[02:41:05] <jmkasunich> do we have/do we want "make release-source-tarball" (or something like that?)
[02:41:43] <cradek> if it's just a matter of debs, we're back to dpkg -l being sufficient
[02:42:07] <jmkasunich> when would that be invoked to get the info into Help/About?
[02:42:09] <cradek> so I think the solution for release version numbers has to be in cvs
[02:42:21] <cradek> oh, it wouldn't, I forgot about that goal
[02:43:07] <jmkasunich> I'm not crazy about hardcoding it in emc.in
[02:43:07] <cradek> let's just edit emc.in
[02:43:15] <cradek> ha
[02:43:16] <jmkasunich> the commit logs for emc.in would get messy after a while
[02:43:36] <cradek> true, most things in the log would be useless
[02:43:51] <jmkasunich> if there was a file that held only the version
[02:44:06] <jmkasunich> emc.in could source it (treat it like a script)
[02:44:27] <jmkasunich> or configure could read it, and do substitution into emc.in -> emc
[02:44:33] <cradek> was just thinking that
[02:44:40] <cradek> that solves the messy cvs log problem.
[02:44:49] <cradek> but keeps most of the simplicity
[02:45:06] <jmkasunich> yeah, now the log for that file is still "messy", but in a good way, it becomes a history of releases
[02:45:36] <cradek> history is fine, wading through irrelevant history for the change you want is what's bad
[02:45:36] <jmkasunich> having emc source it is easy, but emc needs to be able to find it
[02:45:45] <cradek> no, configure will insert it
[02:45:57] <cradek> we do not want another file that's hard to find
[02:45:59] <jmkasunich> having ./configure read it and stuff into emc means it only needs read a compile time
[02:46:10] <jmkasunich> and it never gets installed anywhere
[02:46:15] <cradek> right
[02:46:43] <jmkasunich> configure is just bash right?
[02:46:48] <cradek> kind of
[02:46:51] <jmkasunich> as opposed to configure.in
[02:47:01] <cradek> configure is a generated file from configure.in/autoconf
[02:47:21] <jmkasunich> so if "version" was a one liner: EMC2VERSION=<somestring>
[02:47:27] <jmkasunich> configure could source it
[02:48:16] <cradek> EMC2VERSION=$(cat version)
[02:48:21] <cradek> AC_SUBST([EMC2VERSION])
[02:48:28] <cradek> I think it's this simple
[02:48:29] <jmkasunich> yeah
[02:48:50] <jmkasunich> so the file contains nothing except the actual version string
[02:49:02] <cradek> right
[02:49:14] <jmkasunich> and configure could also stick that string into config.h, so C progs could have it
[02:49:25] <cradek> yes, it could
[02:49:30] <jmkasunich> (like halscope - it is C, uses GTK, but may someday have a Help->About
[02:49:33] <cradek> I'll go do this
[02:49:47] <jmkasunich> slow down just a tiny bit
[02:50:11] <jmkasunich> are we gonna set version to "after-release-foo" between releases?
[02:50:36] <jmkasunich> leave it blank and let configure substitute something else, like the compile date?
[02:50:49] <cradek> that's a policy decision, I'm working on technical now :-)
[02:50:52] <jmkasunich> ok
[02:51:12] <jmkasunich> just thinking about what to do if "cat version" returns nothing
[02:51:30] <jmkasunich> there should probably be an if and a reasonable default in configure
[02:53:43] <jmkasunich> EMC2VERSION=$(cat version) ; if [ -z $EMCVERSION ] then EMCVERSION=??? fi ; ACSUBST ([EMC2VERSION])
[02:54:58] <jmkasunich> * jmkasunich thinks of ways to bust things
[02:55:14] <jmkasunich> monday: cvs co ; configure ; make
[02:55:24] <jmkasunich> 3 months later
[02:55:29] <jmkasunich> cvs up ; make
[02:55:34] <jmkasunich> (no configure)
[02:55:37] <jmkasunich> busted!
[02:55:56] <jmkasunich> or does that come under the heading "if it hurts don't do it"
[02:56:17] <cradek> a 3 month rebuild without configure will probably bomb anyway
[02:56:29] <jmkasunich> ok, 3 week
[02:57:00] <jmkasunich> just being devil's advocate, I actually kinda like this scheme
[02:57:11] <jmkasunich> the work I do in my day job makes me paranoid
[02:57:59] <jmkasunich> if we miss some way for the customer to screw up, and they find it, we don't get a bug report, we get a smoking ruin
[02:58:39] <jmkasunich> needless to say, our primary protection schemes do NOT rely on software/firmware ;-)
[03:03:40] <cradek> yuck, I can't get substitution in config.h
[03:03:44] <cradek> I don't know what I'm doing
[03:04:00] <jmkasunich> lemme take a look
[03:04:06] <cradek> let me commit this
[03:05:49] <jmkasunich> autoheader?!?
[03:05:52] <jmkasunich> ick
[03:05:58] <cradek> nfc
[03:06:05] <cradek> it doesn't subst like the other files
[03:06:14] <cradek> I don't understand what makes config.h
[03:06:24] <cradek> maybe we should wait for alex to do the c part - the sh part is easy/done
[03:06:30] <jmkasunich> some of the GNU auto-foo is just too clever for its own good
[03:07:59] <jmkasunich> doesn't look like it even does substitution...
[03:08:08] <cradek> I'm off to go find some dinner... be back soon.
[03:08:18] <jmkasunich> I'll be off to bed soon
[03:08:23] <cradek> goodnight then
[03:08:27] <jmkasunich> goodnight
[03:08:46] <jmkasunich> you still there?
[03:09:18] <jmkasunich> guess not...
[03:09:34] <cradek> yes
[03:09:52] <jmkasunich> did you see PACKAGE_VERSION and friends in config.h.in?
[03:10:07] <cradek> no
[03:10:08] <jmkasunich> I wonder if we're reinventing a wheel
[03:10:51] <cradek> could be ... I bet there's a way to get a var substitued in there
[03:11:06] <cradek> "someone" will have to wade through the autoconf info pages I guess
[03:11:15] <jmkasunich> not tonight
[03:11:20] <cradek> yeah
[03:11:32] <cradek> the important part is done - give the info to the guis
[03:11:43] <jmkasunich> yeah
[03:11:55] <cradek> alex will probably fix the rest easily
[03:21:12] <jepler> cradek: Is it OK to 'export' EMC2VERSION from scripts/emc?
[03:21:29] <jmkasunich> I don't see why not
[03:23:35] <jepler> "AXIS version 1.2a2 / emc2 Prerelease CVS HEAD"
[03:23:53] <jepler> -- AXIS's Help > About
[03:34:00] <jmkasunich> john@ke-main-ubuntu:~/emcdev/emc2head$ scripts/emc
[03:34:00] <jmkasunich> EMC2 - Prerelease CVS HEAD
[03:34:00] <jmkasunich> Machine configuration directory is '/home/john/emcdev/emc2head/configs/stepper/'Machine configuration file is 'stepper_inch.ini'
[03:34:00] <jmkasunich> Starting emc...
[03:34:18] <jmkasunich> -- EMC's version display (non GUI)
[03:34:37] <cradek> cool
[03:34:57] <cradek> btw change that string if you want, I don't know what it should say right now
[03:35:24] <jmkasunich> that is fine for now
[03:35:50] <jmkasunich> gonna go spelunking thru tkemc, see if I can make that one work
[03:42:47] <jmkasunich> how does one get an env var in tcl.... equivalent of C getenv()?
[03:42:55] <cradek> $env(VAR)
[03:43:01] <jmkasunich> ok
[03:43:52] <jmkasunich> I knew it had to be easier than [ lindex [ lsearch env ]] cruft
[03:43:55] <jmkasunich> thanks
[03:44:04] <cradek> eww
[03:45:55] <jepler> eek
[03:46:12] <jmkasunich> didn;t realize that env was an array
[03:46:19] <jmkasunich> nor did I know tcl's array syntax
[03:46:32] <jmkasunich> damn language has its () and [] backwards anyway
[03:47:48] <jmkasunich> drat, if I edit Ray's About message I'll break the translations
[03:48:54] <cradek> add another string afterward?
[03:49:32] <jmkasunich> thats what I'm gonna do
[03:49:39] <cradek> [concat [msgcat::mc "old string"] $env(VERSION)]
[03:49:49] <cradek> or whatever the syntax is
[03:50:41] <jmkasunich> is this lame: [ format "%s\n(EMC2 %s)" [msgcat(old)] $env(VERSION) ]
[03:51:15] <cradek> depends how important not breaking translation is
[03:51:28] <cradek> I suspect we don't have active translators to fix it
[03:51:39] <cradek> so I think that overrules any small bit of lameness
[03:53:17] <jmkasunich> eww, its worse than I thought
[03:53:59] <jmkasunich> never mind, I was confuseder than I thought
[04:00:49] <jmkasunich> strange, EMC2VERSION isn't in the env when tkemc is running
[04:01:03] <cradek> do you have jepler's change (the export)?
[04:01:10] <jmkasunich> think so
[04:01:16] <cradek> I bet you don't
[04:01:23] <cradek> maybe you didn't run configure
[04:01:45] <jmkasunich> redoing it now
[04:01:59] <cradek> oh wait, I wonder if we have to wank around at the top of the file to export it again when starting wish
[04:02:33] <cradek> yeah I bet
[04:02:44] <jmkasunich> gonna find out, I'll echo it at the top, and puts the env right after the wish restart
[04:02:48] <cradek> piece of crap
[04:08:22] <jmkasunich> well that's annoying
[04:08:26] <jmkasunich> $env isn't global
[04:08:36] <cradek> what?
[04:08:54] <jmkasunich> I added "global env" to the proc that needed it, and now it works
[04:09:01] <jmkasunich> (I needed the export too)
[04:09:27] <cradek> yuck
[04:09:32] <jmkasunich> export made a puts $env(EMC2VERSION) at toplevel work, but the same line inside a proc failed
[04:09:47] <cradek> set TCLBIN $env(EMC2_TCL_DIR)
[04:09:48] <cradek> set TCLSCRIPTS $env(EMC2_TCL_DIR)
[04:09:50] <cradek> set TCLDIR $env(EMC2_TCL_DIR)
[04:10:01] <jmkasunich> inside a proc?
[04:10:02] <cradek> here's some great kruft
[04:10:13] <cradek> no in an 'if' at the toplevel
[04:10:27] <cradek> I'm just laughing about all the different ways to refer to that env
[04:10:39] <jmkasunich> oh!
[04:10:52] <jmkasunich> I didn't even realise at first that they were all the same
[04:11:04] <jmkasunich> the entire tcl tree seems fscked that way
[04:11:18] <jmkasunich> why is tkemc in tcl, but setupconfig in tcl/bin?
[04:11:34] <jmkasunich> and other things in tcl/scripts
[04:11:35] <cradek> because kruftons orbit it
[04:11:40] <jmkasunich> lol
[04:11:48] <cradek> (real answer is it's hard to move stuff in cvs)
[04:12:12] <jmkasunich> oops, laughed loud enough to wake up the cat that is sleeping on my bench
[04:12:18] <cradek> haha
[04:12:57] <jmkasunich> <cat> looks around groggily, gives me a "you disturbed my slumber, lowly human" look, and goes back to sleep </cat>
[04:13:08] <cradek> I think I'm off to bed
[04:13:13] <cradek> goodnight again
[04:13:17] <jmkasunich> yeah, the cat has the right idea
[04:13:33] <jmkasunich> this works, strip out the test/debug puts and commit, and I'm off
[17:49:30] <alex_joni> hello
[17:49:39] <alex_joni> anyone around?
[17:55:49] <alex_joni> guess not ;)
[17:55:56] <alex_joni> * alex_joni will be around a bit later
[18:32:20] <rayh> Post of the day for me ---
[18:32:31] <rayh> My name is Vasantha and I am from Sri lanka. I have got a Slant bed lathe with a 6 way tool Turret, running on EMC, with two Copley Servo Drives and two Sanyo Denki DC servo Motors of 1Hp each.
[18:32:32] <rayh>
[18:44:42] <rayh> Questions on how to implement the tool changer turret.
[18:44:50] <rayh> catch you all later.
[22:00:58] <alex_joni> hello
[22:04:02] <alex_joni> guess no one wants to talk to me :(
[22:06:33] <alex_joni> cradek: so you're just hiding :D
[22:06:41] <cradek> nope
[22:06:51] <alex_joni> kidding
[22:06:51] <cradek> I said hi on the other channel
[22:06:54] <alex_joni> how's stuff
[22:07:01] <cradek> fine, just getting ready to go home
[22:07:04] <alex_joni> I've seen you started versioning
[22:07:08] <alex_joni> & jepler
[22:07:23] <cradek> yeah we wanted to get version numbers into help/about on the guis
[22:07:28] <alex_joni> I have a better way to get it out of configure into config.h
[22:07:40] <alex_joni> so we can compile it in
[22:07:41] <cradek> ok, I couldn't figure out the C part
[22:07:53] <cradek> I figured you would know how to do it, so I didn't worry
[22:07:54] <alex_joni> I can do that when I come back, ok?
[22:07:56] <cradek> sure
[22:08:04] <cradek> no hurry, the gui is the important place anyway
[22:08:16] <alex_joni> but there is still the problem people need to reconfigure to get the new version
[22:08:23] <alex_joni> even if it's only configure --version
[22:08:40] <cradek> I think that doesn't matter
[22:08:58] <alex_joni> ok, then it's fine
[22:10:01] <cradek> http://www.boomka.org/
[22:10:03] <cradek> hahaha
[22:10:37] <cradek> sorry, way off topic, but interesting
[22:11:28] <alex_joni> I like " It can show the Islamic world that humor and self deprecation is a healthy psychological exercise. The one who can face his demons can overcome his weaknesses""