Back
[01:15:30] <rayh> Can I take it that we do not want to display configs/common as a possible configuration to copy?
[01:31:05] <SWPadnos_> rayh: yes, I suppose you could :)
[01:37:26] <rayh> okay. I'll have this in a few.
[01:37:46] <SWPadnos_> actually - I think you can safely leave out any dir that has no *.ini in it
[01:37:50] <rayh> The assumption is that it will be run from emc2 directory.
[01:38:14] <SWPadnos_> that's good enough for now - we can change it if necessary
[01:38:32] <rayh> k
[01:39:16] <rayh> What will the run command look like say for example for sim?
[01:39:50] <SWPadnos_> you mean how this script will be invoked if the ini isn't found?
[01:41:53] <rayh> No Right now I assume that this script will be invoked with tcl/bin/setupconfig.tcl
[01:42:16] <SWPadnos_> oh - so what does the user type to run the sim config?
[01:42:22] <rayh> What I was thinking was if I make a set of files say raymill
[01:42:35] <SWPadnos_> 'emc raymill'
[01:42:35] <rayh> how will I invoke emc2 to run raymill.
[01:42:56] <SWPadnos_> or './emc raymill'
[01:43:06] <SWPadnos_> I'm not sure where the emc cscript will live - I'm just building now
[01:44:17] <SWPadnos_> hmmm - now why would you make things easy for the user by shortening the name emc.run to just "emc", but still put it in the scripts dir?
[01:44:25] <SWPadnos_> (not you, I mean "someone")
[01:45:19] <SWPadnos_> heh - mini is a bit scary at 3000x1000 pixels
[01:46:38] <rayh> I guess it would be. Suppose I shoulda given max values
[01:46:45] <SWPadnos_> heh
[01:46:48] <rayh> not to exceed
[01:47:01] <SWPadnos_> just funny to see it stretcched across most of two 1920x1200 monitors ;)
[01:47:20] <SWPadnos_> not so mini anymore
[01:47:55] <rayh> Would be easy to use as a touch display.
[01:48:03] <rayh> hard to miss each button.
[01:48:14] <SWPadnos_> yep - full screen makes a lot of sense for a dedicated control
[01:48:36] <rayh> jmk didn't like the autosize much!
[01:48:40] <SWPadnos_> and making it full screen regardless of monitor upgrades is even better
[01:48:55] <rayh> I think I went 80%
[01:48:58] <SWPadnos_> I like it, but an aspect ratio limit might be in order
[01:50:10] <SWPadnos_> hmmm - no univstep or univpwm configs yet
[01:50:47] <SWPadnos_> by the way, univstep and univpwm will be the new names for ppmc, since the setup is different for the two boards
[01:55:10] <rayh> okay. I'da prefered the names used as stickers on the cards usc and upc
[01:55:35] <SWPadnos_> that may work - the dirs haven't been committed yet, AFAIK
[01:56:12] <SWPadnos_> though Jon does call them the universal stepper and universal PWM controllers (and refers to them on his websire as univpwm and univstep)
[01:56:36] <rayh> Yea no problem.
[01:57:30] <rayh> looks like the first draft of the copy script is in there.
[01:57:52] <SWPadnos_> I don't see that - running "emc" just got me sim
[01:57:53] <rayh> crude and doesn't actually copy the files but at least we can see it.\
[01:59:08] <rayh> Gotta eat brb
[01:59:16] <rayh> rayh is now known as rayh_away
[01:59:16] <SWPadnos_> see ya
[02:04:53] <SWPadnos_> duh - *your* script - duh
[02:04:57] <SWPadnos_> * SWPadnos_ slaps self
[02:20:26] <SWPadnos_> hmm - one thing I didn't fix, (because I don't know how) - names can't contain periods, or tcl barfs trying to add the radio button
[02:35:40] <jmkasunich> hey ray!
[02:44:32] <jmkasunich> dang! he is hiding
[02:46:20] <SWPadnos_> eating, I think
[02:47:20] <jmkasunich> I started a similar tcl wizard
[02:47:36] <jmkasunich> I like mine better ;-)
[02:47:44] <SWPadnos_> heh - of course ;)
[02:48:45] <SWPadnos_> so - I was looking at sim_rtapi, and came up with a couple of questions
[02:49:11] <jmkasunich> it doesn't work (you know that already I assume)
[02:49:21] <SWPadnos_> yeah - that's why I was looking at it
[02:50:07] <jmkasunich> ok
[02:50:13] <SWPadnos_> I guess I don't see how it could work, considering that it's suppsed to be linked with kernel modules
[02:50:36] <SWPadnos_> it looked like there were some no-no functions in there
[02:51:08] <jmkasunich> that lib is like hal_lib, gets compiled twice, once for kernel, once for user
[02:51:29] <jmkasunich> are you sure the no-nos weren't wrapped in i#fdef ULAPI
[02:51:43] <SWPadnos_> isn't that what the two versions are for? (sim_rtapi and sim_ulapi)?
[02:51:51] <jmkasunich> in theory, the sim could do everything except threads
[02:52:00] <jmkasunich> oh, you're right
[02:52:04] <SWPadnos_> even those, on kernel 2.6 (kernel threads
[02:52:06] <jmkasunich> sorry, its been a while
[02:52:11] <SWPadnos_> heh - no problem
[02:52:25] <jmkasunich> and when I wrote that, kernel 2.6 was a gleam in Linus's eye
[02:52:28] <SWPadnos_> right
[02:53:22] <SWPadnos_> I guess all that stuff should still *run*, just not in RT (ie, there should be lists of tasks that run from time to time ...)
[02:53:50] <jmkasunich> yeah, and fast tasks should run more often than slow ones
[02:54:20] <SWPadnos_> yep, though that can eaily be done the same way as RTAI - run slower tasks on multiples of the faster ones
[02:54:23] <SWPadnos_> easily
[02:54:44] <jmkasunich> yeah, I had thoughts of doing that
[02:55:02] <SWPadnos_> to pthreads work in kernel? (I don't think so)
[02:55:36] <jmkasunich> no idea
[02:55:44] <SWPadnos_> ok
[02:56:08] <SWPadnos_> I'll look around. I was just confused by calls to what (I think) are userspace funcs in kernel code
[02:59:25] <jmkasunich> lemme take a look
[02:59:43] <jmkasunich> which functs?
[02:59:44] <SWPadnos_> don't worry about it, unless you have some free time ;)
[02:59:54] <jmkasunich> too late, I'm curious now
[02:59:58] <jmkasunich> which functs
[02:59:59] <SWPadnos_> oops
[03:00:05] <SWPadnos_> well, it's only 10:00 ;)
[03:00:40] <jmkasunich> which functs ;-)
[03:00:41] <SWPadnos_> well, wrapper calls an unchecked pointer - that's a bad plan
[03:00:54] <SWPadnos_> rtapi_task_start uses pthreads
[03:01:06] <SWPadnos_> same for stop (obviously)
[03:01:24] <SWPadnos_> rtapi_awit also
[03:01:28] <jmkasunich> ok, anything related to tasks was completely unknown and experimenta
[03:01:31] <jmkasunich> l
[03:01:44] <SWPadnos_> yep, also the shmem function - I'm not sure if that's there without RTAI
[03:01:56] <SWPadnos_> rtapi_shmem_new
[03:02:23] <SWPadnos_> pretty much everything else returns "unsupported"
[03:03:25] <SWPadnos_> with emc1, compiling sim made an entirely userspace set of apps, right?
[03:03:35] <jmkasunich> I think so
[03:03:43] <jmkasunich> that may be what I had in mind here too
[03:03:45] <SWPadnos_> OK - that's why they're using pthreads here
[03:04:00] <SWPadnos_> I on';t think you can, you're depending on the kernel linking modules together
[03:04:04] <SWPadnos_> don't
[03:04:16] <jmkasunich> but coding the modules themselves to compile as user or module would be nasty
[03:04:33] <SWPadnos_> yeah
[03:04:53] <SWPadnos_> also, is this supposed to be a simulator only, or just a non-realtime version of emc?
[03:05:09] <jmkasunich> rtapi is rtapi, it cares not what it is used for
[03:05:17] <jmkasunich> (just like HAL)
[03:05:33] <jmkasunich> it was supposed to be able to run any rtapi app in simulation
[03:05:47] <SWPadnos_> I mean in the context of emc - should the sim mode be functional though non-RT, or just a simulator of the low level code?
[03:05:52] <SWPadnos_> ok
[03:06:01] <jmkasunich> there are two kinds of "sim"
[03:06:04] <SWPadnos_> yep
[03:06:11] <jmkasunich> there is a sim config that replaces hardware
[03:06:16] <jmkasunich> but still requires a RTOS
[03:06:34] <jmkasunich> then there is the "sim" that we are looking at right now, which doesn't need the RTOS
[03:06:42] <jmkasunich> (but in theory could use hardware if you wanted)
[03:06:43] <SWPadnos_> actually, there are two kinds of sim for RTAPI:
[03:07:07] <SWPadnos_> 1) stubs for lots of function calls, so that you can test your program
[03:07:16] <SWPadnos_> 2) something that runs RTAPI, but not in realtime
[03:07:23] <jmkasunich> 1 is pretty useless
[03:07:42] <SWPadnos_> that's mostly what this file is now - I'm not sure how much of that is from the emc1 version
[03:07:46] <jmkasunich> if you call a funct that allocs shmem and its a stub, your program isn't gonna be testable
[03:08:00] <SWPadnos_> true - only the thread and memory functions are implemented, for the most part
[03:08:04] <jmkasunich> nothing in RTAPI is from emc1
[03:08:31] <SWPadnos_> ok - I noticed some comments like "fred returned success, I changed this to unsupported"
[03:08:36] <jmkasunich> fred started it, what he did was a very thin wrapper over the rtos calls
[03:08:44] <SWPadnos_> ok
[03:08:53] <jmkasunich> I added all the checks and reference counts and such
[03:09:15] <jmkasunich> (mostly to reduce the number of oopses and kernel panics that I was experiencing....)
[03:09:23] <SWPadnos_> heh
[03:09:27] <SWPadnos_> always a good plan
[03:10:01] <jmkasunich> it is pretty robust now... assuming you call rtapi_exit(), its hard to leave the system in an unstable state
[03:10:39] <jmkasunich> but the sim never worked, and may well be unworkable period
[03:13:23] <jmkasunich> (when I got it from fred, it was just a work in progress, none of the versions had ever been tested
[03:16:57] <SWPadnos_> sorry -was afk for a mo (heard a crash, figured I'd check on the wife and cat)
[03:17:09] <jmkasunich> which one was it?
[03:17:15] <SWPadnos_> did sim work in emc1?
[03:17:23] <jmkasunich> yes
[03:17:24] <SWPadnos_> the wife - she dropped a windowshade or something
[03:17:32] <jmkasunich> but that was a completley different build
[03:17:36] <SWPadnos_> yep
[03:17:39] <SWPadnos_> all userspace
[03:17:41] <jmkasunich> remember the PLAT crap
[03:17:47] <SWPadnos_> yes - the PLAT crap
[03:17:48] <jmkasunich> and ifdefs galore
[03:18:02] <SWPadnos_> please - I just ate
[03:18:15] <jmkasunich> whats with the late meals today
[03:18:22] <jmkasunich> Ray needs to get back here, dammit!
[03:19:25] <SWPadnos_> what's the big hurry?
[03:19:40] <jmkasunich> I want to talk to him about the config wizard
[03:19:56] <jmkasunich> Now, now, now....
[03:20:02] <SWPadnos_> (also, you should say " rayh_away needs to get back here", so he gets the beep
[03:20:13] <jmkasunich> (IRC makes one impatient... instant gratification...)
[03:20:20] <SWPadnos_> yeah - like credit cards ;)
[03:20:29] <jmkasunich> rayh_away, where are you?
[03:20:40] <jmkasunich> I manage to do OK with those
[03:20:53] <SWPadnos_> apparently cradek has a text mode script as well
[03:21:47] <SWPadnos_> maybe if cradek and rayh_away were here, we could all talk about cradek's and rayh_away's programs
[03:21:55] <SWPadnos_> but cradek and rayh_away aren't here
[03:22:07] <SWPadnos_> so we'll just have to wonder where cradek and rayh_away are, I guess ;)
[03:22:31] <jmkasunich> I think rayh_away uses ksirc, and if its like mine, it doesn't beep
[03:22:38] <SWPadnos_> damn
[03:22:52] <jmkasunich> (of course that might be because my box has no sound card... but it does have speaker)
[03:23:05] <SWPadnos_> hmmm
[03:23:12] <jmkasunich> actually, it has sound on the MB, but no speakers plugged into it
[03:23:26] <SWPadnos_> mine has a sound card and speaker, but no speakers connected to the sound card, so I get very few sounds
[03:23:36] <SWPadnos_> with drivers loaded
[03:23:55] <jmkasunich> I have no idea if there are sound drivers loaded
[03:24:25] <SWPadnos_> I can play mp3's if I plug in the speakers, so I know things are workable here
[03:24:32] <SWPadnos_> and even dvds
[03:24:52] <jmkasunich> seems I never to anything entertaining with my computer
[03:25:06] <SWPadnos_> programming is entertaining ;)
[03:25:09] <jmkasunich> code and talk...
[03:25:19] <jmkasunich> not in tcl it isn't
[03:25:29] <SWPadnos_> no - that's like a horror movie
[03:25:49] <jmkasunich> actually, its quite powerfull, I made up a small GUI thing pretty quickly today
[03:25:58] <jmkasunich> but it can easily get ugly
[03:26:23] <SWPadnos_> yep - it seems pretty easy to get the basics (like perl, python, etc), but the intricacies aren't so forthcoming
[03:26:56] <jmkasunich> talk about intricacies... the text widget has about a thousand options
[03:27:04] <SWPadnos_> huh
[03:27:32] <SWPadnos_> that's the issue with most GUI programming environments - learning the options seems harder than writing your own library
[03:27:41] <jmkasunich> heh
[03:28:48] <jmkasunich> ha - solved that problem...
[03:28:57] <SWPadnos_> which?
[03:28:57] <jmkasunich> (picked the right option)
[03:30:01] <SWPadnos_> the default style for tk widgets is pretty ugly - motif went out of style about 5- years ago
[03:30:22] <jmkasunich> I could care less about style
[03:30:31] <SWPadnos_> well - it's ugly anyway ;)
[03:30:36] <jmkasunich> considering that the alternative is ncurses or worse
[03:30:56] <SWPadnos_> the text isn't even antialiased - how can I work with this?
[03:30:59] <SWPadnos_> :)
[03:31:05] <jmkasunich> :-P
[03:31:26] <SWPadnos_> I see that the univstep and univpwm configs aren't there yet
[03:31:39] <jmkasunich> no, the configs are gonna need some work
[03:32:03] <jmkasunich> in fact I was thinking about a post to the lists warning people that the configs are in a state of flux
[03:32:17] <SWPadnos_> may be a good idea
[03:32:43] <SWPadnos_> I can put the deafult ppmc stuff I have into a univstep directory (renamed, of course)
[03:32:48] <SWPadnos_> default
[03:33:06] <jmkasunich> sure, its better than nothing
[03:33:11] <jmkasunich> put a README in there too
[03:33:29] <jmkasunich> you know: This configuration uses the Pico.....blah, blah
[03:33:31] <SWPadnos_> we should make a document with recommended names for various signal names and ini variables
[03:33:34] <SWPadnos_> yep
[03:33:46] <jmkasunich> (have you tried Rays config tool, it displays the README)
[03:33:55] <SWPadnos_> yes - I even fixed it
[03:34:10] <jmkasunich> mine does too, I was originally using a file called description, but README makes more sense
[03:34:29] <SWPadnos_> the fix I did was so that it only gets directory names
[03:34:45] <jmkasunich> (except that he has no line breaks in his README, so its butt ugly unless you use the tool to view it
[03:34:57] <SWPadnos_> the side effect is that any .ini in the configs/ dir won't be on the menu
[03:35:00] <jmkasunich> mine has a better directory sort
[03:35:13] <jmkasunich> there should be no inis in the config dir, so that is fine
[03:35:26] <jmkasunich> mine looks for directories that contain at least one .ini file
[03:35:30] <SWPadnos_> I figured that was desirable, but put the comment in there anyway
[03:35:37] <jmkasunich> so common is automatically skipped
[03:36:03] <SWPadnos_> that's the next thing, plus you need separate options for xxx_in and xxX_mm
[03:36:12] <jmkasunich> that would be in the next step
[03:36:19] <jmkasunich> first you select the dir, then the file in the dir
[03:36:25] <SWPadnos_> maybe Ray's tree work would be good here
[03:36:47] <SWPadnos_> rather than radio buttons
[03:36:54] <jmkasunich> I'm going more for the install wizard approach, one screen after another, with next/back/quit buttons
[03:37:05] <SWPadnos_> ah - ok.
[03:37:07] <jmkasunich> let me send you mine and take a look
[03:37:10] <SWPadnos_> ok
[03:38:39] <jmkasunich> on the way
[03:38:46] <SWPadnos_> ok. thanks
[03:39:09] <jmkasunich> right now it just has the first screen, the one you would see if you invoked emc with no config specified, and no default set
[03:39:29] <SWPadnos_> ok
[03:39:32] <SWPadnos_> where does it go?
[03:39:46] <jmkasunich> in configs (for now)
[03:39:52] <jmkasunich> and run it from there
[03:39:53] <SWPadnos_> ok
[03:40:13] <jmkasunich> it needs a cd $EMC2_CONFIGS_DIR
[03:40:27] <jmkasunich> but I actually started at work today, on my doze box
[03:40:46] <jmkasunich> so the directory was faked
[03:41:27] <SWPadnos_> ok - I think you need to use $EMC_ORIG_CONFIG_DIR
[03:41:37] <jmkasunich> hmm, that text box needs a scrollbar if the text is too ling
[03:41:40] <jmkasunich> long even
[03:41:52] <jmkasunich> whatever, I didn't know the right variable
[03:42:01] <SWPadnos_> that's configs/, and the $EMC2_CONFIG_DIR is set after a config is chosen
[03:42:04] <SWPadnos_> np
[03:42:15] <jmkasunich> oh, ok
[03:42:26] <jmkasunich> is either of those set before you run emc.run?
[03:42:36] <jmkasunich> (I'm testing this stand-alone)
[03:42:41] <SWPadnos_> from the run script, yes - otherwise no
[03:43:25] <jmkasunich> I don't like that text box...
[03:43:39] <SWPadnos_> gah - I've got to look at how the auto-sizing is done in mini - these fixed size widgets drive me batty
[03:43:39] <jmkasunich> it was designed to allow the user to edit text
[03:43:40] <SWPadnos_> (not just yours)
[03:44:13] <jmkasunich> even tho I disabled the editing, it can still take the mouse focus, and then you can't see which item is selected in the upper box
[03:44:30] <SWPadnos_> yep - you can copy from the text widget, I think
[03:44:37] <jmkasunich> in my original version I used a label widget
[03:44:57] <jmkasunich> but I don't think that does word wrap, so I used a text widget like Ray did
[03:45:00] <SWPadnos_> but no scrollbars available for those, I'd bet
[03:45:17] <jmkasunich> I have a scrollbar for the pick list
[03:45:31] <jmkasunich> (it only shows if there are more than a certain number of choices)
[03:45:56] <jmkasunich> I dunno if one could be hooked to a label or not
[03:45:59] <SWPadnos_> ok -I have more dirs, but apparently only 4 with inis in them
[03:46:05] <jmkasunich> same here
[03:46:28] <jmkasunich> you can change config_listbox_max from 8 to 3 to see the scrollbar
[03:46:46] <SWPadnos_> I'm sure I'll see it some day ;)
[03:47:02] <jmkasunich> heh
[03:47:16] <jmkasunich> I must admit the widgets on my win2K box look nicer
[03:47:31] <SWPadnos_> see! motif does suck ;)
[03:47:51] <SWPadnos_> though it's not strictly motif
[03:47:55] <jmkasunich> I never said it didn't
[03:48:05] <jmkasunich> I just said it sucks less than ncurses
[03:48:11] <SWPadnos_> true
[03:48:35] <SWPadnos_> but I'm used to Borland C, so text mode dialogs are pretty normal for me
[03:49:14] <jmkasunich> sounds like Turbo-C, circa 1992 or so ;-)
[03:49:52] <SWPadnos_> heh - Borland C++ 3 - the best one for editing large numbers of ASM files for embedded projects ;)
[03:49:52] <jmkasunich> I used that alot in my former programming life, before I switched to Watcom, and then got disillusioned by Windows
[03:50:02] <SWPadnos_> let you run external compilers / assemblers, etc
[03:50:28] <jmkasunich> I used to be very good with Brief as an editor
[03:50:30] <SWPadnos_> also pipe the output into the error window, so you could click on error and jump to the offending source lines
[03:50:52] <SWPadnos_> BC was pretty close to brief, and I think it even had a set of brief keybindings
[03:51:23] <jmkasunich> we had brief where I worked at the time, and a copy somehow made it onto my box
[03:51:48] <SWPadnos_> B was great (though I never really used it much)
[03:52:21] <jmkasunich> I've been fully windowsified tho, I use kate, and a lot of mixed mouse/keyboard editing
[03:52:36] <jmkasunich> I use ctrl-C, -V, -X, etc, but very few other keyboard shortcuts
[03:52:46] <SWPadnos_> yeah - I've almost forgotten all the ctrl-K block stuff
[03:52:55] <jmkasunich> not like the old days when you did everything with hands on the keyboard
[03:52:56] <SWPadnos_> I now expect blocks to be overwritten if I type, etc
[03:53:31] <SWPadnos_> no - and the thing is, I'm not sure it's really faster now - you have to move between mouse and keyboard too much
[03:53:37] <jmkasunich> so anyway, what do you think of the tcl thing
[03:53:44] <SWPadnos_> also, you have to seee where the mouse pointer is
[03:54:07] <SWPadnos_> it's pretty cool.
[03:54:13] <jmkasunich> agreed about the mouse thing - the folks who use keyboard only editors A LOT, enough to know all the shortcuts, could run circles around me
[03:54:19] <SWPadnos_> I'm not sure if I prefer the wizard approach or the single window approach yet
[03:54:45] <SWPadnos_> you should have seen Paul at Fest - he had like 8 mc editors open at a time, and text was flying
[03:54:51] <jmkasunich> yeah
[03:55:43] <jmkasunich> rayh_away
[03:55:45] <jmkasunich> beep
[03:55:47] <jmkasunich> beep
[03:55:49] <SWPadnos_> he
[03:55:50] <SWPadnos_> heh
[03:56:12] <jmkasunich> going on 11pm and I can't afford to stay up all night on a work day
[03:56:24] <SWPadnos_> nope. maybe email would work
[03:56:29] <jmkasunich> I dunno if I should carry on with this or not
[03:56:35] <jmkasunich> I copied him on the mail to you
[03:56:38] <SWPadnos_> ok
[03:56:57] <jmkasunich> I could call him ;-)
[03:57:04] <SWPadnos_> if you add another wizard pane, then people can decide which approach they like best
[03:57:13] <jmkasunich> yeah
[03:57:25] <jmkasunich> I think I'm gonna work on the RUN one tonight
[03:57:30] <SWPadnos_> I think that would be valuable, and you could get to bed early tonight ;)
[03:57:33] <jmkasunich> theres only one more pane for that
[03:57:45] <jmkasunich> "Would you like to set the selected config as your default?"
[03:57:51] <SWPadnos_> what's the next pane? (make this the default)
[03:57:55] <SWPadnos_> ok
[03:59:01] <SWPadnos_> I'd also make it work from the tcl/bin dir, like Ray's, and use the right env var
[03:59:02] <jmkasunich> on the NEW side, the next pane is "pick a name", then "which do you want to copy" (reuse the pick list), then "edit the description to fit your application" then "I'm gonna create a dir and copy stuff, OK?"
[03:59:25] <jmkasunich> the env var doesn't exist until the run script runs
[04:00:07] <SWPadnos_> true - but the script shouldn't have to be in the configs dir
[04:00:28] <SWPadnos_> both scripts will have that problem though, so it'll need to be solved
[04:00:31] <jmkasunich> I'm thinking that you might actually invoke this program all the time... if it can figure out from defaults or the cmd line what you want to run, it would never pop up a window, just invoke the run script
[04:00:44] <SWPadnos_> it's meant to be the opposite
[04:00:55] <SWPadnos_> if there's no default, it runs the config script
[04:01:00] <SWPadnos_> emc does, that is
[04:01:03] <rayh_away> HI guys
[04:01:04] <jmkasunich> right
[04:01:09] <jmkasunich> hi ray
[04:01:12] <SWPadnos_> oooohhh - he's back!
[04:01:14] <jmkasunich> didja get my mail?
[04:01:23] <jmkasunich> didja, didja?
[04:02:07] <jmkasunich> swp: I think you might run these things other times too, when you have no intention of running EMC
[04:02:18] <jmkasunich> either to set a new default, or to generate a new config
[04:02:30] <jmkasunich> they might even be able to spawn config editor(s)
[04:03:29] <rayh_away> Yes I did
[04:03:51] <jmkasunich> same thing, slightly different look and approach
[04:04:02] <rayh_away> gotta pass it across and then I'll look.
[04:05:55] <SWPadnos_> I agree that it would be good to be able to run the config tool(s) from the comamnd line
[04:06:06] <SWPadnos_> so we'll need a way of making the dir known to those tools
[04:07:01] <SWPadnos_> you can eliminate onw pane in the "new" chain by changing the text to say "click "new" to create a new config based on the selected one" or similar
[04:07:24] <jmkasunich> good point
[04:08:22] <jmkasunich> on second thought..... if they are a true newbie, I just want to let them click new, and then explain to them why they are picking a template
[04:08:49] <SWPadnos_> is a newbie that likely to make a new config immediately?
[04:09:02] <jmkasunich> pretty quick
[04:09:08] <SWPadnos_> they'll need more help than that, I think
[04:09:19] <jmkasunich> remember, we're gonna be doing all we can to keep them from editing the standard configs
[04:09:26] <SWPadnos_> yes
[04:09:39] <jmkasunich> so even if all they need to do is change scale, the first step should be a new config
[04:10:16] <jmkasunich> in fact, if we somehow use these scripts to invoke editors, I'd like to somehow tag the standard configs and refuse to edit them
[04:10:32] <SWPadnos_> btw - you should be able to get the dirnames with [glob */] instead of [glob *] then checking whether it's a dir
[04:10:39] <jmkasunich> (of course they could get around that on the cmd line, but it will keep the newbies honest)
[04:11:01] <SWPadnos_> there should be no ini in the common dir, I think
[04:11:11] <rayh_away> I have some ambivalence about calling these file copiers configuration devices.
[04:11:12] <jmkasunich> there isn't one
[04:11:21] <SWPadnos_> so they'd never see common as a viable option
[04:11:49] <jmkasunich> right, because its not - common isn't a runnable config, its just a library
[04:12:03] <SWPadnos_> the idea would be to run the qconfig or halgui or your config tool (or whatever)
[04:12:06] <jmkasunich> rayh: if all they do is copy, I agree
[04:12:27] <jmkasunich> but what if they spawn an editor on emc.ini, or your tool on the hal files, or.....
[04:13:00] <SWPadnos_> incidentally, I thought of another interesting addition to halcmd
[04:13:09] <jmkasunich> another one!
[04:13:10] <SWPadnos_> (may you live in interesting times ;) )
[04:13:31] <SWPadnos_> yep - are you familiar with the pascal use of "with" or "using"?
[04:13:58] <jmkasunich> once upon a time, 25 years ago
[04:14:08] <jmkasunich> so that would be.... no
[04:14:23] <SWPadnos_> it basically allows you to set a structure name, then only use member names within the block
[04:14:31] <jmkasunich> ok
[04:14:39] <SWPadnos_> so you say using foo, and you can say bar=1, and foo.bar will be 1
[04:14:45] <jmkasunich> with ppmc.0.pwm.00
[04:14:48] <SWPadnos_> yep
[04:14:49] <jmkasunich> setp value 0.1
[04:14:55] <jmkasunich> setp freq 100000
[04:15:00] <SWPadnos_> endwith
[04:15:17] <jmkasunich> how about "prefix ppmc.0.pwm.00"
[04:15:21] <jmkasunich> then "prefix"
[04:15:27] <SWPadnos_> and even better, make it so you can pipe in an ini file, and have it only look in the specified section
[04:15:36] <jmkasunich> huh?
[04:15:58] <SWPadnos_> (probably different functions)
[04:16:01] <jmkasunich> where did ini files come from?
[04:16:18] <SWPadnos_> this came from the setp and = thing last night
[04:16:36] <jmkasunich> I'm really not in favor of putting large amounts of hal stuff in ini files
[04:16:39] <SWPadnos_> my reason for wanting name=value was so you could have lines in the ini file that look just like regular ini vars
[04:17:14] <jmkasunich> halcmd defines a language
[04:17:16] <SWPadnos_> if you add the prefix / inisection options, you can set a bunch of stuff in a module, with the module name as the section, and the vars alone on a line
[04:17:37] <jmkasunich> it doesn't look anything like ini format, for one thing ini is order independent, and hal is a scripting language
[04:17:49] <SWPadnos_> there are two semantic parts to the language - creation of objects, and setting their values
[04:18:03] <SWPadnos_> setting of values isn't order-dependent
[04:18:06] <jmkasunich> both of which are procedural
[04:18:22] <SWPadnos_> setp isn't exactly procedural, I think
[04:18:55] <jmkasunich> tell that to the MOSFETs after you set the enable TRUE before setting a safe PWM frequency
[04:18:57] <rayh_away> So where do we go from here with this config business
[04:19:04] <jmkasunich> I dunno
[04:19:30] <SWPadnos_> there may be blocks of setp that you want to execute before doing other things (like starting the servo thread)
[04:19:33] <jmkasunich> I was caught by surprise by your commit, obviously we are working on the same thing
[04:20:04] <jmkasunich> swp: IMO, we've stretched the halcmd language about as far as I want to stretch it
[04:20:06] <SWPadnos_> enable would be a pin anyway
[04:20:55] <jmkasunich> I have no objection to you making a similar program, or a completely differnt mode for halcmd that interprets a completley differnt source format, but I really don't want add ini format to what we have now
[04:21:20] <jmkasunich> after all, 90% of the lines in an ini file would be ignored by halcmd
[04:21:24] <SWPadnos_> ok - I was just thinking of ways to make config easier - putting a line in the ini (STEPGEN_NMAX_OUTPUT) and in a .hal (setp stepgen.00.max_output [AXIS_0]STEPGEN_MAX_OUTPUT) seems redundant
[04:21:44] <jmkasunich> I disagree
[04:21:56] <rayh_away> IMO we can rather easily manipulate all of configuration from something like tickle
[04:22:03] <jmkasunich> but it is probably a matter of opinion
[04:22:16] <SWPadnos_> sure - we can drop it for now
[04:22:33] <SWPadnos_> as you casy - I can always add a new halcmd-like tool that does what I want ;)
[04:22:33] <jmkasunich> lets talk about these config tools for now
[04:22:37] <SWPadnos_> yep
[04:22:39] <rayh_away> without having to create a lot of config handling stuff in hard code.
[04:22:51] <jmkasunich> define "hard code"?
[04:23:03] <jmkasunich> to me, tcl is hard code
[04:23:07] <rayh_away> something that has to be compiled
[04:23:15] <rayh_away> Not at all.
[04:23:19] <rayh_away> imo
[04:23:27] <jmkasunich> I think that distinction is not so important
[04:23:34] <rayh_away> notice the lower case cause we are getting into tricky waters.
[04:23:45] <jmkasunich> "hard code" is code that isn't trivial to modify
[04:24:04] <rayh_away> that works.
[04:24:10] <jmkasunich> and of course "trivial to modify" is subjective, for you tcl is
[04:24:15] <rayh_away> trivial for rayh to modify
[04:24:18] <jmkasunich> within reason
[04:24:32] <jmkasunich> trivial for anybody to modify
[04:24:49] <SWPadnos_> anyone who knows at least *some* programming ;)
[04:24:57] <rayh_away> as an example, I added the tuning parameters to an ini for ppmc recently
[04:25:04] <jmkasunich> granted I'm a total tcl newbie, but I found many. many stumbling points when I was working on that script this afternoon
[04:25:05] <rayh_away> They work well from there.
[04:25:26] <rayh_away> Oh yea. There are a thousand gotchas
[04:25:38] <jmkasunich> ray: how many people could have done that (the ppmc params thing)?
[04:25:54] <rayh_away> things as simple as [set $whatevervarname]
[04:26:39] <rayh_away> I guess I was thinking back to emc days when those were ini variables.
[04:26:56] <rayh_away> and asking myself why would I want to change that.
[04:26:57] <jmkasunich> I see the level of difficulty/"hard codedness" as going: ini file, hal file, tcl file, c/c++ files
[04:27:14] <rayh_away> That is probably about right.
[04:27:18] <jmkasunich> hopefully, average users edit ini only
[04:27:26] <jmkasunich> advanced integrators edit hal
[04:27:33] <jmkasunich> and nobody edits tcl or C
[04:27:51] <jmkasunich> oops, forgot classicladder files
[04:27:58] <rayh_away> I wrote a front end to let me tune ppmc direct to halcmd
[04:27:58] <jmkasunich> they're probably between ini and hal
[04:28:46] <jmkasunich> btw, I want to modify core_servo.hal to pull its P,I,D, etc from the ini again
[04:28:50] <rayh_away> problem with thinking that way is that cl files can't be edited by anything but the cl front end.
[04:28:58] <jmkasunich> but they will be only in a servo ini, stepper inis don't need them
[04:29:23] <jmkasunich> true, but if you have the tool, its probably more intuitive than editing hal files
[04:29:25] <rayh_away> Right and with the configs/xxx the way they are now, that should be no problem.
[04:29:43] <jmkasunich> exactly - I'm quite pleased with the path alex has started us on
[04:30:13] <rayh_away> I was kinda wishing that we didn't have to edit each ini for it's location.
[04:30:26] <jmkasunich> ?
[04:30:33] <jmkasunich> you mean paths in the ini?
[04:30:40] <rayh_away> yes
[04:30:57] <jmkasunich> if they invoke a "common" file they need edited NML_FILE = ../common/emc.nml
[04:31:03] <SWPadnos_> you don't have to - the only paths are ../common/
[04:31:12] <jmkasunich> if they invoke a local file, they don't need it
[04:31:22] <jmkasunich> HALFILE = mypinout.hal
[04:31:25] <rayh_away> okay that will help
[04:31:31] <SWPadnos_> but the other side of that coin is that "default" behavior shouldn't be relied on
[04:31:55] <SWPadnos_> so you should be explicit anyway, if you don't want things to get screwed up at a later date ;)
[04:32:19] <jmkasunich> a file without a path will be pulled from the "user" config
[04:32:31] <jmkasunich> if it gets screwed up, its because he screwed it
[04:32:52] <SWPadnos_> right - the default behavior is like 'ls' - current dir or specified dir
[04:33:07] <jmkasunich> actually its the common ones that worry me, if we change a core_foo.hal, people might have working configs stop working
[04:33:23] <SWPadnos_> rather than bash, for example (check /etc/bashrc, then /etc/profile, then ~/.bashrc ...)
[04:33:53] <jmkasunich> I'm very tempted to propose that we copy all files to a users config dir
[04:33:58] <rayh_away> I've already gotten screwed cause of core_stepper.hal
[04:34:21] <jmkasunich> you made local mods and CVS stompped on them?
[04:34:29] <jmkasunich> or we made mods and cvs up broke you
[04:34:50] <rayh_away> I made a config and then pulled it into a new checkout.
[04:35:10] <rayh_away> version change to core_stepper
[04:35:48] <jmkasunich> I'm really in favor of having user configs completely isolated from CVS configs
[04:35:57] <rayh_away> Not a big thing but while we are making those kinds of changes we break most all existing stuff.
[04:36:00] <jmkasunich> CVS/tarball/distribution
[04:36:14] <jmkasunich> right
[04:36:33] <rayh_away> We could make the sample configs read only.
[04:36:42] <jmkasunich> I would like to do that...
[04:37:02] <jmkasunich> discourage, if not outright prohibit, editing of the samples
[04:37:12] <jmkasunich> they are only to be used as templates
[04:37:31] <rayh_away> If we pull all the relevant files into a users config/dir then we will have to read the ini
[04:37:46] <jmkasunich> how so?
[04:37:57] <rayh_away> No problem doing that but we would need to chase down the complete set.
[04:38:02] <jmkasunich> if only relevent files are in the directory to start with...
[04:38:23] <jmkasunich> duh, we still dont want duplicates of all the common ones in every sample dir
[04:38:27] <rayh_away> say for example that sim.ini makes reference to common/core_xxx.hal
[04:38:34] <jmkasunich> right
[04:39:00] <rayh_away> we need to grab a copy of all of the files and stuff them in there.
[04:39:31] <jmkasunich> and change the ini, so instead of pointing to ../common/core_foo.hal, it points to core_foo.hal (the users copy)
[04:39:38] <rayh_away> if the local directory search works as promised, we don't have to change the references in the original but they still might confuse some folk.
[04:40:04] <jmkasunich> I'd suggest eliminating the ../common completely from the ini, but then the samples wouldn't be runnable
[04:40:05] <rayh_away> me for example
[04:40:34] <jmkasunich> if there is an explicit path "../common" in the ini, it should obey the path
[04:40:49] <rayh_away> should be easy enough to read in an ini, search for common/ and remove it.
[04:40:50] <jmkasunich> anything else would make people crazy (and not just you)
[04:41:17] <jmkasunich> yeah, and at the same time make note of the file so you can copy it from common/
[04:41:42] <jmkasunich> so it is _doable_, the question is, is it the right thing to do
[04:41:58] <jmkasunich> on one side, changes to common/foo might mess people up
[04:42:17] <jmkasunich> on the other side, changes to common/foo that fix bugs would have to be manually copied over by the user
[04:42:18] <rayh_away> Someone mentioned more than one ini in a configs/dir
[04:42:29] <jmkasunich> yeah, like inch and mm versions
[04:42:49] <jmkasunich> the hal files in that case would probably be identical, only the inis would vary
[04:43:00] <jmkasunich> so instead of two config dirs, just have two inis
[04:43:10] <rayh_away> How do we handle those cases when we start with a command like "emc sherline"
[04:43:18] <jmkasunich> like the dirs, we would have a mechanism to indicate a default
[04:43:29] <jmkasunich> and like the dirs, the first time it would ask you which one you want
[04:43:34] <rayh_away> "emc sherline mm"
[04:43:43] <SWPadnos_> or sherline_mm
[04:43:57] <SWPadnos_> though two params might be easier
[04:44:06] <jmkasunich> both of those would be hard for the run script to deal with, why not let the wizard do it
[04:44:09] <rayh_away> so we would need to sort on the first part for dirname
[04:44:24] <rayh_away> I don't favor wizard start.\
[04:44:26] <SWPadnos_> if you have two params, then look for param1_param2 in the param1 dir - not too hard
[04:44:40] <jmkasunich> swp: yes
[04:44:43] <jmkasunich> ray: why?
[04:44:59] <jmkasunich> once the defaults are set, you'd never see the wizard
[04:45:07] <rayh_away> most of the machines out there are dedicated
[04:45:23] <rayh_away> but any sherline distro will have both mm and inch
[04:45:34] <rayh_away> and soon will have the same for mills and lathes.
[04:45:50] <SWPadnos_> ok - the mill / lathe thing would be an issue
[04:45:56] <jmkasunich> that screen that I did... after you pick one and hit RUN, it will ask you "do you want to set this config as the default", then continue on and run emc
[04:46:05] <SWPadnos_> that's something that people would want to switch back and forth a lot
[04:46:12] <jmkasunich> mill and lathe are two completely different configs
[04:46:15] <rayh_away> I suppose it is possible to strip out unnecessary dirs on these kinds of releases.
[04:46:16] <jmkasunich> in two dirs
[04:46:28] <SWPadnos_> yes, it's the back and forth that's the problem
[04:46:47] <SWPadnos_> I suppose the integratopr could have a mill and a lathe config dir
[04:46:48] <rayh_away> could be simply configs/millmm configs/millinch
[04:46:50] <jmkasunich> if you pass a dir name to the run script, it ignores the default
[04:46:56] <SWPadnos_> yes
[04:47:21] <jmkasunich> two mill dirs will in all likely hood have exactly the same hal files in them
[04:47:33] <jmkasunich> (assuming it is the same mill, only a units change)
[04:47:58] <jmkasunich> so if he burns out a parport pin and edits HAL to reroute, he'll have to do that edit twice
[04:48:12] <jmkasunich> (and have to remember to do it twice)
[04:48:50] <rayh_away> The mill itself will be defined in one unit or the other.
[04:49:01] <jmkasunich> I think the way we left it last time we talked was that if the cmd line had dir and file, it would use exactly that
[04:49:07] <rayh_away> It's the distro that needs em all.
[04:49:16] <jmkasunich> if the cmd line has dir only, it will go to that dir and use the default file
[04:49:31] <jmkasunich> if the cmd line has nuttin, it goes to the default dir, and uses the default file
[04:49:44] <rayh_away> you mean as in configs/m5i20/default.ini?
[04:50:02] <jmkasunich> the exact mechanism for defaults isn't decided
[04:50:06] <SWPadnos_> configs/m5i20/m5i20.ini
[04:50:10] <rayh_away> ah.
[04:50:13] <SWPadnos_> I think that's what it is now
[04:50:14] <jmkasunich> just assume there is some way to say "this one is the default"
[04:50:22] <SWPadnos_> (looking at the files in CVS right now)
[04:50:24] <rayh_away> configs/m5i20/m5i20.ini really annoys me.
[04:50:38] <jmkasunich> I was thinking that emc.ini might be the default, and it would be a symlink to the desired one
[04:50:56] <rayh_away> alpha sorting for lowest named ini?
[04:50:57] <jmkasunich> changing the default means changing the symlink (done by the wiz, not by the user typing unixy stuff)
[04:51:24] <rayh_away> so x1.ini would start before x2.ini
[04:51:28] <SWPadnos_> where would this emc.ini be?
[04:51:37] <jmkasunich> in the individual config dire
[04:51:38] <jmkasunich> dir
[04:51:51] <SWPadnos_> ok - if you have two configs in a dir, then making a link called dirname.ini would be OK
[04:51:52] <jmkasunich> so lathe would have an emc.ini, and mill would have an emc.ini
[04:51:59] <SWPadnos_> (or emc.ini or default.ini or whatever)
[04:52:29] <SWPadnos_> ok - that was my thought as well - no point changing the names of the ini
[04:52:32] <jmkasunich> inside the dir you might have lathe_in.ini and lathe_mm.ini, and emc.ini (or lathe.ini, or default.ini) would be a symlink to one or the other
[04:52:35] <rayh_away> If we do have many emc.ini files plastered throughout the config stuff.
[04:52:50] <rayh_away> we will need a way to troubleshoot.
[04:52:53] <SWPadnos_> though they are slightly driver-specific - they specify which hal file to load, and that will have the driver in it
[04:52:57] <jmkasunich> but only one per dir
[04:53:12] <rayh_away> What ini are you using? will not be a trivial question at all.
[04:53:20] <jmkasunich> my recommentation for troubleshooting is to have the user tar up their individual config dir
[04:53:26] <jmkasunich> configs/lathe for instance
[04:53:31] <SWPadnos_> I think that's why they have unique names
[04:53:44] <rayh_away> and what ini does the startup report to bash
[04:53:48] <jmkasunich> the question won't be "what ini are you using", it will be "what config are you using"
[04:54:17] <jmkasunich> because for troubleshooting, we might want to see their .hal and .ladder files too
[04:54:21] <rayh_away> I'm thinking of the guy who called the other day with a sherline question.
[04:54:33] <rayh_away> He was starting with the emc in k menu
[04:54:40] <rayh_away> and getting all the wrong answers.
[04:54:57] <jmkasunich> doesn't the k menu emc invoke the right config?
[04:55:01] <rayh_away> seems his desktop icons went away.
[04:55:02] <jmkasunich> or did he fsck with it?
[04:55:26] <rayh_away> well imo it was sloppy distro work.
[04:55:43] <SWPadnos_> hmmm - I guess we should have an icon somewhere
[04:55:50] <rayh_away> generic and emc were in k and millinch and millmm were on desktop.
[04:55:51] <SWPadnos_> in the tree
[04:55:56] <jmkasunich> ok, it wasn't his fault, but the icon got changed
[04:56:20] <rayh_away> yep.
[04:56:30] <jmkasunich> heh, I'd have the icon invoke emc, with no ini named at all
[04:56:55] <jmkasunich> the first time run, the wiz would ask them to pick, after that the defaults are set, end of problem
[04:57:06] <rayh_away> anticipating all of the possible problems to address in a single config wizard is going to be difficult.
[04:57:44] <jmkasunich> I know, it isn't an attempt to manipulate individual pieces of the config, as much as a way to manage the config directories
[04:57:47] <SWPadnos_> the trouble is that there's only one default, and someone might want as many as 4 active configs
[04:57:53] <rayh_away> it scares me that a machine operator has that much ability instantly at his command.
[04:58:20] <jmkasunich> heh, ray wants less flexibility, swp wants more
[04:58:23] <SWPadnos_> lathe and mill, inch and metric (silly, but possible)
[04:58:23] <rayh_away> integrator no problem there is a real need there.
[04:58:50] <jmkasunich> here is what I think the wiz might do (hear me out, then comment)
[04:58:51] <SWPadnos_> on - I'm just looking at the issue ray brought up - mill vs. lathe, without typing lathe or mill every time
[04:59:07] <jmkasunich> allow you to delete any config directory (to get rid of unneeded/confusing ones)
[04:59:08] <SWPadnos_> you can certainly set up icons with command line params though
[04:59:29] <jmkasunich> allow you to make a new config by copying any other (either one of the samples, or your own)
[04:59:35] <jmkasunich> allow you to run any config
[04:59:42] <jmkasunich> allow you to set any config as the default
[04:59:54] <jmkasunich> allow you to tar up any config, to mail off for help
[05:00:24] <jmkasunich> maybe, if possible, allow you to make an icon that fires off a particular config
[05:00:57] <jmkasunich> and allow you to invoke editors on any config (except the standard)
[05:01:21] <jmkasunich> so the user will get used to refering to "configs", rather than to the inidividual files
[05:01:39] <jmkasunich> ok, I'm done now...
[05:01:40] <SWPadnos_> standard config = what? (and should it be deletable if it's not editable?)
[05:01:45] <jmkasunich> asbestos pants on
[05:01:57] <jmkasunich> standard config being the ones we ship
[05:01:58] <SWPadnos_> bad chili? ;)
[05:02:29] <SWPadnos_> ok - maybe those will need to be made RO
[05:02:40] <jmkasunich> deleteable because once you have your taig working, the maxak sample is just confusing
[05:02:54] <jmkasunich> there would be lots of "are you sure" before allowing that to be deleted
[05:03:12] <SWPadnos_> ok, but if you edit it, it either doesn't matter, or it'll go away if you get an update
[05:03:29] <SWPadnos_> the edits will go away
[05:03:42] <jmkasunich> depends
[05:03:50] <jmkasunich> CVS won;t do anything with your edits
[05:04:06] <rayh_away> I'd like to see a set of release specific stock config files preserved someplace untouchable
[05:04:09] <SWPadnos_> the "customer" won't be likely to use cvs
[05:04:14] <jmkasunich> if they conflict with changes in the new version, you get conflict tags and the file is fscked
[05:04:37] <SWPadnos_> ray - are you saying release specific as in "sherline's CD"?
[05:04:44] <SWPadnos_> or as in release 2.0.0.1?
[05:04:57] <rayh_away> Right or even emc2-1.05
[05:05:26] <jmkasunich> actually, version numbering is something else we should discuss, but not tonight
[05:05:51] <jmkasunich> yesterday we were leaning toward kernel style: emc-2.0.1 is the upcoming stable release
[05:05:52] <SWPadnos_> yep
[05:06:02] <jmkasunich> emc-2.1.x is unstable
[05:06:11] <rayh_away> If these standard files were there we could easily diff for changes
[05:06:15] <jmkasunich> emc-1.something would be our last emc1 release
[05:06:22] <rayh_away> that's why I said 05
[05:06:35] <SWPadnos_> or even just putting versions into the ini / hal files (like the cvs $Revision: string)
[05:06:55] <jmkasunich> swp: that doesn't help if the user edits it, he won't update the string
[05:07:07] <SWPadnos_> right - but you'll see what it was based on
[05:07:15] <jmkasunich> not much help
[05:07:27] <SWPadnos_> more than no info, I'd imagine
[05:07:37] <jmkasunich> if some guy is on IRC complaining about following errors, I need to know exactly what he is running, not just close
[05:07:42] <SWPadnos_> most users won't be doing much editing, other than axis scaling, I'd bet
[05:07:46] <rayh_away> It will be for revisions to hal modules that cause configs to become obsolete.
[05:08:31] <rayh_away> I do like the idea of tarballs for configs.
[05:08:38] <rayh_away> I used to call them personalities.
[05:08:49] <jmkasunich> every release of emc2 will need to have all the standard configs tested to make sure they match the hal modules
[05:09:17] <jmkasunich> any change to the hal pins exported by a hal module would be cause for a new release number, because they are no longer compatible
[05:09:19] <rayh_away> right but folk will pull forward a config
[05:09:32] <jmkasunich> and have to edit it
[05:09:44] <jmkasunich> in general, changes to hal pin names are a bad thing
[05:09:54] <jmkasunich> we should get our naming convention right, and then stick with it
[05:10:04] <rayh_away> more like start from scratch if the wizard is the config tool
[05:10:23] <jmkasunich> depends on the amount of hacking they did
[05:10:37] <jmkasunich> if all they did was set scales, then yes, start from scratch, change the ini, done
[05:10:55] <jmkasunich> if they hacked a lot in the hal files, then they will want to save their hacks
[05:12:17] <jmkasunich> one thing: whatever the wiz does, it should be clearly documented, and reproducable from the command line
[05:12:18] <rayh_away> I'm imagining that each supported hardware would have a sample config
[05:12:45] <rayh_away> so a servo guy starts the gui
[05:12:51] <SWPadnos_> if we can make a recommended set of signal names, then a lot of that will be easier to do
[05:13:13] <rayh_away> selects his board(s) and gets those configs in configs/hisdir
[05:13:17] <jmkasunich> SWP: that comes down to being smart about the sample configs
[05:13:33] <SWPadnos_> actually, it comes down to being smart about the interface the sample configs present
[05:13:36] <jmkasunich> ray: yes
[05:13:53] <SWPadnos_> if they're all the same (within reason), then updates to the core* files don't break (much)
[05:14:08] <rayh_away> I could see the next page of the wizard asking for encoder counts per unit
[05:14:20] <rayh_away> and such
[05:14:26] <rayh_away> IO connections
[05:14:30] <jmkasunich> ray: I wasn't going that far, but that is a logical extension
[05:14:34] <rayh_away> and then a tuning page.
[05:15:13] <rayh_away> If this was a non stock kind of install then the text editing pages would be necessary.
[05:15:27] <jmkasunich> right
[05:15:45] <jmkasunich> I see several independent but cooperating wizards
[05:16:04] <jmkasunich> one manages the configs as a whole - select, copy, tarball, etc
[05:16:17] <jmkasunich> another is used to configure a certain class of machines
[05:16:20] <rayh_away> At least a modular sort of front end to it.
[05:16:26] <jmkasunich> a servo wiz, a stepper wiz
[05:16:43] <SWPadnos_> the qconfig idea would be handy there
[05:16:45] <jmkasunich> from the users perspective it could be seamless
[05:17:07] <jmkasunich> the config manager would call the appropriate machine specific wiz at the appropriate point
[05:17:44] <rayh_away> When we were working on the qconf idea
[05:17:58] <rayh_away> we had to build a master file
[05:18:10] <jmkasunich> with all the "hints" and such?
[05:18:12] <SWPadnos_> yes - that could be done with halcmd instead
[05:18:30] <SWPadnos_> but the acceptable ranges for various params wouldn't be there
[05:18:34] <rayh_away> I've noticed that once the hal modules are loaded, halcmd can become that knowledge base.
[05:18:48] <SWPadnos_> yes - except for limitations on settings
[05:18:57] <SWPadnos_> or - limits on settings
[05:19:29] <jmkasunich> many module params have limits, but A) those limits are module limits only, and may be insane for the application
[05:19:29] <rayh_away> could you illustrate a limit that is hal but not machine?
[05:19:40] <jmkasunich> for instance, the PWM module can make 500KHZ pwm
[05:19:55] <SWPadnos_> right
[05:20:03] <jmkasunich> if you ask for 1MHz PWM, the parameter value will be forced to 500KHZ
[05:20:03] <rayh_away> not much range there
[05:20:30] <jmkasunich> but you probably want something between 10KHz and 20KHz
[05:20:46] <SWPadnos_> that was meant also for the ini file - like listing the allowed display programs
[05:20:50] <jmkasunich> I didn't want to limit the module tho, because other applications might want more
[05:20:58] <SWPadnos_> or io or motion programs (if there are options)
[05:21:16] <SWPadnos_> actually, it was forthe ini file, come to think of it
[05:21:21] <SWPadnos_> not for hal
[05:21:32] <jmkasunich> yeah, alot of things are "choose from this list" rather than "choose between these limits"
[05:22:27] <rayh_away> We already have a couple of models of ini configuration wizards.
[05:22:48] <SWPadnos_> yep
[05:23:22] <jmkasunich> yeah - another reason why I want to think in terms of the select/copy wizard invoking helpers to do the actual configuration, not trying to do it itself
[05:24:27] <rayh_away> Sure
[05:25:14] <jmkasunich> now that we have individual directories for both the sample configs and for user configs, I want to take full advantage of that
[05:25:42] <jmkasunich> that means thinking of a config as the contents of a directory, not just one or two files
[05:26:19] <rayh_away> So we need to add some auto navigation between wizards as we write them.
[05:26:51] <rayh_away> I don't like the way that damn small did wizard-wizard.
[05:27:07] <rayh_away> it's just a set of buttons allowing selection of any.
[05:27:22] <jmkasunich> "you have selected the lathe config, and the lathe_mm ini file... now what do you want to do: RUN, edit ini, tune, edit hal, etc"
[05:27:23] <rayh_away> We need a path from start to finish
[05:27:37] <SWPadnos_> maybe think a bit like the KDE control panel
[05:27:46] <SWPadnos_> or not ;)
[05:28:07] <rayh_away> That kcontrol is not an entirely bad model
[05:28:29] <SWPadnos_> no, but it's not exactly start to finish
[05:28:37] <jmkasunich> right, its random access
[05:28:52] <jmkasunich> which is what you want once you get past the first setup
[05:28:54] <SWPadnos_> their config model is great as well, but the nice GUI tools are KDE-specific and large
[05:29:14] <jmkasunich> cause you might want to go back and tweak something, and there's no way to know what you want to tweak
[05:29:43] <jmkasunich> now when you first install KDE, and log in the first time, it walks you thru some basic setup
[05:29:55] <SWPadnos_> true
[05:30:00] <jmkasunich> then tells you how to come back later and do it in a ramdom-access kind of way
[05:30:21] <jmkasunich> I think thats the key, we need sequential walkthru for the first time, or for newbies
[05:30:27] <jmkasunich> and random access later, or for experts
[05:31:20] <jmkasunich> heh, need a "config.state" file (maybe hidden)
[05:31:29] <rayh_away> If we do this will we need a file that saves that first set of selections
[05:31:37] <rayh_away> thinking a lot alike
[05:31:42] <jmkasunich> when you start, it looks at the state to see how far you got, and invokes the appropriate sequential wiZ
[05:31:57] <rayh_away> With that config thing I put in the dropbox earlier today,
[05:32:08] <rayh_away> I read config from the ini file.
[05:32:09] <jmkasunich> once you get to the end, the state is "done", and you can run the machine, or invoke any wiz for tweaking
[05:32:51] <SWPadnos_> I'm not sure that's the greatest idea
[05:32:53] <rayh_away> or invoke the wiz again to write another
[05:33:09] <SWPadnos_> the config system shouldn't prevent an expert from running the machine immediately
[05:33:09] <jmkasunich> swp: what part?
[05:33:20] <jmkasunich> swp: agreed
[05:33:32] <SWPadnos_> assuming that they did things manually, the config.state will be nothing
[05:33:39] <jmkasunich> have an "expert" button that sets the state to "done"
[05:33:56] <SWPadnos_> the expert may choose to never run the wizard at all
[05:34:09] <jmkasunich> then nothing is stopping him from running emc
[05:34:11] <SWPadnos_> cp core_stepper/* myconfig/*
[05:34:20] <SWPadnos_> emc myconfig
[05:34:38] <jmkasunich> sure, he can do that
[05:34:42] <rayh_away> IMO a startup should allow running from read only configs.
[05:34:57] <jmkasunich> yes, the sample configs should be runnable
[05:35:02] <SWPadnos_> ok - I'm just thinking back to the idea the "emc" will get the wizard in some cases
[05:35:22] <jmkasunich> emc myconfig won't, assuming that myconfig exists and has an ini file in it
[05:35:30] <SWPadnos_> true
[05:35:35] <jmkasunich> the wiz is for cases where there is ambiguity
[05:36:28] <jmkasunich> hmm, emc myconfig when myconfig doesn't exist can skip the first 2 pages and go right to "which config would you like to copy for your new config 'myconfig'"
[05:36:53] <rayh_away> How about a front page to this wiz that allows immediate run from 1 or 2 sample files or setup of a new.
[05:36:54] <jmkasunich> there will always be a cancel button, in case it was a brain fart or typo
[05:37:10] <jmkasunich> ray: thats pretty much what my tcl does
[05:37:27] <jmkasunich> gives you a list of configs, 1 click to select, 1 click to run
[05:37:42] <jmkasunich> only if you click new do you get into the copying and such
[05:37:52] <SWPadnos_> 1 click to say "no, I don't want this to be the default"
[05:38:00] <jmkasunich> right
[05:38:05] <rayh_away> But without intervention, only sim, emc, or step_cl will go.
[05:38:20] <SWPadnos_> univstep and univpwm should as well
[05:38:24] <jmkasunich> you mean because of missing hardware?
[05:38:38] <rayh_away> missing hardware prevents any servo system from starting.
[05:38:44] <jmkasunich> SWP: the uni ones won't work without hardware
[05:38:58] <SWPadnos_> sure -I'm assuming that things are hooked up
[05:39:03] <SWPadnos_> you can't tune or test without that
[05:39:13] <jmkasunich> rayh: I expect that the README for each one would say "this needs X hardware"
[05:39:32] <SWPadnos_> "if you have a Universal Stepper Controller connected, this is your config"
[05:39:41] <rayh_away> Right. I kinda suggested that in the one readme I wrote for sim.
[05:40:17] <jmkasunich> btw, I stole your idea - my version had a file called "description" in the dir, and it displayed that - I changed to README after I saw yours
[05:40:46] <rayh_away> I thought you were ahead of me.
[05:40:56] <rayh_away> great minds and all.
[05:41:10] <jmkasunich> and the idea of displaying a description at all came from the qconfig stuff
[05:42:08] <SWPadnos_> great minds - yeh, that's it
[05:42:22] <jmkasunich> well, getting late here (again)
[05:42:29] <rayh_away> Yes and I still like the idea of using simple html in that but that brings a whole other layer of complexity.
[05:42:44] <jmkasunich> didn't add any more code to the tcl, but we have a lot of good ideas going around here
[05:42:51] <SWPadnos_> yep - I was just gonna say - it's late, and I'll probably need to clear snow this morning
[05:43:03] <jmkasunich> I did that this evening :-/
[05:43:08] <SWPadnos_> it 's snowing now
[05:43:34] <rayh_away> Nice weather here.
[05:43:35] <SWPadnos_> ray - is there an html or RTF text widget (that we can get to work)?
[05:43:40] <jmkasunich> rayh: one thing I don't like about your README - no line breaks, so very hard to read in an ordinary editor or catted to the screen
[05:43:53] <rayh_away> I've seen some stuff but not tried any.
[05:43:57] <SWPadnos_> ok
[05:44:08] <jmkasunich> I understand why you did it tho, so it could re-wrap if the window resizes
[05:44:09] <rayh_away> Could look a bit tomorrow.
[05:44:21] <jmkasunich> I don't know if there are any good solutions to that
[05:44:52] <jmkasunich> my old "description" file was preformatted, for a 60 char wide window
[05:44:59] <SWPadnos_> concat any lines that end in a single newline
[05:45:01] <jmkasunich> but if you resize or whatever, it gets messy
[05:45:04] <rayh_away> Well inspite of the no line breaks, I did make a fixed size screen so could have.
[05:45:11] <SWPadnos_> double newline = new paragraph
[05:45:18] <jmkasunich> SWP: I like that
[05:45:32] <jmkasunich> dunno how hard to do in tcl, but I like it
[05:45:42] <SWPadnos_> sed or the like can probably do that (though I don't know how)
[05:46:20] <rayh_away> pretty limited in tk
[05:46:31] <jmkasunich> s/\n\n/some_unlikely_char/; s/\n// s/some_unlikely_char/\n/
[05:46:32] <rayh_away> stuff like \n\n
[05:46:39] <rayh_away> gets messy in a hurry.
[05:47:41] <SWPadnos_> yeah - and sed is kind aline based sometimes
[05:47:44] <SWPadnos_> kinda
[05:47:50] <jmkasunich> oops, right
[05:47:56] <rayh_away> http://www.hwaci.com/sw/tkhtml/
[05:48:04] <SWPadnos_> does it work?
[05:48:27] <SWPadnos_> can we (you) make it work? :)
[05:48:42] <jmkasunich> so the README would be in html?
[05:48:52] <SWPadnos_> optionally
[05:49:06] <jmkasunich> interesting thought
[05:49:11] <rayh_away> I can try it in the morning.
[05:49:16] <SWPadnos_> as long as plain text is an option, it's OK
[05:49:18] <SWPadnos_> ok
[05:49:30] <jmkasunich> but I'm gonna look into whether tcl can to the \n \n\n thing
[05:49:43] <jmkasunich> theres also the dependency thing
[05:49:50] <rayh_away> 300k
[05:49:56] <jmkasunich> BDI-old has tcl, but not this package
[05:50:06] <jmkasunich> its not the size, its getting it to the user
[05:50:32] <jmkasunich> I realize its not an issue for Sherline or whatever, they'll have a shiny new CD
[05:50:41] <SWPadnos_> you'd have to replace all \n[^\n] with "", then "\n\n" with "\n"
[05:51:09] <rayh_away> Right we would need to make whatever additions we use available for all.
[05:51:11] <SWPadnos_> oops - first replace is ""\1 (or \0) I think
[05:51:22] <jmkasunich> swp: I'd rather do it in tcl
[05:51:25] <SWPadnos_> heh
[05:51:30] <SWPadnos_> C is my friend ;)
[05:51:41] <rayh_away> and a part of the package require if we build debs or rpms
[05:51:52] <jmkasunich> it has good string handling (the entire README is just a string), just not so strong at individual chard
[05:51:54] <jmkasunich> chars
[05:52:25] <SWPadnos_> we'll have to be careful with dependencies
[05:52:41] <rayh_away> let me look a bit more. I think McClenahan and company have some html stuff.
[05:52:46] <rayh_away> in pure tk
[05:53:09] <jmkasunich> ok
[05:53:23] <SWPadnos_> if you need to include 300k of source, you might as well just depend on the package ;)
[05:53:38] <jmkasunich> I'm gonna keep chugging away on my wiz, at least for a day or two, then maybe ray and I should sit down and decide what parts of each we want
[05:53:52] <jmkasunich> seems dumb for us both to stay on it much longer than that
[05:54:06] <SWPadnos_> yep
[05:54:28] <jmkasunich> I am learning tck/tk tho, so it isn't entirely wasted effort
[05:54:32] <SWPadnos_> though you have two different approaches ATM, it may be good for others to see them, and help decide which one to pursue
[05:54:42] <jmkasunich> yeah
[05:55:03] <jmkasunich> I'd like both to be visible, but don't want to commit both, because then you have multiple files, some dead
[05:55:04] <rayh_away> * rayh_away would be pleased to take a back seat on this
[05:55:34] <SWPadnos_> yep - the dropbox and an email or conversation with some active folk would probably do
[05:56:23] <rayh_away> foster-johnson has a section on html.
[05:56:27] <jmkasunich> rayh: I'll run with it a couple days and we'll see what happens
[05:56:28] <rayh_away> will read a while.
[05:56:56] <jmkasunich> can I count on you for testing, tck critique, and feedback?
[05:57:22] <jmkasunich> my tcl style leaves a LOT to be desired ;-)
[05:57:56] <jmkasunich> but now its bedtime...
[05:58:32] <SWPadnos_> yeah - me, too - see ya later Ray
[05:58:39] <SWPadnos_> SWPadnos_ is now known as SWP_Away
[05:59:55] <rayh_away> night guys
[15:59:24] <SWP_Away> SWP_Away is now known as SWPadnos_
[16:28:46] <rayh> How is emc2 doing with steppers since the latest modifications there?
[16:29:07] <SWPadnos_> good question
[16:29:24] <SWPadnos_> I note that the stepper demo config won't load on my machine
[16:29:55] <rayh> * rayh tests
[16:30:40] <rayh> scripts/emc does bring up scope and mini
[16:31:06] <SWPadnos_> scripts/emc stepper complains that it can't find motion module "/Project/emc2-check/rtlib/.ko"
[16:31:29] <rayh> sim does the same.
[16:31:42] <SWPadnos_> but demo_step_cl works for me
[16:31:54] <rayh> I had the same problem when I tried to make a univstep directory.
[16:32:14] <SWPadnos_> I looked at the inis, but didn't see the problem
[16:36:34] <alex_joni> SWPadnos_: the problem is that there is no stepper/stepper.ini
[16:36:40] <alex_joni> there is a stepper_in.ini however
[16:36:47] <SWPadnos_> ok, so it doesn't et the stepper_in.ini that's there
[16:36:51] <alex_joni> so starting emc configs/stepper/stepper_in.ini works
[16:36:54] <SWPadnos_> s/et/get/
[16:37:00] <SWPadnos_> ok
[16:37:03] <alex_joni> no that's the wizard supposed to do
[16:37:22] <SWPadnos_> yep - OK
[16:37:49] <alex_joni> right now it's kinda inbetween
[16:38:02] <alex_joni> dumb version before, very smart version ahead
[16:38:02] <alex_joni> :)
[16:39:35] <SWPadnos_> sleeping version now
[17:52:57] <rayh> before I forget, shutdow of demo_step_cl from tkemc does not shut down the classicladder display
[17:53:37] <SWPadnos_> odd - it did for me
[17:53:49] <SWPadnos_> did you use "emc" or "emc/run"?
[17:53:53] <SWPadnos_> emc.run
[17:53:56] <SWPadnos_> I meant
[17:54:10] <rayh> I think i had to use scripts/emc
[17:54:29] <SWPadnos_> yep - scripts/emc (which should be ./emc, IMO)
[17:55:04] <rayh> scripts/emc demo_step_cl
[17:55:59] <SWPadnos_> yes. I just did that, and all the cl stuff went away as expected
[17:57:05] <rayh> not here at all.
[17:57:10] <SWPadnos_> hm
[17:57:33] <SWPadnos_> odd, even if the RT parts are loaded, you should be able to kill the GUI stuff, right?
[17:57:47] <rayh> just hangs the cleanup waiting for modules to go away.
[17:58:20] <SWPadnos_> ah - OK. there's a module problem, not a cl problem
[17:58:35] <rayh> Shutting down and cleaning up EMC...
[17:58:35] <rayh> Could not kill task classicladder, PID=27997
[17:58:35] <rayh> ERROR: Can't remove RTAI modules, kill the following process(es) first
[17:58:36] <rayh> USER PID ACCESS COMMAND
[17:58:42] <rayh> /dev/rtai_shm root 27997 ....m classicladder
[17:59:04] <SWPadnos_> are the cl windows still there?
[17:59:10] <rayh> yes
[17:59:21] <SWPadnos_> can you close them with the X button?
[17:59:34] <rayh> When I also kill the main cl window it goes on to shutdown complete
[17:59:55] <SWPadnos_> ok - weird
[18:00:03] <chinamill> * chinamill is away: eating
[18:00:30] <rayh> interesting enough, it requires another start attempt to kill off those modules.
[18:00:35] <rayh> then you can restart.
[18:00:38] <SWPadnos_> well - now it's in the logs, someone more knoledgeable than me can see it (like alex or jmk) ;)
[18:01:03] <rayh> If you kill cl display first then it shuts down okay.
[18:01:15] <SWPadnos_> ok, so it can be killed by the script, but not when shutting down the first tiem
[18:02:00] <rayh> This is just about the way the system worked when I was starting cl by hand after starting emc2
[18:02:28] <rayh> we'll let alex work on it.
[18:02:51] <SWPadnos_> yep
[18:03:35] <rayh> chinamill reminded me to eat.
[18:03:38] <rayh> brb
[18:03:43] <SWPadnos_> oh yeah - good plan
[19:24:50] <SWPadnos_> hey Alex - can you take a look at the log, and see if you can tell what causes the problem Ray has?
[19:25:08] <alex_joni> hang on.. what problem?
[19:25:31] <SWPadnos_> classicladder prevents him from exiting emc using the demo_step_cl config
[19:25:46] <SWPadnos_> look at the log, about the last 50-100 lines
[19:26:22] <alex_joni> ok.. that's a simple one ;)
[19:26:33] <SWPadnos_> good. not so imple for me or Ray ;)
[19:26:41] <alex_joni> root 27997 ....m classicladder
[19:26:42] <SWPadnos_> does he need to cvs up or something?
[19:26:44] <alex_joni> it's owned by root
[19:26:48] <SWPadnos_> ah
[19:26:51] <alex_joni> the run script is run by the user
[19:27:01] <alex_joni> probably I missed a sudo where the killing is done ;)
[19:27:12] <alex_joni> might it be safe to do slaughter as root?
[19:27:18] <alex_joni> probably..
[19:27:19] <SWPadnos_> got it - I'm logged in as root on my machine
[19:27:28] <alex_joni> BAD thing ;)
[19:27:45] <alex_joni> but I guess you know that
[19:27:53] <SWPadnos_> yeah - but it's only being used for emc development :)
[19:29:11] <alex_joni> ok.. figured it out completely ;)
[19:29:21] <alex_joni> the classicladder GUI gets started from the hal file
[19:29:35] <alex_joni> but the hal file also has a loadrt component in it
[19:29:54] <alex_joni> emc script scans hal files for loadrt commands, and if that's the case runs them as root
[19:29:58] <alex_joni> so as the insmod won't fail
[19:30:13] <alex_joni> but that means loadusr commands also get run by root
[19:30:16] <SWPadnos_> right
[19:30:24] <alex_joni> which means a kill won't work, unless sudo
[19:36:49] <alex_joni> [21:26] <SWPadnos_> does he need to cvs up or something?
[19:36:52] <alex_joni> now he does ;)
[19:36:56] <SWPadnos_> heh
[19:37:12] <alex_joni> oops.. not yet
[19:37:26] <SWPadnos_> you're too slow ;)
[19:37:31] <alex_joni> got an up-to-date error
[19:38:31] <alex_joni> merging and testing ;)
[19:40:09] <alex_joni> ok.. now he does
[19:40:20] <alex_joni> brb
[19:40:26] <SWPadnos_> ok
[19:57:46] <rayh> hard at work I see.
[19:58:27] <alex_joni> back
[19:58:44] <alex_joni> hi rayh, can you test if it works as expected?
[19:59:11] <rayh> Getting it now.
[20:02:56] <rayh> No difference.
[20:03:26] <alex_joni> hrmmm. that's strange
[20:03:47] <alex_joni> do you have time to explore this a bit more?
[20:03:57] <rayh> certainly.
[20:04:01] <alex_joni> ok..
[20:04:11] <alex_joni> you are running as user, right?
[20:04:25] <rayh> I'm between here and a tree widget sample.
[20:04:34] <rayh> Yes user.
[20:04:36] <alex_joni> 1. lets try the old way. 'sudo scripts/emc demo_step_cl'
[20:04:40] <alex_joni> that should work
[20:04:46] <alex_joni> if that works we'll move on
[20:05:12] <alex_joni> btw.. after cvs up, did you rerun configure? or config.status?
[20:05:27] <SWPadnos_> does it hurt to always 'sudo killtask'?
[20:05:41] <alex_joni> because that's the process of recreating the emc script file
[20:05:49] <alex_joni> SWPadnos_:doesn't hurt.. I think
[20:05:53] <SWPadnos_> heh
[20:05:55] <alex_joni> I added sudo to the -9 part
[20:05:55] <rayh> sudo scripts/emc demo_step_cl works as promised
[20:06:09] <SWPadnos_> ah, ok
[20:06:20] <alex_joni> rayh: my bets that you cvs up'ed and didn't run the src/config.status
[20:06:29] <alex_joni> that way you still have the old emc script
[20:06:39] <rayh> k
[20:06:45] <alex_joni> the 'emc' script gets created by configure from emc.in
[20:07:01] <alex_joni> one more thing.. after running src/config.status it won't be runnable
[20:07:08] <alex_joni> so you need to chmod +x scriptsemc
[20:07:12] <alex_joni> so you need to chmod +x scripts/emc
[20:07:31] <rayh> assume got me again. no new code no need to make or configure
[20:07:33] <alex_joni> that is automatically done by make (if you compile the first time)
[20:07:59] <alex_joni> rayh: the problem is on my side, I should add docs to the wiki
[20:08:17] <SWPadnos_> README in the root and src dires as well
[20:08:21] <SWPadnos_> dirs
[20:08:32] <alex_joni> SWPadnos_: gotcha, doing that now
[20:08:38] <SWPadnos_> kewl
[20:08:45] <rayh> nope no different
[20:09:12] <alex_joni> so you did the chmod +x ?
[20:11:21] <rayh> nope no difference from the before chmod +x
[20:11:36] <rayh> It does behave just a bit different now.
[20:11:41] <alex_joni> how so?
[20:11:54] <rayh> When I close from the tkemc display
[20:12:09] <rayh> it waits until i close cl and then cleans up
[20:12:14] <alex_joni> it will hang for a while (the timeout to the kill)
[20:12:23] <rayh> rather than kicking up an error about not being able to remove modules
[20:12:25] <alex_joni> if you wait a few seconds it will get killed automatically
[20:12:30] <alex_joni> but the timeout is 10 secs
[20:13:58] <alex_joni> the thing is: on shutdown first a normal kill is tried, then if that fails it tries a sudo kill -9
[20:14:16] <alex_joni> and that one succeeds.. maybe sudo on the first would be ok too
[20:14:47] <rayh> you're right
[20:14:58] <alex_joni> on what?
[20:15:08] <alex_joni> I know I usually am.. *evil grin* :D
[20:15:52] <rayh> phone
[20:16:47] <rayh> After about 20 seconds it does shut down the cl interface.
[20:16:56] <alex_joni> 20 is a bit much.. :(
[20:17:02] <alex_joni> I'll add sudo to the first one too
[20:17:32] <rayh> Killall with great prejudice should be the next rmmod option
[20:21:17] <SWPadnos_> alex - is there a good reason for having the run script in the scripts dir (other than the fact that it's a script ;) )?
[20:21:28] <alex_joni> no
[20:21:44] <SWPadnos_> ok - then maybe it should be in the emc dir instead
[20:21:59] <SWPadnos_> anyone who does an ls in that dir would at least see an executable file
[20:22:00] <alex_joni> actually the new one can be anywhere.. it doesn't use relative dirs to find stuff
[20:22:14] <alex_joni> well.. it's not executable at first ;)
[20:22:31] <SWPadnos_> sure, but after it's created by the configure script, it should be
[20:22:39] <SWPadnos_> or make, or whatever
[20:22:46] <alex_joni> not really.. the configure script doesn't do chmod, but make does
[20:22:48] <alex_joni> right
[20:35:52] <alex_joni> so..
[20:35:57] <alex_joni> rayh: care to test again?
[20:40:49] <rayh> phone
[20:41:18] <alex_joni> after the phone :)
[20:41:45] <rayh> cvs up now
[20:42:08] <alex_joni> btw.. added some info to emc2/docs/news
[20:42:24] <alex_joni> woul dbe delighted if you (and everyone else) adds stuff in there
[20:43:17] <alex_joni> even retroactive stuff
[20:43:28] <rayh> down to about 3 seconds delay
[20:44:16] <alex_joni> that's probably caused by something else
[20:44:34] <alex_joni> there shouldn't be a difference from 'sudo scripts/emc' now
[20:44:52] <alex_joni> any other error messages in the console?
[20:45:32] <rayh> none
[20:46:13] <alex_joni> only thing I could still imagine is one of the other processes to run as user now, and not beeing able to access some files (like .var or .tbl)
[20:46:17] <alex_joni> I know tkemc handles .var files directly
[20:47:00] <alex_joni> anyways.. is running 'scripts/emc' slower than 'sudo scripts/emc' ?
[20:47:08] <alex_joni> on the shutdown I mean..
[20:48:52] <rayh> hang on a minute more
[20:49:31] <alex_joni> * alex_joni is in no hurry
[20:57:05] <rayh> okay.
[20:57:23] <rayh> test between sudo and user.
[20:57:40] <alex_joni> * alex_joni reads last nights discussion on the wizard ;)
[20:58:31] <rayh> no difference now between sudo and user startup and shutdown. Good job.
[20:59:32] <alex_joni> great
[20:59:52] <alex_joni> btw.. I noticed on my machine there's a lag on starting mini (opposed to tkemc)
[21:00:15] <alex_joni> runnign scripts/emc starts sim (and sim is configured to run mini right now, along with halscope)
[21:00:52] <rayh> I see that.
[21:01:25] <rayh> Yes. Mini is a linear startup rather than sourcing and then running as needed.
[21:02:16] <alex_joni> I see... well, not bugging me very much.. so I'm not paying much attention to it
[21:03:54] <rayh> I know that I should multi thread it and get the screen up faster.
[21:04:00] <rayh> just have not had the time.
[21:04:17] <alex_joni> ahh.. it's not that important
[21:29:26] <alex_joni> ok.. off to bed
[21:29:30] <alex_joni> night all
[21:30:15] <rayh> Catch you later alex
[21:30:51] <alex_joni> rayh: didn't drop me the tcl stuff jmk did..
[21:31:13] <rayh> ouch sorry I forgot.
[21:31:27] <rayh> let me get there right now.
[21:31:27] <alex_joni> np.. will look tomorrow over it ;)
[21:31:39] <alex_joni> too tired right now, later is fine too
[21:32:33] <alex_joni> night all