Back
[03:38:27] <SWPadnos> SWPadnos is now known as SWP_Away
[13:06:36] <rayh> Small issues this morning.
[13:06:56] <rayh> 1 - univstep says it can't find a param
[13:07:26] <rayh> HAL:7: ERROR: parameter 'ppmc.0.stepgen.00-03.pulse-width' not found
[13:07:27] <rayh> HAL config file /home/rayh/emcdevelop/emc2/configs/univstep//univstep_motion.hal failed.
[13:08:30] <rayh> Also the new link to halcmd seems to try to open it in the wrong place because it can't find bin/halcmd.
[13:09:19] <cradek> rayh: did you run configure? I think alex put in some things yesterday.
[13:09:37] <rayh> Yes I did.
[13:09:50] <rayh> on a check out this morning.
[13:10:03] <cradek> hmm
[13:10:08] <rayh> thanks for reminding me.
[13:10:23] <cradek> which thing is trying to run bin/halcmd? I will look at it with you
[13:10:25] <rayh> I did fail to run the sudo command that sets uid
[13:10:53] <rayh> got some odd error message.
[13:10:57] <cradek> I think that will make halcmd not work right when invoked
[13:11:10] <cradek> (it won't cause anything to not be able to run halcmd)
[13:11:12] <rayh> But then that could just be me again.<g>
[13:11:54] <cradek> which thing is trying to run bin/halcmd? I will look at it with you
[13:12:28] <rayh> Alex put a link under tkemc menu --> scripts to HAL CONFIG
[13:12:42] <rayh> It starts halconfig.tcl
[13:12:53] <rayh> but the complaint is that it can't find halcmd.
[13:13:00] <cradek> cool, I saw that in the new deb I built last night (and it ran correctly)
[13:13:10] <cradek> ok there must be a problem with run-in-place
[13:13:16] <rayh> Right.
[13:13:31] <cradek> tk_messageBox -icon error -type ok -message "The configuration script needs to be run from the main EMC2 directory. Please add the emc2/bin dir to PATH before running this command"
[13:13:36] <cradek> is this the error?
[13:13:59] <rayh> TCLBIN=/home/rayh/emcdevelop/emc2/tcl/bin
[13:13:59] <rayh> Error in startup script: couldn't execute "halcmd": no such file or directory
[13:13:59] <rayh> while executing
[13:14:00] <rayh> "exec halcmd"
[13:14:40] <cradek> does it say which line of halconfig.tcl it is?
[13:15:05] <rayh> No I'm assuming it is the open channel stuff.
[13:16:21] <cradek> before the first exec halcmd, please add a puts stderr $env(PATH) and see if ..../emc2/bin is in there
[13:17:01] <rayh> k
[13:19:29] <rayh> can't read "env(PATH)":
[13:19:53] <rayh> I'll bet I need to \$
[13:21:35] <cradek> I have to get going - be back in an hour or so
[13:22:00] <cradek> my theory is that PATH isn't being set right - it should have ..../emc2/bin in it
[13:22:15] <rayh> okay. I've got emc stuck trying to clean up.
[13:22:23] <cradek> that comes from $EMC2_BIN_DIR in scripts/emc line 394
[13:22:28] <cradek> ugh
[13:22:36] <cradek> that's always fun
[13:22:58] <cradek> usually sudo rmmod motmod blocks (I think) fixes it for me
[13:23:18] <cradek> see you soon, I'll help if you don't have it by then
[13:23:26] <rayh> okay.
[13:47:02] <alex_joni> morning
[13:47:11] <alex_joni> hi ray.. still having problems?
[13:47:23] <alex_joni> darn.. talking alone again :D
[14:04:11] <alex_joni> hey ray
[14:04:16] <alex_joni> seen you had some problems
[14:05:15] <rayh> Yep. I think the pin problem was that I hadn't powered the univstep board.
[14:05:46] <rayh> The issue with halconfig is probably a lack of pointer to the correct location of halcmd.
[14:06:03] <rayh> In a run-in-place setup.
[14:07:07] <rayh> The lockup of rtai_math and reboot ate a bit of my kde config again.
[14:07:26] <rayh> One of these days I'll be forced to reinstall on this box.
[14:10:13] <alex_joni> the issue of halconfig sounds like teh runscript wasn't rebuild
[14:10:21] <alex_joni> try issuing src/config.status
[14:10:25] <alex_joni> then make -s
[14:10:45] <alex_joni> make does the chmod +x emc and chmod +x realtime (you could also run those manually..)
[14:44:30] <cradek> rayh: halconfig for both installed and run-in-place works for me
[14:44:42] <cradek> rayh: and I think it looks really good (I hadn't looked at it yet)
[14:49:32] <cradek> rayh: How do I use watch?
[14:55:29] <SWP_Away> click on tree nodes - they'll be added to the list of watched variables
[14:55:36] <SWP_Away> SWP_Away is now known as SWPadnos
[14:55:51] <cradek> I just get "xxxx XPos" then
[14:55:56] <cradek> and it doesn't update
[14:56:02] <SWPadnos> hmmm
[15:00:34] <SWPadnos> wow. SF seems pretty slow today
[15:00:43] <cradek> yeah, from here too
[15:01:01] <SWPadnos> like 15 seconds before the cvs password prompt
[15:01:16] <cradek> it didn't work at all yesterday, so this is better
[15:01:22] <SWPadnos> baby steps
[15:02:55] <SWPadnos> I'm a little paranoid about make clean since Ray's problem
[15:03:20] <cradek> I think there's nothing wrong with make clean
[15:03:33] <SWPadnos> it hasn't eaten my machine yet, so that's a good thing
[15:05:07] <jepler> Is there some reason that (cd foo; $(MAKE)) is used, instead of (cd foo && $(MAKE)) or $(MAKE) -C foo ?
[15:05:22] <SWPadnos> "because that's the way it is"
[15:06:03] <SWPadnos> does make -C maintain all the variables, or is it a "clean environment"?
[15:06:25] <SWPadnos> make vars, that is
[15:07:26] <rayh> I always issue make clean before I cvs up.
[15:07:56] <SWPadnos> that's probably the better way to do it, rather than cvs up / configure / make clean / make
[15:08:27] <rayh> I used to do that and had the two big faiilures.
[15:08:45] <cradek> jepler: what difference does that make?
[15:09:36] <rayh> I'm still getting the failure to find halcmd.
[15:10:08] <rayh> But it is from the testing stuff rather than from the open channel.
[15:10:08] <jepler> cradek: try removing a subdirectory, and type "make all"
[15:11:05] <cradek> jepler: true it should be (cd foo && $(MAKE))
[15:11:11] <cradek> jepler: I skipped over that part of your question
[15:11:46] <cradek> jepler: fixes happily accepted
[15:11:59] <jepler> cradek: I'm working on it
[15:12:53] <rayh> re halconfig and watch. I still have a problem in the code adding vars.
[15:13:12] <rayh> sounds like your click did not get a proper return from halcmd.
[15:13:17] <jepler> make -C module_helper all
[15:13:18] <jepler> make: *** module_helper: No such file or directory. Stop.
[15:13:18] <jepler> make: *** [all] Error 2
[15:13:19] <cradek> rayh: ok, didn't know if it was finished or not
[15:13:19] <jepler> well this works now
[15:13:26] <rayh> I should have that working in a bit.
[15:13:52] <cradek> rayh: I think the rest of it is looking good
[15:14:06] <rayh> Thanks.
[15:17:00] <SWPadnos> it seems to work fine for pins and params, but signals don't get updated
[15:17:41] <cradek> ah, I think I only tried signals
[15:19:36] <rayh> cradek: Didn't like my "darn". What should be done for those who are not using a debian based install.
[15:20:17] <cradek> rayh: I guess they have to find a package appropriate for their system, or build it from source
[15:20:42] <cradek> jepler: I don't think your fix to configure.in is quite what you meant
[15:21:04] <jepler> cradek: oops, what did I foul up?
[15:21:13] <jepler> cradek: perhaps the bwidget message should direct the user to '
http://sourceforge.net/project/showfiles.php?group_id=12883&package_id=23786'
[15:21:29] <cradek> case $a in a) chmod a b;; b) chmod a b;; esac
[15:21:41] <jepler> oops!
[15:21:49] <cradek> you probably want case $a in b|c) chmod $a;; esac
[15:21:49] <jepler> I changed configure.in to fix that but didn't regenerate again.
[15:21:50] <jepler> doh
[15:22:01] <rayh> apt is certainly the easier way to get it.
[15:22:32] <cradek> I think the apt message is going to be appropriate for almost everyone
[15:22:53] <cradek> others will already understand that their system is not "mainstream" for emc2 and will have experience with this kind of thing
[15:24:15] <jepler> cradek: better now? (configure)
[15:24:18] <cradek> jepler: oops, I forgot you didn't write that by hand
[15:24:36] <cradek> yes, better
[15:25:30] <rayh> On a run-in-place system if you fail to sudo make setuid you get some strange error messages that don't point you to the source of the problem.
[15:25:45] <cradek> jepler: did you take the corresponding chmods out of the Makefile?
[15:26:03] <cradek> rayh: what error do you get?
[15:27:20] <rayh> I was looking to see what the reply would be if I tried to run emc without issuing sudo make setuid.
[15:27:55] <rayh> The answer was. insmod: error inserting '/lib/modules/2.6.12.6-magma/kernel/adeos/adeos.ko': -1 File exists
[15:28:30] <cradek> that must be an error from something else
[15:28:36] <cradek> you already had the adeos module inserted
[15:28:55] <cradek> I expect it to say something about permission denied if you don't make setuid
[15:29:24] <rayh> I'd guess that's what we get for expecting.
[15:29:55] <rayh> I got a whole set of these. Nothing had been running before, I don't think.
[15:30:03] <rayh> This was a new clean make
[15:30:18] <cradek> well that message means you already had the modules inserted.
[15:30:53] <cradek> forgetting make setuid for run-in-place will get you an error only from halcmd, I think.
[15:31:00] <rayh> Okay. I'll take the time to reproduce the problem.
[15:31:01] <cradek> the module helper is not even used.
[15:31:14] <cradek> ok thanks
[15:32:41] <rayh> now I'm getting some really goofy stuff.
[15:32:45] <rayh> rm -f ../include/* ../lib/* ../rtlib/* ../bin/*
[15:32:46] <rayh> rm: cannot remove `../include/CVS': Is a directory
[15:32:46] <rayh> rm: cannot remove `../rtlib/CVS': Is a directory
[15:32:46] <rayh> rm: cannot remove `../bin/CVS': Is a directory
[15:32:47] <rayh> make: [clean] Error 1 (ignored)
[15:34:11] <rayh> That emc2 is gone, getting a new one.
[15:41:02] <cradek> gone?
[15:41:16] <cradek> those are fine, ignore them
[15:42:16] <cradek> I wonder why we have those empty directories in cvs anyway
[15:46:03] <SWPadnos> because people didn't want to create them with make?
[15:46:27] <cradek> yeah, but that seems silly since we populate them with make
[15:46:44] <SWPadnos> that's the silly part
[15:47:01] <cradek> the whole build is silly
[15:47:17] <SWPadnos> the include files should just be in the incude dir - there's no good reason to have the "sources" in separate dirs
[15:47:46] <SWPadnos> for anything that may need to be included by something else (like the nml-related stuff, HAL, ...)
[15:48:01] <SWPadnos> I read that paper, and it made a lot of sense
[15:48:02] <cradek> I'm not willing to move all those files and lose their history.
[15:48:09] <SWPadnos> that is an issue
[15:48:17] <SWPadnos> svn would help there :)
[15:50:24] <cradek> I hid those warnings instead of fixing it right.
[15:50:32] <SWPadnos> lazy bum
[15:51:10] <SWPadnos> now they'll never get fixed (out of sight, out of mind)
[15:51:13] <SWPadnos> :)
[15:51:41] <cradek> I guess I don't care
[15:52:27] <cradek> my idea of "right" (ruling out a massive restructuring) would be to remove them from cvs and put the mkdirs in the Makefile
[15:52:52] <cradek> then a safe clean could do rm ../include/*; rmdir ../include
[15:53:30] <SWPadnos> yep
[15:54:09] <cradek> feel free if you're offended by my fix, I won't be offended
[15:54:11] <SWPadnos> it doesn't look like the restructuring would be that massive - it's on the same order as the $(MAKE) -C changes jepler just did (right?)
[15:54:32] <SWPadnos> just change those to include ...
[15:54:48] <cradek> no, by restructuring I mean stop copying stuff into these directories.
[15:55:15] <SWPadnos> yes - move headers to the correct dir, and eliminate the recursive make (either qualifies as a restructuring)
[15:55:27] <cradek> I have to be careful because my instinct tells me to throw out the Makefiles and start over, and I don't want to spend the time on that.
[15:55:49] <rayh> The brand new system start with not setuid answers.
[15:55:54] <rayh> Version: 1.2
[15:55:54] <rayh> Machine: EMC-HAL
[15:55:54] <rayh> HAL:4: ERROR: Must be root to load realtime modules
[15:55:55] <rayh> HAL:4: ERROR: child did not exit normally
[15:55:56] <rayh> HAL config file /home/rayh/emcdevelop/emc2/configs/m5i20//../common/core_servo.hal failed.
[15:56:10] <cradek> rayh: great, that's the right error message
[15:56:19] <rayh> Okay.
[15:56:43] <SWPadnos> though it doesn't tell you exactly how to fix it (that's in a message at the end of the make)
[15:57:19] <rayh> Right. My ignoring that message was deliberate.
[15:57:20] <cradek> if someone wants to add "this is probably because halcmd is not setuid" that's fine with me
[15:58:23] <rayh> Now for the real problem of the morning -- halconfig not starting.
[15:58:42] <cradek> rayh: I tested that and it worked ok here. Maybe it will be ok on your new build.
[15:58:46] <SWPadnos> it does work here, using a new checkout
[15:58:58] <rayh> Error in startup script: couldn't execute "halcmd": no such file or directory
[15:59:19] <rayh> I should be so lucky.
[15:59:24] <SWPadnos> heh
[15:59:28] <rayh> This is run-in-place
[15:59:46] <SWPadnos> mine too, though I am logged in as root
[15:59:57] <rayh> Nor am I
[16:00:00] <cradek> I have tried it both ways
[16:00:12] <cradek> this is not a root issue, it must be a problem with PATH
[16:00:37] <rayh> IMO the fix needs to be in the emc rather than in the individual user's path var.
[16:00:52] <cradek> right, the emc script sets up this path
[16:01:53] <cradek> I forgot I cleaned, now I'm compiling again
[16:02:37] <rayh> In halconfig now there is no reference to a global path var like there is with the tickle stuff.
[16:02:57] <SWPadnos> does it use the HALCMD env var?
[16:03:03] <rayh> for example "set thisret [exec halcmd show $searchbase $searchstring]"
[16:03:04] <cradek> yes if I understand alex's change PATH is in the environment and [exec ...] uses it
[16:03:40] <rayh> k
[16:05:07] <SWPadnos> strange -the run script doesn't print the PATH, even in verbose mode
[16:07:11] <cradek> rayh: in your scripts/emc around line 396:
[16:07:16] <cradek> PATH=$EMC2_BIN_DIR:$PATH
[16:07:17] <cradek> echo PATH is $PATH
[16:07:22] <cradek> add that echo
[16:07:27] <cradek> run and see what you get
[16:08:17] <cradek> rayh: you're using tkemc right?
[16:08:46] <rayh> yes
[16:09:30] <rayh> Path is /home/rayh/emcdevelop/emc2/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
[16:09:44] <rayh> But IMO that is not the path to try to fix.
[16:09:48] <cradek> do you have a halcmd in /home/rayh/emcdevelop/emc2/bin
[16:10:24] <rayh> Yep
[16:11:24] <rayh> For now, I'll hard code the location of halcmd in my halconfig.
[16:11:50] <cradek> I think it would be better to find the problem while we're all here
[16:12:01] <SWPadnos> it may be helpful to see whether EMC2_BIN_DIR is being correctly set
[16:12:13] <cradek> it is; it's the first thing on his PATH
[16:12:21] <cradek> /home/rayh/emcdevelop/emc2/bin
[16:12:38] <SWPadnos> err - duh. I should read before I post :)
[16:13:04] <cradek> rayh: in tcl/tkemc put puts stdout "tkemc: PATH is $env(PATH)"
[16:13:12] <cradek> rayh: in tcl/tkemc put: puts stdout "tkemc: PATH is $env(PATH)"
[16:13:22] <cradek> to see if it's the same, or if it gets reset
[16:13:41] <cradek> (mine is the same)
[16:13:51] <SWPadnos> I see no export PATH ...
[16:14:07] <cradek> SWPadnos: I notice that too
[16:14:29] <cradek> SWPadnos: mine is definitely preserved over the exec
[16:14:32] <rayh> tkemc: PATH is /home/rayh/emcdevelop/emc2/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
[16:14:47] <cradek> ok, so that's not it either
[16:14:59] <cradek> so now do the same thing in halconfig.tcl
[16:16:29] <cradek> halconfig: PATH is /home/cradek/emc2/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
[16:16:38] <cradek> mine is the same in halconfig, I bet ray's is not
[16:16:59] <SWPadnos> hey - I've got no games :(
[16:18:49] <SWPadnos> as expected, it's preserved on my machine as well:
[16:18:56] <SWPadnos> tkemc: PATH is /Project/emc2/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
[16:19:09] <SWPadnos> (should be halconfig, not tkemc)
[16:19:11] <cradek> ok
[16:19:13] <cradek> right
[16:21:38] <SWPadnos> rayh, is this a completely new checkout, or was it an update?
[16:24:12] <rayh> new
[16:24:16] <SWPadnos> ok
[16:24:21] <rayh> phone
[16:24:39] <SWPadnos> I'll bbiab then
[16:24:50] <rayh> Just got a second report of a failed ubuntu.
[16:25:21] <cradek> failed at what stage?
[16:25:28] <rayh> cd burner drive didn't work
[16:25:52] <rayh> Last one was not start after install.
[16:26:13] <cradek> my cd burner doesn't work either, I haven't looked into it
[16:26:27] <cradek> there's probably something at ubuntu.com if it's a common problem.
[16:27:07] <rayh> Okay. I'll look around there a bit.
[16:27:21] <rayh> I went back to bin/halcmd and that works fine.
[16:27:30] <rayh> so I can work.
[16:28:11] <cradek> assuming the problem is only on your machine, that's fine I guess. I'm not sure it is though.
[16:29:23] <rayh> No I suspect that whatever scripts/emc is attempting to do to path doesn't always work.
[16:29:37] <cradek> then we should figure out why
[16:40:36] <SWPadnos> I can burn CDs on my SATA CD/DVD burner, under ubuntu
[16:40:52] <SWPadnos> haven't tried burning a DVD yet, though I have ripped one
[16:41:11] <cradek> SWPadnos: I have two CD drives, so maybe that's my problem
[16:41:20] <SWPadnos> could be
[16:41:25] <cradek> SWPadnos: I tried for only about 10 seconds to fix it
[16:41:29] <SWPadnos> only one is a burner, presumably
[16:41:30] <SWPadnos> heh
[16:41:33] <cradek> yes
[16:42:01] <SWPadnos> I do have problems with either k3b or gnomeburner, though I don't recall which at the moment
[16:42:14] <SWPadnos> or whatever the gnome tool is called
[16:50:52] <rayh> cradek: Thanks for the note on sig in halconfig. Got that watch fixed.
[16:51:15] <SWPadnos> did it need fixing after the fix I did?
[16:53:21] <rayh> It was only changing the led for pin and param
[16:53:49] <SWPadnos> right. I moved a '}' and it worked
[16:54:04] <SWPadnos> you had probably already checked out when I checked that in
[16:55:13] <rayh> Okay. I guess I missed that.
[16:55:25] <rayh> I'm seeing now that modify doesn't work at all.
[16:55:35] <SWPadnos> grape rinds think alike
[16:55:38] <SWPadnos> or something like that
[16:55:38] <rayh> Looks like I lost my last version.
[16:55:54] <rayh> dere ya go eh.
[16:56:31] <SWPadnos> I get something that looks right for modify, but I can't see that it does the actual command
[16:57:41] <SWPadnos> is there an easy way to tell if a clicked node is a leaf (has no child nodes)?
[16:57:46] <rayh> Clciking on entries doesn't work
[16:58:15] <SWPadnos> hmmm - can you walk me through what you're doing?
[16:58:21] <rayh> It looks through the list of nodes and if it finds your click it calls you stupid and suggests clicking again.
[16:58:52] <SWPadnos> oops - I was thinking of tune mode, not modify mode
[16:59:09] <rayh> I didn't see your fix in the commit on #emc
[16:59:28] <SWPadnos> CIA-8swpadnos * emc2/tcl/bin/halconfig.tcl: Fix "watch mode" for signals.
[16:59:33] <SWPadnos> at 10:38 my time (EST)
[17:00:10] <SWPadnos> it's only 4 or 5 lines ago, actually
[17:01:14] <rayh> It's in the code.
[17:01:29] <SWPadnos> ok
[17:02:56] <rayh> I'm kinda up sxxt creek here. I have to edit halcmd to bin/halcmd
[17:03:11] <rayh> but then if I edit and commit you guys are wrong.
[17:04:09] <cradek> let's continue debugging that then.
[17:04:18] <SWPadnos> can you try adding a line like puts stdout [exec which halcmd]
[17:04:47] <cradek> good idea, that shows the path
[17:04:57] <SWPadnos> or nothing
[17:05:22] <SWPadnos> so maybe puts stdout "Halcmd is [exec which halcmd]"
[17:05:35] <SWPadnos> (+/ some appropriate punctuation)
[17:07:15] <rayh> Error in startup script: child process exited abnormally
[17:07:18] <rayh> while executing
[17:07:18] <rayh> "exec which halcmd"
[17:07:51] <SWPadnos> but the path echo still showed emc2/bin, right?
[17:08:00] <cradek> he never did a path echo in halcmd
[17:08:08] <cradek> err halconfig
[17:08:24] <SWPadnos> ah
[17:08:56] <rayh> I don't see what the "which" is attempting to do.
[17:09:09] <cradek> I don't think which is even in your path
[17:09:16] <SWPadnos> tell us what will get executed if you run halcmd
[17:09:31] <SWPadnos> which probably is, but it may return an error (and print nothing) if the program isn't found
[17:09:32] <cradek> stick that same puts (like we put in tkemc) into halconfig please
[17:09:35] <rayh> an error message.
[17:10:08] <rayh> Error in startup script: child process exited abnormally
[17:10:08] <rayh> while executing
[17:10:08] <rayh> "exec which halcmd"
[17:10:13] <SWPadnos> these two lines in halconfig:
[17:10:15] <SWPadnos> puts stdout "halconfig: PATH is $env(PATH)"
[17:10:16] <SWPadnos> puts stdout "halconfig: halcmd is [exec which halcmd]"
[17:10:22] <rayh> I'm a bit lost here now.
[17:10:31] <SWPadnos> give me this output:
[17:10:33] <SWPadnos> halconfig: PATH is /Project/emc2/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
[17:10:35] <SWPadnos> halconfig: halcmd is /Project/emc2/bin/halcmd
[17:10:43] <rayh> I can not start halconfig
[17:11:05] <cradek> I'm lost too then
[17:11:15] <SWPadnos> is halconfig not found, or does it exit because it can't find halcmd?
[17:11:52] <rayh> How would you like me to attempt to start halconfig?
[17:12:01] <cradek> from the tkemc menu
[17:12:07] <rayh> from tkemc or from a terminal?
[17:12:15] <SWPadnos> ok - that's the problem. you can't run halconfig from the command line
[17:12:21] <cradek> we're trying to figure out what happens to your PATH in the emc->tkemc->halconfig chain
[17:12:33] <SWPadnos> it has to be run with the environment that scripts/emc sets up
[17:12:39] <cradek> you haven't been running it from the menu?
[17:13:10] <rayh> That time it started.
[17:13:10] <SWPadnos> right - I get the same problem when run from the terminal
[17:13:11] <SWPadnos> localhost:/Project/emc2# tcl/bin/halconfig.tcl
[17:13:12] <SWPadnos> halconfig: PATH is /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
[17:13:14] <SWPadnos> Error in startup script: child process exited abnormally
[17:13:15] <SWPadnos> while executing
[17:13:17] <SWPadnos> "exec which halcmd"
[17:13:18] <SWPadnos> invoked from within
[17:13:20] <SWPadnos> "puts stdout "halconfig: halcmd is [exec which halcmd]""
[17:13:21] <SWPadnos> (file "tcl/bin/halconfig.tcl" line 25)
[17:13:36] <rayh> Hell no I don't start it from emc. I want to see what it does.
[17:13:58] <SWPadnos> heh - well, I think we know what the problem is now :)
[17:14:01] <rayh> Shit Halconfig is supposed to be much bigger than a tool under a single menu in
[17:14:06] <cradek> oh for fucks sake
[17:14:14] <rayh> It didn't start a bit ago from that same menu
[17:14:36] <SWPadnos> the changes to make it work from the menu fubared it for plain old shell execution
[17:14:48] <rayh> What we are saying is that halconfig now needs something from tkemc
[17:15:09] <SWPadnos> more accurately, from scripts/emc
[17:15:23] <rayh> Could it get that as easily from setupconig.tcl
[17:15:31] <rayh> I could live with starting it from there.
[17:15:49] <SWPadnos> we'll have to add some checks for the env vars, and default to bin/halcmd if not found
[17:16:12] <rayh> But that won't work on an installed system.
[17:16:39] <rayh> Oh and setupconfig also strips all the return info.
[17:17:15] <SWPadnos> would you expect someone to just run halconfig on an installed system, not from within emc?
[17:17:18] <cradek> rayh: just set your PATH if you want to run it from the shell. Alex's change works perfectly.
[17:17:27] <cradek> SWPadnos: I wouldn't.
[17:17:57] <cradek> rayh: env PATH=$PATH:./bin tcl/bin/halconfig.tcl
[17:18:09] <rayh> Not meaning to be a mule here but that doesn't help end users.
[17:18:27] <cradek> end users will run it from the menu.
[17:18:32] <rayh> bs
[17:18:36] <SWPadnos> do you think that end users with installed systems will need to run halconfig from the shell?
[17:18:52] <rayh> not if they are building a HAL the way jmk told elson to do last sunday.
[17:19:12] <rayh> coffee brb
[17:19:16] <cradek> elson is a developer
[17:19:26] <SWPadnos> actually, they might - it seems reasonable to run emc from an icon, then run halconfig from either another icon, or a separate terminal
[17:19:27] <cradek> I thought you were writing halconfig for users to use, so they don't have to do that
[17:19:59] <cradek> more coffee is a good idea (I'll get decaf)
[17:20:15] <SWPadnos> eeewwww - decaf
[17:20:39] <cradek> it's not as good but I don't have to worry about drinking 9 cups of it
[17:20:51] <rayh> hehe
[17:21:00] <SWPadnos> dddrrriinnnkkiinngg ccooffffeeeee
[17:21:10] <cradek> you think I'm pissy now
[17:21:14] <SWPadnos> heh
[17:21:42] <rayh> I guess we do need some additional discussion of how the parts fit together
[17:22:25] <SWPadnos> yep
[17:22:25] <rayh> If halconfig is run from tkemc or mini then I don't need any of the testing stuff at the start.
[17:22:37] <SWPadnos> (or axis hint hint)
[17:22:52] <rayh> and eric would never have gotten the message he reported this morning.
[17:23:14] <SWPadnos> which- the BWidget thing?
[17:23:24] <rayh> I guess bwidget test would be there yet.
[17:23:33] <alex_joni> * alex_joni is back
[17:23:34] <rayh> but no winders
[17:23:42] <rayh> no is rtai up
[17:23:57] <rayh> or is hal running
[17:24:22] <cradek> rayh: if he had used my debian packages, bwidget would already have been installed as a dependency.
[17:24:23] <rayh> That last one got broke with some of the changes to setupconfig recently anyway.
[17:24:42] <rayh> Right but I think he has a fedora or some such hat.
[17:25:51] <rayh> so first question, where does halconfig fit, if it fits.
[17:28:40] <SWPadnos> I don't think it's useful for end users unless there's a running emc/HAL
[17:29:03] <SWPadnos> I think it is useful to be able to run it "manually" - ie, not only from an emc GUI menu
[17:32:34] <alex_joni> SWPadnos: so what's stoping you?
[17:32:43] <rayh> and the easy way to accomplish both is to tell the guy who wants to run it manually to edit his path var.
[17:33:11] <alex_joni> that's automatically done for installed systems, as halcmd is already in /usr/bin
[17:33:23] <alex_joni> or similar (/usr/local/bin)
[17:33:41] <SWPadnos> ok - so it should only be a developer using run-in-place that has any issues
[17:33:49] <alex_joni> for the run-in-place system it's hard to put ./bin permanently to PATH, and that might be problematic
[17:34:03] <alex_joni> SWPadnos: right, if he's not running it from tkemc
[17:34:17] <alex_joni> or for what I care using loadusr from hal
[17:34:34] <alex_joni> just like we run halscope for sim
[17:35:36] <SWPadnos> ok, so the danger is if there's an installed version, and you're doing development - that'll prefer the installed version over the RIP version, when run from the shell
[17:36:12] <alex_joni> yes, but an installed halcmd should work just fine with a run-in-place rest
[17:36:32] <SWPadnos> depends on what's changing
[17:36:35] <alex_joni> except when you do serious redesign on halcmd
[17:36:40] <SWPadnos> but most likely true
[17:37:10] <SWPadnos> actually, a single change to the HAL data would screw up an installed halcmd
[17:37:43] <SWPadnos> s/would/could/
[17:39:09] <rayh> SWPadnos: Could you explain that last a bit?
[17:42:24] <alex_joni> rayh: if you have 2 parts of a software using the same data defines
[17:42:34] <alex_joni> and you have one part linked and installed
[17:42:35] <SWPadnos> well - if the HAL data changes, for instance we add a new variable to the pin struct (like a unique ID), then an installed halcmd wouldn't know about it, and things would get messy
[17:43:09] <alex_joni> and afterwards you change the data definitions (only slightly is enough), and compile the second part of the software, those two will never work 100% ok together
[17:43:17] <rayh> I thought halcmd querried a running hal.
[17:43:27] <alex_joni> yes, using some predefined commands
[17:43:32] <alex_joni> that go through shm
[17:43:49] <SWPadnos> it does, but it looks at the HAL structures directly - the definitions have to match betwen halcmd and the running HAL
[17:44:10] <alex_joni> but if jmk decides he should add another command, and that command shifts half of the existing with 1 step, then querying for pin might get you param
[17:44:14] <SWPadnos> if you have a run-in-place version with different structures, and you end up running an installed halcmd, boom!
[17:44:14] <rayh> But it does not behave the same in the installed version as it does in rip.
[17:44:16] <alex_joni> or something lots worse
[17:44:29] <alex_joni> it's not a matter of behave
[17:44:39] <alex_joni> it's a matter of data consistency
[17:44:57] <SWPadnos> command parsing isn't an issue, unless the meaning of a comand changes (like PIN now means PARAM)
[17:45:03] <rayh> In my rip, I can start demo or realtime and add stuff.
[17:45:28] <rayh> start new modules, delete and change old modules
[17:45:29] <alex_joni> what are demo and realtime?
[17:45:36] <rayh> scripts
[17:45:37] <SWPadnos> I was thinking ahead to the person (possibly a developer) who has an installed version, and is testing a new vbersion of emc2
[17:45:59] <alex_joni> rayh: ok
[17:46:14] <SWPadnos> if they run from a shell instead of a menu, then the installed halcmd will be in the path, so even if you check inside halconfig for a valid hapcmd, you may end up finding the wrong one
[17:46:19] <alex_joni> anything you do in rip, works for the installed system just the same
[17:46:40] <SWPadnos> but anything in the installed system may not work the same in rip, due to path issues
[17:46:49] <alex_joni> SWPadnos: that can be overcome, but testing for a file in path is very messy in tcl
[17:47:06] <alex_joni> SWPadnos: how do you mean that?
[17:47:19] <SWPadnos> actually, I think you want to test for an env var (like EMC2_something), and use bin/halcmd if the var doesn't exist
[17:47:38] <SWPadnos> but that doesn't work for installed systems - darn
[17:47:48] <alex_joni> why not?
[17:47:58] <SWPadnos> installed components are in the path, so will be sulently used, even if yuo
[17:48:07] <alex_joni> that is how the realtime script gets found
[17:48:09] <SWPadnos> installed components are in the path, so will be sulently used, even if you're trying a new version as RIP
[17:48:12] <SWPadnos> silently
[17:48:23] <alex_joni> they shouldn't
[17:48:33] <alex_joni> c'mon this is not that hard..
[17:48:34] <SWPadnos> if you try to run from the shell ...
[17:48:43] <alex_joni> in that case yes
[17:48:57] <alex_joni> but that's only because halconfig.tcl doesn't know how it's run
[17:49:06] <alex_joni> at least doesn't right now
[17:49:07] <SWPadnos> that's the problem - it's pretty reasonable to expect that you can run halconfig from something other than an emc gui
[17:49:23] <alex_joni> the runscript knows where it's run from (rip or install)
[17:49:35] <SWPadnos> and it's necessary if you use azis, since you can't run halconfig from within axis at the moment
[17:49:46] <SWPadnos> axis - not azis
[17:50:09] <alex_joni> ok, so then we go back and have halconfig run ONLY from emc2/ (no other location is valid)
[17:50:19] <alex_joni> if bin/halcmd is there it uses that
[17:50:30] <alex_joni> otherwise it assumes installed version and checks in path
[17:50:32] <SWPadnos> that's what I'm trying to think through - what's reasonable, and how to accomplish it
[17:51:21] <rayh> If we have issues with the editing that halconfig can do to a running HAL, then we should trash halconfig.
[17:51:39] <alex_joni> how do you mean editing ?
[17:52:02] <rayh> halconfig can loadrt unloadrt
[17:52:09] <alex_joni> right
[17:52:13] <SWPadnos> that's necessary
[17:52:20] <alex_joni> but all those are halcmd calls
[17:52:20] <rayh> which means that it can do most any mod to HAL
[17:52:31] <SWPadnos> I don't think we're talking about what halconfig does, just how to make it possible for it to work in all necessary cases
[17:52:33] <alex_joni> I thought that's what it's supposed to do
[17:52:46] <alex_joni> it's just a matter of finding halcmd (the right halcmd)
[17:53:01] <alex_joni> we're not talking about changing any functionality of halconfig nor halcmd
[17:53:12] <rayh> I don't understand finding the right halcmd?
[17:53:32] <SWPadnos> if I run emc using axis, halconfig isn't available from a menu
[17:53:44] <rayh> Okay
[17:53:44] <SWPadnos> so I run a separate shell for halconfig (like you were doing)
[17:53:45] <alex_joni> rayh: if a user someday will have an installed emc AND a run-in-place version, halconfig might be confused and run the installed halcmd (because it's in PATH)
[17:53:59] <SWPadnos> but it can't find halcmd, because it's expecting it to be in the PATH
[17:54:11] <SWPadnos> which it isn't (thankfully, since I have no installed emc2 on this machine)
[17:54:21] <rayh> halconfig works on a "running" hal
[17:54:29] <SWPadnos> exactly
[17:54:37] <rayh> so it matters not where it exists or is run from
[17:54:39] <alex_joni> rayh: sure but to work on a running hal it needs to talk to halcmd
[17:54:59] <alex_joni> if halconfig.tcl can't execute halcmd.. it won't matter if HAL is running or not
[17:55:08] <alex_joni> agreed?
[17:55:39] <rayh> true. but I don't see how a halcmd in /bin or /sbin or wherever makes any difference between halcmd and HAL.
[17:55:40] <SWPadnos> and it has to be the correct one - either "bin/halcmd", or halcmd from the path
[17:55:51] <rayh> only that halconfig doesn't know where to find it.
[17:55:52] <SWPadnos> if you checkout a new version of emc2
[17:55:55] <alex_joni> rayh: let's step back a bit
[17:56:04] <alex_joni> SWPadnos: let me try to exaplain for a while
[17:56:13] <SWPadnos> ok
[17:56:33] <rayh> * rayh falls silent
[17:56:49] <alex_joni> rayh: I'm trying to build a scenario, try to say if you don't follow me
[17:56:59] <alex_joni> 1. user gets ubuntu with emc2 deb packages
[17:57:12] <alex_joni> halcmd is installed in /usr/bin
[17:57:25] <alex_joni> halconfig.tcl is in /usr/share/emc/tcl/halconfig.tcl
[17:57:42] <alex_joni> user starts tkemc -> runs halconfig from the menu (works OK)
[17:57:57] <alex_joni> user start axis -> runs halconfig from the shell (works OK)
[17:58:06] <alex_joni> so far everything is as it should be
[17:58:08] <rayh> ??
[17:58:22] <SWPadnos> installed system, not run in place
[17:58:40] <rayh> but how does a users start halconfig.
[17:58:41] <alex_joni> rayh: something not clear?
[17:59:13] <rayh> terminal and enter sudo /usr/share/emc/tcl/halconfig.tcl
[17:59:16] <rayh> ??
[17:59:22] <alex_joni> without sudo
[17:59:24] <alex_joni> but yes
[17:59:53] <alex_joni> or he might even have an icon on his desktop that's reading halconfig for what he cares
[17:59:55] <rayh> no sudo because halcmd has setuid root
[18:00:01] <alex_joni> exactly
[18:00:42] <alex_joni> is it ok so far? can I move on?
[18:01:01] <rayh> sure
[18:01:30] <alex_joni> ok, now the user hears about a fancy new improvement in emc2 and wants to try it out, before he installs over his runing emc2
[18:01:49] <alex_joni> so he gets emc2 and puts it in /home/aunt_tillie/emc2/
[18:02:26] <alex_joni> now /home/aunt_tillie/emc2/bin/halcmd and /home/aunt_tillie/emc2/tcl/bin/halconfig.tcl are the ones we care about
[18:03:18] <rayh> why should we care.
[18:03:32] <rayh> unless these two files have changed?
[18:03:35] <alex_joni> when the user start emc (the rip one), and runs halconfig from the tkemc menu, the runscript already added /home/aunt_tillie/emc2/bin to PATH so halconfig.tcl will use /home/aunt_tillie/emc2/bin/halcmd
[18:03:45] <alex_joni> exactly that is the case we worry about
[18:04:11] <alex_joni> if the user has emc2.0.0 installed, but tries emc2.3.5 out (say 2 years newer)
[18:04:36] <alex_joni> halcmd & HAL is very likely to have changed in the meantime.. agreed?
[18:04:53] <rayh> okay
[18:05:11] <alex_joni> so if you run in place, it's absolute MUST that you use only run-in-place files
[18:05:35] <alex_joni> it's a bad idea to end up running HAL from rip, and halcmd from the installed (2 years older) emc2
[18:05:37] <rayh> so why not pid in tcl
[18:05:44] <alex_joni> pid?
[18:05:51] <rayh> pwd
[18:06:19] <alex_joni> well.. my main problem is that I know too little tcl to do that properly
[18:06:49] <alex_joni> but running `pwd`/bin/halcmd from tcl is not the answer
[18:07:02] <rayh> In a run in place system, tcl/bin and bin/ are the essential locations?
[18:07:14] <alex_joni> yes
[18:07:26] <rayh> is pwd emc2?
[18:07:30] <alex_joni> somehow, also scripts/realtime is used
[18:07:32] <SWPadnos> the pwd is the config dir
[18:07:32] <rayh> or is it scripts
[18:07:39] <alex_joni> pwd is where you run it from
[18:07:47] <SWPadnos> not in halconfig
[18:07:51] <rayh> In emc pwd was always emc
[18:07:57] <alex_joni> the emc runscript can be run from anywhere it shouldn't matter
[18:08:12] <SWPadnos> adding 'puts stdout "halconfig: Working Directory is [exec pwd]" ' to halconfig
[18:08:25] <SWPadnos> gives this: "halconfig: Working Directory is /Project/emc2/configs/SWP_ppmc"
[18:08:26] <alex_joni> you can run scripts/emc OR cd scripts && ./emc OR cd src && ../scripts/emc , etc
[18:08:41] <SWPadnos> run from tkemc
[18:08:42] <alex_joni> SWPadnos: if you run it from the GUI
[18:08:43] <rayh> And IMO you shouldn't be able to do that.
[18:09:04] <alex_joni> rayh: how do you expect to keep track of the installed version then?
[18:09:26] <rayh> * rayh doesn't want to keep track of installed...
[18:09:29] <alex_joni> there is no emc2/ anymore
[18:09:34] <rayh> excuse me for saying that.
[18:09:42] <alex_joni> yes I know you don't ;) but users want that
[18:09:56] <rayh> users want a machine to start up and work;
[18:10:06] <rayh> but another day for that.
[18:10:07] <alex_joni> rayh: you're forgiven, it's not the most pleasant thing to debug
[18:10:23] <SWPadnos> users want the nifty ubuntu "updates available" icon to tell them when there's a new version of emc2 as well
[18:10:36] <rayh> In a rip. is it possible to make a "run from here" directory.
[18:10:36] <alex_joni> agreed to both of you
[18:10:44] <SWPadnos> and that happens automagically with installed debs
[18:10:53] <alex_joni> rayh: you shouldn't need that
[18:11:03] <alex_joni> you can still go to emc2/ and run from there
[18:11:04] <rayh> Not the two users that ripped me a new one on the phone about ubuntu.
[18:11:12] <alex_joni> ripped?
[18:11:25] <SWPadnos> complained aggressively ;)
[18:11:25] <rayh> That doesn't satsify my need.
[18:11:31] <alex_joni> how so?
[18:12:22] <SWPadnos> what are your needs?
[18:12:26] <rayh> Is it possible to say in a rip, "you will always run from emc2
[18:12:43] <alex_joni> you can say that
[18:12:49] <rayh> so that we always have a known file system relationship.
[18:13:44] <rayh> I take that as a no... not possible.
[18:13:55] <alex_joni> the file system relationship
[18:14:04] <alex_joni> is already well known
[18:14:32] <alex_joni> but when adding install support we changed the default location to run everything from
[18:14:59] <alex_joni> the config dir is now the place where stuff gets run from (because of a lot of reasons)
[18:15:15] <alex_joni> so the runscript goes there first, then does it's thing
[18:15:27] <alex_joni> so it actually doesn't matter where you run it from
[18:15:47] <alex_joni> but the runscript posesses the knowledge you were talking about "the known file system relationship"
[18:16:07] <rayh> It does if I'm trying to find halcmd or trying to figure out where to put the saved version of HAL.
[18:16:26] <alex_joni> where would you put the saved version of HAL?
[18:17:15] <alex_joni> IMO the best place would be in the config dir for the current setup
[18:17:15] <alex_joni> up
[18:18:42] <rayh> I just save without worry about where.
[18:18:53] <alex_joni> say I'm running the univpwm config, if I start halconfig and want to edit soemthing then I expect halconfig to save in configs/univpwm not anywhere else
[18:18:56] <rayh> so my only problem is where is halcmd?
[18:19:24] <alex_joni> rayh: we coudl do it like this: the rip user MUST run from emc2/
[18:19:34] <alex_joni> then halconfig looks for bin/halcmd
[18:19:39] <rayh> small issue with a start from scratch hal but go ahead.
[18:19:56] <alex_joni> if it's not found then it looks in path, and assumes installed version
[18:20:45] <alex_joni> does tcl have a way to know from where halconfig was run?
[18:21:02] <alex_joni> saying you are in /home/ray/emc2 and run tcl/bin/halconfig.tcl
[18:21:17] <rayh> pwd
[18:21:25] <alex_joni> does halconfig have a way to find out /home/ray/emc2/tcl/bin/halconfig.tcl ?
[18:21:30] <rayh> will return the current directory
[18:21:40] <alex_joni> pwd + $0
[18:21:59] <alex_joni> $0 is usually the complete executed name
[18:22:16] <alex_joni> at least that's true for bash scripts, and executables (binaries)
[18:22:38] <SWPadnos> $0 doesn't exist in tcl
[18:22:42] <SWPadnos> (I tried it)
[18:23:01] <alex_joni> in tcl no, but there is a bash that runs before wish gets called
[18:23:04] <alex_joni> we can use that
[18:23:24] <SWPadnos> I thikn $0 in bash is the actual name used to run the command, without the path
[18:23:35] <SWPadnos> unless the full path was typed at the command line
[18:23:36] <alex_joni> it's the whole name
[18:23:39] <rayh> exec /usr/bin/wish "$0" "$@"
[18:23:47] <rayh> Is the default way of starting wish
[18:24:14] <alex_joni> yes I know ray
[18:24:23] <alex_joni> but before that we can do any number of bach lines
[18:24:26] <alex_joni> bash even
[18:24:39] <alex_joni> SWPadnos: this is what I put in emc:
[18:24:42] <alex_joni> # 1.3.1. Determine if we have run-in place or installed system
[18:24:42] <alex_joni> # by looking of where the script was run from
[18:24:42] <alex_joni> SCRIPT=`which $0 | grep $0`
[18:24:42] <alex_joni> echo "SCRIPT=$SCRIPT" >>$PRINT_FILE
[18:24:42] <alex_joni> #get the script name
[18:24:44] <alex_joni> SCRIPTNAME=`echo $SCRIPT | sed s#\^.\*/##`
[18:24:47] <alex_joni> #and the path
[18:24:49] <alex_joni> echo "SCRIPTNAME=$SCRIPTNAME" >>$PRINT_FILE
[18:24:52] <alex_joni> SCRIPTDIR=$(dirname $SCRIPT)
[18:24:55] <alex_joni> SCRIPTDIR=$(cd $SCRIPTDIR ; pwd -P)
[18:24:57] <alex_joni> echo $SCRIPTDIR >>$PRINT_FILE
[18:26:19] <alex_joni> the idea is this: get the bash on top of halconfig.tcl figure out if it's installed or rip, and set an ENV accordingly
[18:26:38] <alex_joni> inside tcl (wish), you can read that ENV and use paths accordingly
[18:27:02] <SWPadnos> ok
[18:27:34] <alex_joni> does that sound ok?
[18:28:01] <SWPadnos> it may - I'm no shell guru)
[18:28:17] <alex_joni> cradek is ;)
[18:28:58] <rayh> * rayh realizes his old ways don't fit in this world.
[18:29:52] <alex_joni> rayh: the problem is we are trying to make it perfect
[18:29:54] <alex_joni> ;-)
[18:30:23] <alex_joni> and that complicates things a bit
[18:31:48] <alex_joni> so it's rather a let's think of all the scenarios that might appear in the future, rather than make it just work and move on, and worry later
[18:32:02] <rayh> okay. I guess I'll just have to wait for a solution that is way beyond my ability.
[18:32:24] <rayh> What I have been doing is starting an emc2
[18:32:28] <alex_joni> you'll see it's not a very complicated one..
[18:33:02] <rayh> then from the same directory pointing to tcl/bin/halconfig or setupconfig and working from a terminal]
[18:33:14] <rayh> That way I can see what errors tcl kicks up.
[18:33:32] <rayh> Now if I try to do this with setupconfig, it doesn't start right
[18:33:53] <rayh> if I start setupconfig from scripts/emc
[18:34:12] <rayh> I don't get any error messages from tickle
[18:34:12] <alex_joni> if you run from tkemc, the errors end up on the same terminal from where you started
[18:34:27] <alex_joni> start a terminal, go to emc2/
[18:34:31] <alex_joni> run scripts/emc
[18:34:54] <alex_joni> select a config with tkemc (stepper for example), then run halconfig from the menu
[18:35:11] <rayh> Nope cause the run scripts strips em all.
[18:35:11] <alex_joni> you'll see halconfig error messages along with normal emc debug
[18:35:21] <rayh> nothing here.
[18:35:40] <alex_joni> what messages do you usually get?
[18:35:49] <rayh> The only thing scripts/emc wants to see is the name of the ini to execute.
[18:36:22] <alex_joni> are we still talking about halconfig?
[18:37:10] <rayh> I think so. It was a few days ago when I found that problem.
[18:37:53] <alex_joni> halconfig != setupconfig
[18:38:59] <rayh> Right but interrelated them a while back.
[18:39:28] <alex_joni> oh ok, I got confused
[18:39:52] <rayh> np. you have not got near the confusion that I have now.
[18:40:08] <alex_joni> it is true that scripts/emc doesn't expect setupconfig to return anything but the config name
[18:41:54] <rayh> I don't see any easy way from within halconfig, to say I'm rip or I'm installed.
[18:42:08] <rayh> Unless there were a standard place from which installed started.
[18:42:35] <alex_joni> well the point of make install is not to make it standard
[18:42:38] <SWPadnos> or a standard place where you can find the version of emc that's running (like /var/emc)
[18:42:47] <alex_joni> because different distro's have different policies
[18:43:00] <alex_joni> what is mandatory on debian is NOT allowed on redhat, and so on
[18:43:02] <SWPadnos> containing something like /usr/emc or /home/rayh/emc2
[18:43:05] <rayh> Right. So I'm completely lost as to how to help.
[18:43:25] <alex_joni> rayh: wait 30 mins, I'll boot my ubuntu up, and you can help with tcl stuff.. ok?
[18:43:58] <rayh> I can try.
[18:44:04] <alex_joni> thx
[18:44:31] <rayh> Thank you.
[18:44:51] <alex_joni> 2 minutes
[18:45:05] <SWPadnos> that was a quick 28 minutes ;)
[18:45:11] <rayh> * rayh must get out of the emc business.
[18:45:21] <rayh> rayh is now known as rayh-away
[18:45:23] <SWPadnos> or get much better pay :)
[18:47:49] <alex_joni> * alex_joni is back on ubuntu
[18:51:06] <rayh-away> rayh-away is now known as rayh
[18:52:11] <alex_joni> ok, started to look at it
[18:52:46] <alex_joni> rayh: can you start thinking about how to handle the 2 variants if you have an ENV saying rip or install?
[18:53:45] <alex_joni> not much different just to run bin/halcmd vs. halcmd
[18:53:47] <rayh> The installed is handled. exec halcmd does that.
[18:54:22] <SWPadnos> can you just make an env var HALCMD, that has either 'bin/halcmd' or 'halcmd'?
[18:54:32] <alex_joni> SWPadnos: or better absolute path
[18:54:38] <SWPadnos> sure
[18:54:39] <alex_joni> yes
[18:54:42] <rayh> if {$rip = "rip"} {exec bin/halcmd}
[18:54:53] <alex_joni> ray: exec $HALCMD
[18:55:01] <SWPadnos> just replace all the exec hal;cmd with exec $HALCMD
[18:55:09] <SWPadnos> what he said
[18:55:26] <SWPadnos> set HALCMD $env(HALCMD)
[18:55:59] <alex_joni> SWPadnos: I can take care of that much tcl
[18:56:03] <SWPadnos> heh
[18:56:09] <alex_joni> rayh: give me a few minutes for testing, and I'll commit
[18:56:40] <rayh> k
[18:57:02] <SWPadnos> ray - do you get the messages like "inifind is depreciated" and the like?
[18:57:18] <rayh> sometimes I do.
[18:57:20] <alex_joni> yeah, that's paul's message
[18:57:34] <alex_joni> there are 2 versions of iniFind
[18:57:58] <alex_joni> one c++ (is ok), one c (linked from halcmd) which supposedly is depreciated
[18:58:01] <SWPadnos> it should be there every time - I was just thinking about you mentioning that you get no messages (from halconfig) in the terminal
[18:58:09] <SWPadnos> deprecated, but anyway ;)
[18:58:18] <alex_joni> but the main problem with it is that it's linked to halcmd :))
[19:01:13] <rayh> I seem to have both tkemc and halconfig twisted up. I'll reinstall.
[19:05:29] <rayh> oops I see a change to make. If I go away it's cause it crashed.
[19:05:43] <alex_joni> rayh: btw, I'm getting errors that killHalConfig doesn't exist
[19:06:29] <rayh> make: [clean] Error 1 (ignored)
[19:09:35] <alex_joni> rayh: that isn't a very usefull message
[19:09:41] <alex_joni> try a few more lines bfore that
[19:10:34] <rayh> Sorry long gone now.
[19:10:49] <rayh> It was in the midst of rm -f
[19:11:07] <rayh> The new does start up okay.
[19:15:11] <rayh> killHalConfig should be about line 259.
[19:15:42] <alex_joni> way after initializeConfig (at line 181)
[19:16:14] <alex_joni> but initializeConfig calls killHalConfig in case user presses Cancel at the question if he wants to start HAL
[19:20:22] <rayh> Shouldnt be a problem because initializeConfig isn't called until very late in the program.
[19:20:41] <alex_joni> it's the first called if I'm reading this correctly
[19:20:43] <rayh> Don't know why your's should raise an error. there.
[19:20:43] <alex_joni> line 181
[19:21:52] <rayh> here 181 is in the midst of comment.
[19:22:11] <alex_joni> #run the init test process
[19:22:17] <alex_joni> initializeConfig
[19:22:19] <alex_joni> #
[19:22:31] <alex_joni> #---------------end of environment tests -------------
[19:22:33] <rayh> I see 151 being a call to killHalConfig
[19:24:08] <rayh> Are you getting the error if the initializeConfig script fails to find a working system?
[19:24:53] <alex_joni> yes
[19:25:01] <alex_joni> I get a window with 3 buttons
[19:25:08] <alex_joni> if I push cancel I get an error
[19:25:38] <alex_joni> HAL is not loaded, Yes, No, Cancel
[19:25:42] <rayh> Okay. Let me move that call to initializeConfig.
[19:26:09] <alex_joni> wait on the commit, I'll be modifyin the whole file
[19:26:46] <rayh> k
[19:27:46] <rayh> phone
[19:36:02] <rayh> back
[19:36:25] <rayh> I'll wait for your commit before I do anything more with it.
[19:45:49] <alex_joni> rayh: I commited, you can change the initConfig stuff now, if you like
[19:45:59] <alex_joni> I'm still pondering if it's the final version though
[19:48:18] <rayh> My submissions never are final, why should we expect your's to be?
[19:52:42] <rayh> got that make clean error message.
[19:52:46] <rayh> make[1]: Leaving directory `/home/rayh/emcdevelop/emc2/src/emc'
[19:52:46] <rayh> find . -name "*~" -exec rm -f {} \;
[19:52:46] <rayh> find . -name "*.bak" -exec rm -f {} \;
[19:52:47] <rayh> find . -name core -exec rm -f {} \;
[19:52:49] <rayh> rm -f ../include/* ../lib/* ../rtlib/* ../bin/* 2>/dev/null
[19:52:51] <rayh> make: [clean] Error 1 (ignored)
[19:52:53] <rayh> rm -f .tmp/* .rt_tmp/*
[19:52:59] <alex_joni> that's OK
[19:53:09] <alex_joni> it's trying to remove the include/CVS dir
[19:53:13] <alex_joni> which is not a file
[19:53:23] <rayh> ah okay.
[19:53:36] <rayh> That shouldn't show up in released source.
[19:53:51] <alex_joni> no, it proabbly won't
[19:57:26] <rayh> Works good. Thanks.
[20:13:46] <alex_joni> rayh: I just ripped it all out.. it was an unnecessary complication :)
[20:18:51] <rayh> Ah that's why. Im getting really confused now.
[20:19:21] <rayh> 1.22 is the latest working version?
[20:19:22] <alex_joni> some foo is still in there :)
[20:19:34] <alex_joni> yes, 1.22
[20:39:19] <alex_joni> rayh: any problems on the latest version?
[20:52:53] <alex_joni> bye guys, I'm off to bed
[20:53:25] <rayh> None that I can see. Thanks
[20:53:31] <rayh> catch you tomorrow.