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