#emc-devel | Logs for 2007-01-17

[01:36:52] <jmkasunich> hi guys
[01:36:58] <SWPadnos> hi jmk
[01:37:14] <jmkasunich> cradek: no, I'm not still on vacation (I wish...)
[01:37:41] <jmkasunich> I saw alex's commit and saw a simple mistake a few lines down, so I fixed it
[01:38:02] <jmkasunich> (I have a new work computer, and somehow, it got vmware and dapper installed on it... funny how that happens)
[01:38:26] <SWPadnos> that's cool
[01:38:34] <SWPadnos> is that the laptop or a new desktop?
[01:38:37] <jmkasunich> lappy
[01:38:43] <SWPadnos> oooh. even better
[01:38:52] <jmkasunich> dell 820, 2G ram, 1920 x 1200 screen
[01:38:59] <jmkasunich> I need reading glasses
[01:39:04] <SWPadnos> 17" ?
[01:39:19] <jmkasunich> I don't think so
[01:39:28] <jmkasunich> damn fine print
[01:39:37] <SWPadnos> it's funny - there are 17" 1920x1200, but when you go to 19", the res is lower - like 1680x1050 or some such
[01:43:32] <jmkasunich> jepler: you around?
[01:43:43] <jmkasunich> I have some questions about how sim works
[01:43:48] <jepler> jmkasunich: yes
[01:44:14] <jmkasunich> I tried to run sim this afternoon
[01:44:31] <jepler> didn't work?
[01:44:33] <jmkasunich> loadrt motmod failed (for irrelevant reasons), but the error message that came up was from loadusr
[01:45:07] <jmkasunich> are you implementing "loadrt foo" as "loadusr rtapi_app foo" ?
[01:45:13] <jepler> yes, something like that
[01:45:15] <jmkasunich> * jmkasunich is clueless about how sim works
[01:46:18] <jmkasunich> I noticed that loadusr manages to swallow any messages from the module you are attempting to load, so if it fails you have no clue why
[01:46:37] <jmkasunich> (I believe that applies to sim and regular alike)
[01:47:16] <jmkasunich> oh, a little is coming back to me
[01:47:40] <jepler> I'm not sure why I go off to 'loadusr' when invoking rtapi_app
[01:47:44] <jmkasunich> the first time you run rtapi_app, it loads itself, then the shared lib, and uses dlopen to load the module
[01:47:45] <jepler> I can't remember what the motivation was
[01:48:02] <jepler> yep
[01:48:06] <jmkasunich> the next time, it just passes the desired module off to the already running rtapi_app
[01:48:11] <jepler> yep
[01:48:21] <jmkasunich> it seems like you are using loadusr -W
[01:48:38] <jmkasunich> because it complains about rtapi_app exiting without becoming ready
[01:49:00] <jepler> (it's rtapi_app that determines if one is already running, and if so it contacts the existing one, not something inside halcmd)
[01:49:07] <jmkasunich> ok
[01:49:21] <jepler> ah yeah -- I bet that's it
[01:49:41] <jepler> if it's the "master" rtapi_app it doesn't exit, unlike loadrt
[01:49:53] <jepler> if it's the "slave" rtapi_app, it used to exit before the component was guaranteed ready (I think this is now fixed)
[01:50:10] <jepler> so it was to reuse the "wait for ready" code that I hand the arguments off to loadusr
[01:50:14] <jmkasunich> hmm, that makes using loadusr non-trivial
[01:51:16] <jmkasunich> the first time, rtapi_app becomes ready and doesn't exit (-W is fine there) (does it use rtapi_app as the comp name, or the name of the module its loading?)
[01:51:27] <jmkasunich> the next time, does it become ready and then exit?
[01:51:30] <jepler> there's not an rtapi_app in the comp list
[01:51:36] <jmkasunich> if so, -wW would actually work correctly
[01:51:46] <jmkasunich> I guess I should be looking at the code ;-)
[01:52:40] <jmkasunich> otoh, if the second and subsequent instances of rtapi_app exit without becoming ready, then -W is gonna report an error
[01:53:02] <jepler> I believe that rtapi_app either doesn't exit (first one) or exits after the new comp is loaded and ready (subsequent ones)
[01:53:17] <jepler> $ halcmd -kf
[01:53:17] <jepler> halcmd: loadrt blocks limit3=3
[01:53:17] <jepler> BLOCKS: installed 3 third order limiters
[01:53:37] <jepler> with sim, I get output from loaded modules on the terminal
[01:53:58] <jmkasunich> I need to get my facts straight
[01:54:03] <jmkasunich> when I used halcmd, I did too
[01:54:13] <jepler> halcmd: loadusr -w echo testing
[01:54:13] <jepler> testing
[01:54:29] <jepler> maybe it's scripts/emc that is hiding messages?
[01:54:31] <jmkasunich> but when I ran emc, there was no info about why motmod didn't load, in any of the log files or the screen
[01:54:35] <jepler> it does funky redirection stuff
[01:54:43] <jmkasunich> could be
[01:54:54] <jmkasunich> s/could be/probably is/
[01:55:10] <jmkasunich> I should really run things like a user more often
[01:55:15] <jepler> Starting EMC2...
[01:55:15] <jepler> Unknown parameter `bae_period_nsec=1000000'
[01:55:15] <jepler> HAL:7: ERROR: program '/home/jepler/emc2/bin/rtapi_app' failed, returned 255
[01:55:24] <jmkasunich> (I was running a non-RT ubunto on a VM, so I did things the user way)
[01:55:28] <jepler> I introduced a typo into core_sim.hal and got this on my terminal ^^
[01:55:43] <jmkasunich> yeah, thats not to differnet from what I got
[01:55:59] <jmkasunich> I think I ran a config that didn't load kins before motmod, or something
[01:56:05] <jmkasunich> probably "or something"
[01:56:10] <jmkasunich> lemme see if I can replicate here
[01:56:15] <jepler> I thought you said you didn't get a message on the terminal
[01:56:23] <jmkasunich> I didn't get a usefull one
[01:56:58] <jmkasunich> oh, I missed one line of your paste
[01:57:11] <jmkasunich> I don't think I got anything except "rtapi_app failed"
[01:58:36] <jmkasunich> building the sim here
[02:01:16] <jepler> and when I run sim from the menu, I get the Unknown parameter message down in "Debug file information" near the bottom
[02:04:17] <jmkasunich> ok, I'm obviously full of crap, because it seems to work just fine now
[02:04:28] <jepler> oh good!
[02:04:47] <jmkasunich> running sim/axis
[02:04:54] <jepler> umm, were you running 2.1 one place and TRUNK in the other? something like that?
[02:05:05] <jepler> if I botched the "re-route message" backport it might work in one but not the other..
[02:05:24] <jmkasunich> this afternoon I was running TRUNK (95% sure anyway)
[02:05:52] <jmkasunich> right now, I thought I was running trunk, but it said EMC2 - pre-2.1 CVS HEAD
[02:05:59] <jmkasunich> I thought trunk was at pre-2.2
[02:06:16] <jepler> $ ./scripts/emc configs/sim/axis.ini
[02:06:16] <jepler> EMC2 - pre-2.2 CVS HEAD
[02:06:45] <jmkasunich> yeah, the sim checkout on this machine must be a tag
[02:07:18] <jmkasunich> (I didn't want to rebuild as sim in my main checkout, I recall strange things happening when I switched back and forth between sim and rt before
[02:07:20] <jepler> I get the 'Unknown parameter' message on 2.1 and TRUNK/HEAD
[02:07:54] <jmkasunich> I'm gonna get the machine that had the problem and see what happens
[02:10:32] <jepler> I'll check back later
[02:14:41] <jmkasunich> I'm not sure this computer knows what to do... I just connected it to a non-corporate network for the very first time
[02:14:59] <jmkasunich> free at last!
[02:15:05] <jmkasunich> (the filtering has gotten really bad at work)
[02:16:58] <SWPadnos> I can swear at you if you like, to exercise your newfound freedom
[02:22:44] <jmkasunich> they block personal websites, anything remotely political, anything remotely streaming, etc, etc
[02:22:57] <jmkasunich> and they block IRC ports
[02:23:05] <jmk-wvm> but here I am
[02:23:13] <SWPadnos> ah - of course :)
[02:23:45] <jmk-wvm> and the probem I had this afternoon is still here
[02:24:22] <SWPadnos> whazzat?
[02:24:40] <jmk-wvm> pastebin coming up
[02:25:23] <jmk-wvm> http://www.pastebin.ca/319167
[02:25:49] <jmk-wvm> this is an off the shelf ubuntu 6.06LTS install, cvs head, compiled for sim
[02:25:55] <jmk-wvm> running the sim/axis config
[02:26:19] <jmk-wvm> man, I gotta install vmware tools
[02:26:32] <jmk-wvm> 1920x1200 screen, but the vm is running 1024x768
[02:26:37] <SWPadnos> s p e e d t o o l o w ?
[02:26:50] <jmk-wvm> no, just lack of real estate
[02:26:53] <SWPadnos> unfortunately, there aren't any widescreen modes
[02:27:15] <SWPadnos> I usually end up at 1400x1050 or so, which lets me see the window border
[02:27:24] <jmk-wvm> 1600x1200 would still be a huge improvement
[02:27:51] <SWPadnos> I'm not sure that will work without switching to full screen mode
[02:27:52] <jmk-wvm> I'll probably switch to fullscreen mode and try to forget that I'm running on an XP host
[02:27:56] <SWPadnos> heh
[02:28:14] <jmkasunich> that keyboard sux anyway
[02:28:24] <jmkasunich> looking at the pastebin
[02:29:00] <jmkasunich> I did get lots of output from motmod
[02:29:14] <jmkasunich> but none that helps figure out why it didn't work
[02:29:22] <jepler> I wonder if you're crashing rtapi_app or something
[02:29:41] <SWPadnos> well, it's after the motmod load ...
[02:30:08] <jepler> ulimit -c unlimited, run again, and look for a core file (in the config directory, natch)
[02:30:19] <jmk-wvm> the entire contents of emc_debug.txt:
[02:30:21] <jmk-wvm> Stopping realtime threads
[02:30:20] <jmk-wvm> Unloading hal components
[02:30:20] <jmk-wvm> 7472
[02:30:20] <jmk-wvm> PID TTY STAT TIME COMMAND
[02:31:50] <jmk-wvm> no core file
[02:32:00] <jmk-wvm> (would be called core, right?)
[02:32:13] <jepler> I think it would be core or core.<digits>
[02:32:30] <jepler> any easy way to get me a copy of this config?
[02:32:33] <jmk-wvm> closest to that is core_sim.hal ;-)
[02:32:56] <jmk-wvm> cvs up ;-)
[02:33:15] <jmk-wvm> configs/sim/axis.ini
[02:33:27] <jepler> does tkemc.ini do the same thing?
[02:33:27] <jmk-wvm> completely stock and unmodified
[02:33:51] <jmk-wvm> yes
[02:33:56] <jmk-wvm> tkemc same
[02:33:55] <SWPLinux> same here
[02:34:05] <jmk-wvm> same as in same problem?
[02:34:06] <SWPLinux> for both
[02:34:14] <SWPLinux> yes, same effect, on both configs
[02:34:20] <jmk-wvm> its gotta be related to the new test for -W
[02:34:25] <jepler> HAL:7: ERROR: /home/jmkasunich/emcdev/emc2head/bin/rtapi_app exited without becoming ready
[02:34:30] <jmk-wvm> right
[02:34:36] <jmk-wvm> that wasn't in there before
[02:35:15] <jmk-wvm> before, loadusr -W true would be accepted
[02:35:17] <jmk-wvm> now its an error
[02:35:26] <SWPLinux> hmmm - hold on. there's an error further up, talking about the tool table size being wrong ...
[02:35:32] <jmk-wvm> because it doesn't become a ready hal component
[02:35:53] <jmk-wvm> SWPLinux: bet that the x64 thing
[02:35:54] <jepler> SWPLinux: I changed the .nml file a bit ago, but you have old NML shared memory buffers that stuck around for some reason
[02:36:03] <SWPLinux> in sim?
[02:36:20] <jmk-wvm> NML doesn't know RT from SIM
[02:36:50] <jepler> ipcrm -M 0x3e9 -M 0x3ea -M 0x3eb -M 0x3ec -M 0x3ed
[02:36:55] <SWPLinux> but wouldn't there need to be some userspace app running to maintain those buffers?
[02:37:28] <jmk-wvm> jepler: if we're using loadusr -W to spawn rtapi_app, we should probably be passing the name of the rt comp (maybe you are)
[02:38:01] <jepler> no error after: cvs up -D"1/14" halcmd.c
[02:38:07] <jepler> but I did get the problem after 'cvs up'
[02:38:50] <jepler> The args I prepare for do_loadusr_cmd are: -Wn mod_name rtapi_app load mod_name ...
[02:38:55] <jmkasunich> I just added the "exited without ready" thing yesterday
[02:39:00] <SWPLinux> do all rt comps become "ready" (like motmod)?
[02:39:03] <jmkasunich> yeah, seeing that now in the source
[02:39:11] <SWPLinux> or is that only ones using the python lib
[02:39:16] <jmkasunich> SWPLinux: that might be it
[02:39:55] <SWPLinux> ok - it does signal "ready"
[02:39:59] <jepler> I believe that every comp becomes ready
[02:40:04] <jepler> I wrote the doc to say that they all must become ready :-P
[02:40:09] <SWPLinux> looks that way :)
[02:40:45] <jmkasunich> the sim checkout on this box (some strange version) only shows ready for user comps
[02:41:02] <jmkasunich> jmkasunich@ke-main-1006:~/emcdev/emc2sim$ bin/halcmd show comp
[02:41:03] <jmkasunich> Loaded HAL Components:
[02:41:03] <jmkasunich> ID Type Name PID Ready?
[02:41:03] <jmkasunich> 12359 User halcmd12359 12359 ready
[02:41:03] <jmkasunich> 12350 User axisui 12350 ready
[02:41:04] <jmkasunich> 12337 User hal_manualtoolchange 12337 ready
[02:41:05] <jmkasunich> 32772 RT scope_rt
[02:41:05] <jepler> at first the flag only existed for user comps
[02:41:07] <jmkasunich> 32771 RT blocks
[02:41:09] <jmkasunich> 32770 RT motmod
[02:41:12] <jmkasunich> 32769 RT trivkins
[02:41:13] <jmkasunich> 12325 User iocontrol 12325 ready
[02:41:23] <jmkasunich> ok, this is just old and crappy and I should make it go away
[02:41:50] <jmkasunich> whats the cvs foo for stripping stickys? -A? -a?
[02:42:09] <jepler> I use -CA
[02:42:12] <jepler> -C gets rid of local mods too
[02:42:22] <SWPLinux> dPAC is what cradek suggested before
[02:42:54] <jmkasunich> ok, bringing this box up to date
[02:43:04] <jmkasunich> if it happens here, I don't have to screw around with the laptop
[02:46:01] <SWPLinux> my checkout is from 2 days ago, plus updates
[02:50:05] <jepler> jmkasunich: I need to look at the source again, but what if in the same polling period, the new component became ready, but the process also exited?
[02:50:21] <jmkasunich> perhaps I should re-order the tests
[02:50:27] <jepler> hal_ready in the master rtapi_app and the exit of the slave rtapi_app happen very close to the same time
[02:50:29] <jmkasunich> it tests for exit first
[02:50:53] <jmkasunich> with normal hal apps, it becomes ready and hangs around for a long time, but rtapi_app should probably go the other way
[02:50:58] <SWPLinux> that's a race condition anyway
[02:51:21] <jmkasunich> reversing the order will fix the race
[02:51:29] <jmkasunich> you can't become ready after you exit
[02:51:40] <jmkasunich> well, it won't fix it
[02:51:46] <jepler> it doesn't fix it
[02:51:51] <jmkasunich> but it will reduce the window from 10mS to some microseconds
[02:51:53] <SWPLinux> and the wait is actually done in the pidwait() function?
[02:52:04] <jmkasunich> no, the nanosleep at the top of the loop
[02:52:10] <SWPLinux> err - waitpid :)
[02:52:30] <jmkasunich> the waitpid call in the loop has NOHANG, its non-blocking
[02:52:40] <SWPLinux> on, so component becomes ready then exits ... - the HAL data for that component is gone, so where's the ready flag?
[02:52:44] <SWPLinux> s/on/ok/
[02:53:13] <jepler> in some other process
[02:53:18] <SWPLinux> ok :)
[02:54:09] <jepler> consider the component that is a shell script: #!/bin/sh ; hal_example ...
[02:54:28] <SWPLinux> or the component that is halcmd ...
[02:54:29] <jepler> the PID of the component is not the pid of the shell script, which is the only pid that halcmd knows about
[02:54:40] <jepler> halcmd waits for the component, doesn't care about the pid (except to check whether it exits or not)
[02:55:16] <jepler> MOTION: init_module() complete
[02:55:15] <jepler> rtapi_app_main returned 0
[02:55:15] <jepler> master: load motmod base_period_nsec=1000000 servo_period_nsec=1000000 traj_period_nsec=10000000 key=111: writing 0
[02:55:18] <jepler> slave: got 0
[02:55:21] <jepler> task 0x8050960 period = 1000000 ratio=1
[02:55:24] <jepler> HAL:7: ERROR: /tmp/emc2/bin/rtapi_app (motmod) exited without becoming ready
[02:56:48] <jepler> I am very confident that the component really is ready when the slave rtapi_app exits
[02:56:54] <jepler> this patch does seem to fix it:
[02:56:55] <jepler> http://www.pastebin.ca/319186
[02:57:02] <jmkasunich> its almost certainly the order of the tests
[02:57:42] <jepler> I get the return value first. then check if it became ready and set the 'ready' flag. then check the exit value, if the program exited. if it exited and was ready during the same trip through the loop, it doesn't treat it as an error.
[03:03:27] <jmkasunich> an error return from waitpid (retval < 0) is very unlikely, but if it happens, I'm gonna assume that is an error regardless of ready or not
[03:04:44] <jepler> yeah
[03:04:49] <jepler> a waitpid error seems most likely to indicate a bug in halcmd
[03:05:06] <jmkasunich> what I have right now is
[03:05:09] <jmkasunich> call waitpid
[03:05:16] <jmkasunich> check for negative retval
[03:05:27] <jmkasunich> check for ready (find comp by name, etc)
[03:05:50] <jmkasunich> check for positive retval, if positive, check for ready, if not print error message
[03:06:23] <jmkasunich> last sentence unclear
[03:06:26] <jmkasunich> check for positive retval, if positive, check for ready, if not ready print error message
[03:07:00] <jepler> why not: if(comp && comp->ready) break;
[03:07:06] <jepler> er
[03:07:12] <jepler> why not: if(comp && comp->ready) { relase_lock; break; }
[03:07:13] <jmkasunich> yeah, I was just thinking that
[03:07:22] <jmkasunich> the loop can be while 1
[03:07:27] <jmkasunich> and ready or exit can both break
[03:07:31] <jmkasunich> then the decision and message code is after
[03:08:21] <jmkasunich> eliminates one copy of the "if count > 100 print "\n" code
[03:08:31] <SWPadnos> while (!too much time has passed) ...
[03:08:51] <jepler> how much time is too much time?
[03:09:05] <SWPadnos> dunno, but endless loop in halcmd probably is
[03:09:13] <jmkasunich> the user gets to decide - if too much time has passed, he kills the program
[03:09:16] <SWPadnos> though ctrl-C works
[03:09:21] <jmkasunich> when it dies, the loop exits
[03:16:31] <jmkasunich> how about this: http://www.pastebin.ca/319198
[03:21:56] <jepler> I don't see any problems
[03:22:01] <jepler> does it also make sim work right?
[03:22:23] <jmkasunich> still testing
[03:22:37] <jmkasunich> tweaking actually
[03:22:39] <jmkasunich> http://www.pastebin.ca/319202
[03:22:55] <jmkasunich> gets rid of a little more duplicated code, and maybe a little clearer
[03:23:50] <jepler> retval has a scope that begins above the if() ?
[03:23:58] <jmkasunich> oops
[03:24:09] <jmkasunich> see, I'm used to declaring all vars at the start of the function
[03:24:35] <jmkasunich> and I did...
[03:24:38] <jmkasunich> so yes, it does
[03:24:48] <jepler> now you made the case 'ready but waitpid had an error' into a success for loadusr
[03:25:04] <jmkasunich> no I didn't
[03:25:07] <jepler> I don't think this is a problem, but it's a difference from what you had earlier
[03:25:12] <jepler> you didn't?
[03:25:29] <jmkasunich> if ready print happy, if not, print one of two differnet messages, but return -1 either way
[03:26:04] <jmkasunich> at least thats what I think I wrote
[03:26:20] <jepler> in http://www.pastebin.ca/319198 you tested retval < 0 before looking at ready
[03:26:27] <jepler> now you test ready first, retval < 0 second
[03:26:44] <jmkasunich> oh
[03:27:04] <jepler> it's a difference but I don't think it's important
[03:27:17] <jmkasunich> well if the component becomes ready, we don't care about waitpid do we?
[03:28:01] <jepler> not really
[03:32:47] <jmkasunich> libpth is a new dependency for sim only?
[03:35:38] <jepler> yes
[03:35:56] <jmkasunich> like an idiot I made all my changes on my rt checkout
[03:35:56] <jepler> it's a threading library that can be used in a cooperative threading mode
[03:36:13] <jmkasunich> so I had to copy over and build again for sim
[03:36:48] <jmkasunich> has anyone tried building for RT, then reconfiguring and building for sim, in the same tree?
[03:36:58] <jmkasunich> ISTR that did bad things, but that was a while ago
[03:39:23] <jepler> hal/utils/halcmd.c:2062: warning: 'retval' may be used uninitialized in this function
[03:39:27] <jepler> I do get this warning
[03:40:06] <jepler> with your change in 319198 I got several correct startups in a row, no trouble
[03:40:37] <jmkasunich> I'm about to test the later one (which doesn't have the warning)
[03:41:21] <jepler> I meant to test the last one but I got confused by all the pastebin urls :-P
[03:41:55] <jmkasunich> oh, it does get the warning
[03:42:00] <jmkasunich> * jmkasunich investigates
[03:42:27] <jmkasunich> oh, it must not grok the initializers, and assumes that the loop can be skipped
[03:42:54] <jepler> yeah sometimes gcc can't figure out everything you can
[03:43:13] <jmkasunich> I'll just zero retval before the loop
[03:45:23] <jmkasunich> yay, works
[03:46:17] <jmkasunich> there is still potential for confusing error messages when running sim
[03:46:46] <jmkasunich> if you loadrt something and it fails for any reason, the message you get will be that rtapi_app exited without becoming ready
[03:47:08] <jmkasunich> unless you know that sim does loadrt foo by calling loadusr rtapi_app foo, you are gonna be confused
[03:47:31] <jmkasunich> but short of major changes, I don't see how to fix that
[03:51:51] <jepler> yeah
[03:52:11] <jepler> it would be better if they at least used different error reporting code
[03:52:27] <SWPLinux> one possibility is to add a parameter to loadusr that tells it to do its work silently, and leave the error message printing to loadrt
[03:52:31] <jepler> but I don't want to get into that mess either
[03:52:54] <jepler> let my mantra be: after 2.1
[03:55:01] <cradek> someone said changing the toolSts size broke 32 bit machines - was that wrong?
[03:56:12] <SWPLinux> I said that - I think it broke some machines, but I don't know that it was a 32-bit / 64-bit thing
[03:56:25] <jepler> something leaves an old shared memory buffer around, and until you 'ipcrm' it or reboot there's a size mismatch for the shared memory
[03:56:28] <jepler> I think that's the problem
[03:56:29] <SWPLinux> and jepler pointed out that it may have been something else entirely
[03:56:30] <jepler> I'm not 100% sure
[03:56:49] <jepler> for now, it's in 2.2, not 2.1
[03:57:21] <cradek> ok, just wondered
[03:57:32] <cradek> seems strange that it would break anything, since other buffers are bigger already
[03:57:39] <jepler> do you mean someone just said it again, or are you remembering the last time I tried to change this?
[03:57:54] <cradek> someone said it in the last couple days
[03:58:03] <cradek> maybe it was alex
[03:58:07] <jmkasunich> didn't it happen to SWP just an hour or so ago?
[03:58:13] <cradek> heh, I wasn't here
[03:58:49] <SWPLinux> it did, and ipcrm fixed it
[03:58:51] <jmk-wvm> ok, configs/sim/axis.ini is now working on the laptop in simulation
[03:58:59] <jmk-wvm> thanks guys
[03:59:00] <cradek> new laptop?
[03:59:04] <SWPLinux> or, it was different after running ipcrm :)
[03:59:20] <jepler> we should figure out under what circumstances that shared memory stays around, and fix it -- but not tonight
[03:59:21] <jmkasunich> cradek: yeah, new work one
[03:59:30] <jepler> goodnight guys
[03:59:35] <cradek> bye
[03:59:41] <jmkasunich> it has XP on it, but somehow vmware and dapper found their way onto the disk
[03:59:42] <jmkasunich> goodnight jeff
[03:59:59] <jepler> jmkasunich: thanks for working on that loadusr stuff
[04:00:21] <jmkasunich> thanks for helping me find the problem (after all, I put it there)
[04:00:53] <SWPadnos> see you Jeff
[04:08:59] <jmkasunich> I have a vmware tools question
[04:09:04] <SWPLinux> shoot
[04:09:22] <jmkasunich> I'm doing the install, and it wants to build a module (none of the prebuilt ones are suitable it says)
[04:09:27] <jmkasunich> this is stock dapper btw
[04:09:37] <jmkasunich> it wants to know where the kernel headers are
[04:09:47] <cradek> you'll need to install them (and the compiler)
[04:09:59] <jmkasunich> I rememeber screwing around with this for quite a while several days ago and never got anywhere
[04:10:08] <cradek> apt-get install linux-headers-`uname -r`
[04:10:19] <jmkasunich> I installed several packages that I thought were the kernel headers but didn't seem to make it happy
[04:10:24] <jmkasunich> I'll try again
[04:10:33] <SWPLinux> did it not find them? (I'd assume you have headers or you wouldn't be able to compile emc)
[04:11:44] <jmk-wvm> right now I'm only compiling the sim version of emc, so that may not be a good indicator
[04:11:57] <SWPLinux> ok
[04:12:06] <jmk-wvm> ok, apt-get install done
[04:12:24] <jmk-wvm> I'm gonna have to tell the vmware script where the headers are
[04:13:32] <SWPLinux> /usr/src/linux-headers-`uname -r`
[04:15:39] <jmk-wvm> The path "/usr/src/linux-headers-2.6.15-27-386" is an existing directory, but
[04:15:40] <jmk-wvm> it does not contain a "linux" subdirectory as expected.
[04:15:49] <jmk-wvm> (thats a bitch from the vmware installer)
[04:16:03] <SWPLinux> link /usr/src/linux to that dir, and use /usr/src
[04:16:30] <jmk-wvm> ln -s?
[04:16:51] <SWPLinux> yeah. though I always forget the order of the dirs ...
[04:17:08] <jmk-wvm> so do I, but I'll rtfmp
[04:17:44] <SWPLinux> the other problem is when to use the trailing /, and on which of the names
[04:18:11] <cradek> sounds like the vmware tool build is bogus
[04:19:04] <cradek> I don't remember ever playing those games - but maybe I never installed the tools
[04:19:15] <jmk-wvm> next bitch:
[04:19:16] <jmk-wvm> The path "/usr/src" is a kernel header file directory, but it does not contain
[04:19:15] <jmk-wvm> the file "linux/version.h" as expected. This can happen if the kernel has
[04:19:15] <jmk-wvm> never been built, or if you have invoked the "make mrproper" command in your
[04:19:15] <jmk-wvm> kernel directory. In any case, you may want to rebuild your kernel.
[04:19:43] <SWPLinux> right - make headers or make mrproper is needed
[04:19:53] <cradek> no it's not
[04:20:02] <SWPLinux> ok
[04:20:06] <cradek> those linux-headers packages are set up for kernel module builds already
[04:20:25] <cradek> you don't have to do that stuff anymore
[04:20:41] <cradek> that file is /usr/src/linux-headers-`uname -r`/include/linux/version.h
[04:20:45] <jmk-wvm> but this install script doesn't know that...
[04:20:55] <cradek> you have to coerce it somehow
[04:21:04] <cradek> maybe the path it wants is /usr/src/linux-headers-`uname -r`/include
[04:21:18] <jmk-wvm> yes
[04:21:59] <SWPLinux> you could try exiting and re-running the script, now that you have the headers installed
[04:22:14] <SWPLinux> though I'm not sure if that may break something
[04:22:27] <SWPLinux> (I don't think so, but I can't remember for sure)
[04:22:56] <jmkasunich> hmm, it must have disconnected the network during the install
[04:23:03] <SWPLinux> yes
[04:23:10] <jmkasunich> "yes" was because it did the build
[04:23:18] <jmkasunich> now its offering me a choice of video modes
[04:23:26] <cradek> yay
[04:23:38] <SWPLinux> cool
[04:23:39] <jmkasunich> 1920 x 1200 is on the list and I'm tempted to pick it
[04:23:47] <jmkasunich> but do you think it will only work fullscreen?
[04:23:48] <SWPLinux> nice. I wonder why I don't get that
[04:23:56] <SWPLinux> no, it'll scroll around
[04:24:10] <SWPLinux> you just can't drag the window that large, I think
[04:24:25] <jmkasunich> so then I can go fullscreen when I want, and have the entire thing linux
[04:24:27] <jmkasunich> cool
[04:24:41] <jmkasunich> begone XP! (or at least, go into hiding)
[04:24:50] <tomp> is there a list of all the click events available to tkinter?
[04:25:02] <jmk-wvm> its offering me display sizes now
[04:25:04] <jmk-wvm> I'm tempted to pick 1920 x 1200, but that might only work fullscreen
[04:26:50] <cradek> hey what happens when I push this bu
[04:26:57] <SWPLinux> *boom*
[04:27:03] <jmkasunich> hhe
[04:27:06] <jmkasunich> heh even
[04:27:17] <jmk-wvm> restarted the networking
[04:27:23] <jmk-wvm> gotta restart X to get the new screen size
[04:27:39] <jmk-wvm> is there a quicker way to restart x on dapper than rebooting?
[04:27:52] <jmk-wvm> * jmk-wvm hangs his head, thats such a doze thing to do
[04:27:55] <SWPLinux> ctrl-alt-backspace (but that's hard in a VM)
[04:27:58] <cradek> ctrl-alt-backspace
[04:28:08] <cradek> easy with the keyboard grabbed
[04:28:14] <SWPLinux> you can change the un-grab key combo to ctrl-shift, I think
[04:28:16] <cradek> oh, that ungrabs, doesn't it
[04:28:17] <cradek> hmmm
[04:28:19] <SWPLinux> right
[04:28:31] <jmk-wvm> * jmk-wvm reboots it ;-)
[04:29:16] <jmkasunich> after all, its only a virtual reboot
[04:29:20] <SWPLinux> or sudo /etc/init.d/gdm restart :)
[04:29:26] <jmkasunich> now you tell me
[04:29:29] <SWPLinux> heh
[04:29:42] <SWPLinux> it's just a VM - you'll have to reboot as often as XP ...
[04:31:54] <jmk-wvm> now thats more like it
[04:31:59] <jmk-wvm> big effin screen
[04:32:11] <jmk-wvm> well, lots of pixels anyway, its not really big
[04:32:31] <cradek> welcome to the world of the two-inch-wide internet
[04:32:45] <jmk-wvm> 15.4"
[04:32:59] <SWPadnos> ok - similar to jepler's laptoop screen
[04:33:01] <SWPadnos> -o
[04:33:23] <cradek> sadly, most of the internet is 800 pixels wide
[04:33:41] <SWPadnos> yeah - but at least you can have two full internets side by side
[04:33:47] <SWPadnos> plus extra space
[04:34:30] <jmk-wvm> more like 4 shells and an editor and xchat and firefox
[04:34:51] <jmk-wvm> that does involve some overlapping tho
[04:35:48] <SWPadnos> I kinda like kate at 1920x1100 or so (panels, you know)
[04:35:54] <jmk-wvm> yeah
[04:36:07] <jmk-wvm> I usually have kate full width, and about half height
[04:36:09] <SWPadnos> 2 or 3 files at reasonable width, and a very wide terminal underneath
[04:36:13] <jmk-wvm> shells underneath
[05:37:59] <tomp> pyvcp knobs pic http://imagebin.org/6945
[05:38:47] <tomp> pyvcp_widgets.py http://pastebin.ca/319271
[05:39:23] <tomp> test xml for knobs http://pastebin.ca/319274
[05:40:02] <SWPadnos> I think the scale on the FarfelNoogies is a bit low ;)
[05:40:17] <tomp> remember farfel the dog?
[05:40:25] <SWPadnos> nope
[05:40:44] <SWPadnos> is 0 to the right? (or is that settable)
[05:41:01] <tomp> where?
[05:41:18] <SWPadnos> hmmm - what do the two numbers mean?
[05:42:00] <tomp> yeah, thats a todo, middle is current value, botttom is current scale ( how much 1 tick changes value)
[05:42:26] <SWPadnos> does it snap between ticks?
[05:42:35] <SWPadnos> err - snap from tick to tick
[05:43:07] <tomp> yes, a lot when ticks per rev is low ( like 2 is crazy jerky ) but the user can do as he likes, it works still
[05:43:56] <tomp> the scale can be changed at will , mux by 10 or div by 10 with modified clicks
[05:44:06] <SWPadnos> ok. this is a multi-turn knob. can it be made one-turn (or less)?
[05:44:08] <SWPadnos> sure
[05:44:19] <tomp> yes
[05:44:49] <SWPadnos> can you specify where the start and end angles are (fro the ticks)?
[05:44:49] <tomp> it can go min to max inside 360 ( but ticks marks fill 360 now )
[05:44:54] <SWPadnos> ok
[05:44:56] <tomp> not now
[05:45:06] <tomp> looking for other peepl to fiddle w it
[05:45:09] <SWPadnos> ok - that's why I was asking if 0 is "east"
[05:45:24] <SWPadnos> all the dots are at the rigth
[05:45:28] <SWPadnos> right
[05:46:03] <tomp> there's not really a 'zero' there's a current state and more and less, but it begins with given xml initial value at 12 o clock
[05:46:30] <tomp> you can say an initial value
[05:47:09] <tomp> the text scales :) i found a trick
[05:47:22] <SWPadnos> cool
[05:48:09] <tomp> you specify the font size with a negative number, then it's pixels
[05:48:27] <SWPadnos> right
[05:49:49] <tomp> dbl click left btn to divide scale by 10, dbl click right to mux by 10
[05:50:12] <tomp> dbl clcik middle ( or both on my mouse) to restore original scale
[05:50:16] <SWPadnos> nice
[05:50:35] <tomp> shift click to restore orinal pot value ( the oops click )
[05:51:03] <SWPadnos> double-both-click must be fun to try
[05:51:29] <tomp> i used it, it works, all the way up to triple-button-3
[05:51:46] <SWPadnos> sounds hard to get right
[05:52:09] <SWPadnos> especially for someone who has used a 3-button (or more) mouse since ~1988
[05:52:25] <tomp> but i usually give the mouse a little nudge at even dbl clcik, so it's not exactly the event i wanted ( theers a tiny drag too )
[05:52:59] <tomp> i dont have a wheel mouse, so maybe someone can try that, it should be like dragging
[05:53:42] <tomp> hokay, thanks, i'm outta here!
[12:32:18] <tomp> pyvcp knobs pix http://imagebin.org/6945
[12:32:22] <tomp> pyvcp_widgets.py http://pastebin.ca/319271
[12:32:27] <tomp> text xml for knobs http://pastebin.ca/319274
[12:33:33] <tomp> gotta run bb2nite
[23:33:58] <jmkasunich> damned mail - I sent a message to the dev list a few hours ago, but it hasn't showed up
[23:35:01] <jmkasunich> hmm, it made it into the archives - I guess the problem is delivery from SF back to me
[23:35:34] <SWPadnos> I got it - it was about an html doc, right?
[23:35:41] <SWPadnos> or html device ...
[23:35:45] <jmkasunich> yeah
[23:36:05] <jmkasunich> I'm gonna be away this evening, just making sure it got thru
[23:36:19] <jmkasunich> dunno if jepler knows about the man to html conversions... I sure don't
[23:36:36] <SWPadnos> me either. that documentation stuff is voodoo to me
[23:36:38] <jepler> I probably know as much as anybody .. which ain't much
[23:36:41] <cradek> jmkasunich: do you use UTC dates on your emails on purpose, or is it a misconfiguration?
[23:36:44] <jmkasunich> (and I also couldn't exactly go diving into it at work anyway - I just tried a quick build)
[23:36:56] <jepler> oh -- you're missing a package
[23:37:08] <jepler> I guess configure should check
[23:37:21] <jepler> the "groff" package
[23:37:30] <jmkasunich> cradek: I didn't think I was using UTC
[23:38:09] <cradek> groff: usr/share/groff/1.18.1/font/devhtml/DESC
[23:38:13] <jmkasunich> I use webmail, so the time probably comes from my ISP's servers, not from my box
[23:38:54] <cradek> ok, so misconfiguration :-)
[23:39:04] <jmkasunich> where do you see UTC anyway
[23:39:10] <cradek> the Date: header
[23:39:33] <cradek> it's not wrong necessarily, it's just strange - usually people use their own localtime
[23:40:00] <jmkasunich> I would look at the header, except the damn mail hasn't come back to me yeyt
[23:40:03] <jmkasunich> yet
[23:40:09] <jmkasunich> strangely, I just got jeff's response tho
[23:40:45] <jmkasunich> I'll install groff later (or tomorrow), going out this evening
[23:40:55] <jmkasunich> thanks for the quick answer
[23:40:56] <cradek> I got yours 8 mins after you sent it
[23:42:58] <jmkasunich> ATT (my isp) and SF occaisionally have pissing contests when each thinks the other is a spammer
[23:43:12] <jmkasunich> but that wouldn't explain jeff's response beating my original message
[23:43:39] <jepler> checking for HTML support in groff... no groff -Thtml, documentation will not be built
[23:44:03] <jmkasunich> that was already in there? or you just added it?
[23:44:06] <jepler> just added it
[23:44:10] <jmkasunich> cool
[23:44:34] <jepler> if you remember, update before adding the groff package to make sure it fails, then add groff and make sure it succeeds
[23:44:38] <jepler> if it does I'll backport that to 2.1 as well
[23:44:55] <jepler> I tried removing the groff package and it seems to have worked here, but another data point would be great
[23:45:21] <jmkasunich> I was trying on the VM on my work laptop
[23:45:30] <jmkasunich> I'll try it at lunchtime tomorrow
[23:45:40] <jmkasunich> unless I get home early this evening and try it then
[23:45:55] <jmkasunich> time to go, thanks again
[23:46:01] <jepler> see you
[23:46:03] <jepler> glad to help
[23:46:16] <jmkasunich> I'm being a tester ;-)
[23:46:30] <jmkasunich> its actually quite informative to start from scratch every once in a while
[23:46:37] <jmkasunich> finds problems that we might otherwise miss
[23:47:17] <jepler> yes indeed