#emc-devel | Logs for 2006-02-12

Back
[00:00:01] <jmkasunich> think so
[00:00:12] <cradek> I was thinking you would do shell expansion once
[00:00:14] <jmkasunich> setupconfig cd's to the configs dir to build its list of configs
[00:00:27] <jmkasunich> that need to be revised now that there can be more than one dir
[00:00:28] <cradek> (not a special test for $HOME)
[00:00:31] <jmkasunich> shell expansion?
[00:00:46] <jmkasunich> * jmkasunich is NOT a unix/shell guru or even veteran
[00:00:55] <cradek> yeah, so I can use $HOME or ~ or anything else
[00:01:09] <jmkasunich> how do I do dat?
[00:01:24] <cradek> ummmm
[00:02:35] <cradek> durn tcl
[00:03:07] <cradek> I have no idea
[00:03:17] <cradek> in bash it would just work
[00:04:29] <jmkasunich> will it be expanded before passed to tcl?
[00:05:09] <cradek> no, it has to be expanded at runtime for $HOME etc to work
[00:06:19] <cradek> oh I see what you mean I think, it can be expanded in emc
[00:06:41] <cradek> yeah
[00:06:57] <jmkasunich> yeah, it works
[00:07:03] <jmkasunich> at least from the cmd line
[00:07:10] <jmkasunich> I wrote a tcl prog that just prints argv
[00:07:22] <jmkasunich> test.tcl foo $HOME bar
[00:07:26] <cradek> yeah the shell will expand it before it runs test.tcl
[00:07:39] <jmkasunich> args are:
[00:07:39] <jmkasunich> foo /home/John bar
[00:07:39] <jmkasunich> end of args
[00:07:53] <jmkasunich> dunno about when invoking it from a scripot
[00:07:53] <cradek> we have to make sure emc.in expands it (it's a quoting issue)
[00:08:14] <cradek> likewise we have to make sure configure does NOT expand it
[00:08:25] <jmkasunich> such fun
[00:11:42] <cradek> ok don't worry about expansion in any of the tcl
[00:11:59] <cradek> we'll expand right when invoking the tcl, and never before
[00:12:05] <jmkasunich> hah, I decided that 5 mins ago
[00:12:19] <cradek> ok I'm talking to myself then
[00:12:36] <jmkasunich> I'm going to resolve ./, ../, and symlinks tho
[00:12:38] <cradek> and it was only 3 minutes
[00:12:49] <cradek> symlinks?
[00:12:57] <jmkasunich> default
[00:13:12] <jmkasunich> oh wait, that won't be in the path, that will be an actual config name
[00:13:49] <jmkasunich> should we accept symlinks in the path? (is it a security hole or anything?)
[00:14:58] <cradek> I think you don't know the difference and don't care
[00:15:03] <jmkasunich> ok
[00:15:15] <jmkasunich> I like that kind of answer, less work for me
[00:15:38] <cradek> let symlinks do their job, don't treat them in a special way (this goes for "default" too)
[00:15:52] <jmkasunich> ok
[00:17:05] <cradek> I still don't think you need to do anything to the paths
[00:17:46] <jmkasunich> I want to make sure that everything mentioned in the path is actually a dir
[00:17:57] <jmkasunich> cause later I'm gonna be searching those dirs for subdirs
[00:18:22] <cradek> yeah, you just try to cd to each one, look for emc configs (a dir with an ini and maybe other things in it?)
[00:18:23] <jmkasunich> or am I just making things harder than they need to be?
[00:19:11] <cradek> maybe so
[00:19:27] <jmkasunich> before, when there was only one, I cd'd to it, and did foreach dir_name [ glob */ ] { look for ini files in dir_name }
[00:19:42] <cradek> I think your algorithm is: for each thing in the path, look under it for emc configs
[00:19:53] <jmkasunich> once I cd'd to the config dir I stayed there
[00:19:54] <cradek> yeah same thing, with another foreach around it
[00:20:12] <jmkasunich> now that there are multiples, I'm tempted to use absolute paths
[00:20:24] <jmkasunich> cause once I cd to one, how do I get to the next one if it is relative?
[00:20:41] <jmkasunich> and later on, I need to cd to a specific one
[00:21:02] <cradek> I guess you should not cd
[00:21:30] <jmkasunich> maybe something like foreach dirname [ glob $onedirinpath/*/ ]
[00:21:36] <cradek> yep
[00:22:23] <jmkasunich> foreach onedirinpath $listofpathdirs { foreach dirname [ glob $onedirinpath/*/ ] { check for ini } }
[00:22:28] <cradek> the configs you collect will be full paths, relative or absolute doesn't matter, you'll return one, emc will cd into it
[00:23:09] <cradek> yes I think you want something like that
[00:23:44] <jmkasunich> and it should work even if one of the path dirs is "."
[00:23:51] <cradek> exactly
[00:23:58] <jmkasunich> as long as neither I nor emc cd prior to the search
[00:24:26] <jmkasunich> now, do I need to verify that onedirinpath is actually a dir before I do the glob?
[00:25:12] <jmkasunich> (need as in "will it crash or print a confusing message if I don't")
[00:25:36] <cradek> % set a [glob /dev/null/*/]
[00:25:36] <cradek> no files matched glob pattern "/dev/null/*/"
[00:25:36] <cradek> % set a
[00:25:36] <cradek> can't read "a": no such variable
[00:26:03] <jmkasunich> but also, "should I tell the user he has a bogus path, or silently fail?"
[00:26:31] <cradek> well if we put /usr/local/etc/emc2 in the glob path, we don't want to error if there's nothing there yet
[00:26:32] <jmkasunich> if he makes a typo, should I leave him wondering where his config are, or say "etc/emcc is not a directory"
[00:26:46] <cradek> same for ~/emc2-configs or whatever
[00:26:46] <jmkasunich> glob -nocomplain
[00:26:50] <jmkasunich> (or something like that)
[00:27:06] <cradek> so if the path is invalid somehow, just don't find anything there, and go on
[00:27:12] <jmkasunich> yeah
[00:27:17] <jmkasunich> I guess thats ok
[00:27:30] <jmkasunich> the path won't normally be entered by a user anyway
[00:27:37] <jmkasunich> it comes from the calling script
[00:27:47] <cradek> similarly it's not an error to add /nonexistent to my PATH - I don't expect a warning from my shell every time I run a command
[00:28:05] <jmkasunich> ok - that is good reasoning
[00:28:07] <cradek> it's just a search path, just like we have
[00:32:06] <jmkasunich> ok, one more check that maybe isn't needed
[00:32:20] <jmkasunich> what if they don't specify the --configs-path at all?
[00:32:36] <jmkasunich> complain at them, or just display a list of zero configs?
[00:32:37] <cradek> "they" is the emc script, so it will
[00:33:12] <jmkasunich> unix principle - when you write a program, it will be called by folks that you didn't expect to call it
[00:33:18] <cradek> if you don't find any configs for whatever reason, maybe spew an error to stderr, and exit with a failure exit code I guess
[00:33:47] <cradek> I agree giving an empty list to the user and expecting him to do something useful with it is kind of silly
[00:34:32] <jmkasunich> right now it pops up a dialog "ERROR: blah, blah hit OK to exit", then returns failure
[00:34:40] <jmkasunich> is stedrr better or worse?
[00:34:50] <jmkasunich> stderr even
[00:35:07] <jmkasunich> if they invoke from a icon or menu, they'll never see stderr
[00:35:09] <cradek> I guess I have no preference
[00:35:30] <jmkasunich> that could be good or bad ;-) (the fact that they don't see it, not your lack of preference)
[00:35:33] <cradek> if they invoke from the menu, you'll be coming from the emc script
[00:35:48] <cradek> if they invoke bogusly from the shell, either error method is fine
[00:35:59] <jmkasunich> stderr is less bloaty then
[00:36:12] <cradek> ok
[00:36:34] <cradek> and return 1
[00:36:43] <cradek> starving, off to make dinner
[00:36:48] <jmkasunich> 1 or -1?
[00:37:06] <jmkasunich> another convention I'm not familiar about, I was using -1 to indicate failure
[00:37:26] <cradek> in the shell, 0 is success, >0 is failure
[00:37:36] <jmkasunich> so 1 is preferred
[00:37:37] <jmkasunich> ?
[01:14:25] <cradek> back
[01:15:05] <cradek> 1 is usually used as a basic error result, but you can use other numbers if you have multiple error types to report
[01:15:36] <cradek> sometimes I use a different small integer at every place my program can return an error
[02:10:41] <jmkasunich> ok, here is one of those "is it overengineering?" questions
[02:11:04] <jmkasunich> it looks for the logo in three places
[02:11:23] <jmkasunich> if it isn't in any of those places, it just blindly continues
[02:11:42] <jmkasunich> later one, it crashes with a "can't read logo, no such variable"
[02:11:55] <jmkasunich> IMO, not finding the logo should be tested for
[02:12:24] <jmkasunich> granted, if I was running it installed, and from the right place, the search would probably succeed
[02:12:29] <cradek> should not finding the logo be fatal?
[02:12:43] <jmkasunich> dunno
[02:13:01] <jmkasunich> doesn't seem like it should, the world won't end if there's no logo ;-)
[02:13:31] <jmkasunich> but it certainly shouldn't crash
[02:14:35] <cradek> I agree
[02:18:06] <jmkasunich> probalbly shoud create a blank image if it doesn't find the one its looking for
[02:18:37] <cradek> OTOH if it just fails, we'll get an error report and we can fix the logo installation problem
[02:19:31] <jmkasunich> assuming the user reports the error instead of grumbling and saying "this is shit" and walking away
[02:19:45] <jmkasunich> anyway, not what I should concentrate on right now
[02:19:50] <cradek> well we'll test it in our packages
[02:19:54] <jmkasunich> when I run it from the right place it works
[02:20:00] <cradek> ok
[02:22:08] <jmkasunich> but that is a typical example - should we assume that it will be run from the right place, and let it crash if not
[02:22:22] <jmkasunich> or should we add error detection and handling code and bloat it?
[02:23:05] <cradek> if our script is always going to run it, and an error means there's a problem with our script that needs to be fixed, we should allow the error.
[02:23:14] <jmkasunich> ok
[02:23:32] <cradek> if the user is meant to run it, and he runs it incorrectly, we should tell him what he's done wrong
[02:23:52] <jmkasunich> I think its the former case
[02:24:01] <cradek> if the user digs around and runs things we don't intend him to do, and they break, he gets to keep both pieces
[02:24:20] <jmkasunich> heh
[02:24:26] <cradek> without giving it much thought, I think this is how we should decide
[02:28:18] <jmkasunich> sounds good to me
[02:49:18] <jmkasunich> we never decided what to do if there were configs with the same name in more than one dir in the path
[02:49:33] <jmkasunich> if we've been asked to find config "foo" we return the first foo
[02:49:44] <jmkasunich> but if I'm making a list for the user to choose from?
[02:50:23] <cradek> I guess you'll have to show the directory somehow
[02:50:30] <cradek> but in a listbox that's going to be janky
[02:50:31] <jmkasunich> ick
[02:51:09] <jmkasunich> it is tempting to suppress duplicates, but that might confuse people
[02:51:20] <jmkasunich> displaying both with nothing to distinguish sucks too
[02:51:40] <cradek> yeah.
[02:51:48] <jmkasunich> hmm, when you click on one it displays the details (README file)
[02:51:58] <jmkasunich> I could also display the full path to the selected on
[02:51:59] <jmkasunich> one
[02:52:13] <cradek> that's true
[02:52:40] <cradek> you know, they could be in a tree like halconfig has
[02:52:42] <jmkasunich> so you might have two "foo"s, but click on one and it shows /etc/emc2/foo, click the other it shows /home/John/emc2/foo
[02:53:00] <cradek> it would default to all the nodes being open
[02:53:10] <cradek> each path item would be a node
[02:53:25] <cradek> (no idea how hard this is)
[02:53:36] <jmkasunich> that means I have to learn how to use that bwidget thing
[02:53:37] <cradek> but that's a way to show a heirarchy
[02:53:45] <jmkasunich> this is limited to one level anyway
[02:54:25] <cradek> you could show and hide different parts of the path
[02:54:33] <jmkasunich> lemme see what it would look like:
[02:54:44] <jmkasunich> /etc/emc2
[02:54:46] <jmkasunich> foo
[02:54:48] <jmkasunich> bar
[02:54:49] <jmkasunich> blat
[02:55:01] <jmkasunich> /home/John/emcdev/emc2head/configs
[02:55:06] <jmkasunich> foo
[02:55:08] <jmkasunich> stepper
[02:55:10] <jmkasunich> sim
[02:55:38] <jmkasunich> except it would do a better job of column alignment
[02:55:42] <cradek> haha
[02:56:38] <jmkasunich> are the configs installed directly in /etc/emc2/ ? or below, like /etc/emc2/configs/ ?
[02:57:06] <cradek> /etc/emc2/configname/config.ini
[02:57:17] <jmkasunich> so directly in emc2
[02:57:25] <jmkasunich> I consider each subdir a config
[02:57:31] <cradek> I'm just rewriting that - should we change it?
[02:57:37] <jmkasunich> dunno
[02:57:44] <cradek> there is currently other crap in /etc/emc2
[02:57:54] <cradek> it would be nice if you could get the names of the configs with one glob
[02:58:01] <jmkasunich> I just was looking at my tree sample, and thought it might be nice if the dir was /etc/emc2/samples
[02:58:15] <cradek> I can sure do that
[02:58:17] <cradek> let's do
[02:58:29] <jmkasunich> should it be samples or sample-configs?
[02:58:38] <cradek> up to you
[02:58:45] <jmkasunich> samples might be g-code samples
[02:58:52] <jmkasunich> (unless they are elsewhere)
[02:59:02] <cradek> true
[02:59:06] <cradek> /etc/emc2/sample-configs
[02:59:35] <jmkasunich> I really don't want to learn that tree widget tho :-/
[03:01:21] <cradek> I bet it's not too bad as long as you only have to populate it once, and get a string out of it when you click
[03:01:24] <cradek> I'll help if you want
[03:01:33] <cradek> I think I've (painstakingly) finished make install
[03:01:50] <jmkasunich> I never turn down help
[03:02:03] <cradek> give me a minute to finish this up and check it in
[03:06:21] <cradek> darnit, now everyone will know I understand the new Makefile too
[03:18:08] <jmkasunich> you know we're gonna have a shitstorm for the next few days from all the folks who have been experimenting with RIP
[03:19:02] <cradek> yes, but I refuse to stop progress just so we never briefly break anything
[03:19:27] <jmkasunich> we should have "semi-stable" tarballs or tags
[03:19:40] <cradek> I have debs...
[03:19:57] <jmkasunich> will they work on skunkworks box?
[03:20:04] <jmkasunich> I dunno what he has
[03:20:10] <jmkasunich> maybe that is the answer for him
[03:20:23] <cradek> whatever he was running yesterday is probably his answer
[03:20:36] <jmkasunich> I think he deleted that
[03:23:25] <cradek> we could have a FRIDAY tag that we move along every week :-)
[03:24:20] <jmkasunich> heh
[03:24:36] <cradek> hmm, I guess there's no point since you can specify a date
[03:24:41] <cradek> forget it
[03:24:47] <jmkasunich> how about (seriously) USABLE
[03:25:03] <jmkasunich> or something like that
[03:25:08] <cradek> yeah, we could sure do that if we intended to break it soon
[03:25:28] <cradek> dh_movefiles: debian/tmp/usr/realtime-2.6.12-magma/modules/emc2/extint.ko not found (supposed to put it in emc2)
[03:25:29] <jmkasunich> we always intend to break it soon
[03:25:31] <cradek> dh_movefiles: debian/tmp/usr/realtime-2.6.12-magma/modules/emc2/fifotask.ko not found (supposed to put it in emc2)
[03:25:34] <cradek> dh_movefiles: debian/tmp/usr/realtime-2.6.12-magma/modules/emc2/master.ko not found (supposed to put it in emc2)
[03:25:37] <cradek> dh_movefiles: debian/tmp/usr/realtime-2.6.12-magma/modules/emc2/shmemtask.ko not found (supposed to put it in emc2)
[03:25:40] <cradek> dh_movefiles: debian/tmp/usr/realtime-2.6.12-magma/modules/emc2/slave.ko not found (supposed to put it in emc2)
[03:25:43] <cradek> dh_movefiles: debian/tmp/usr/realtime-2.6.12-magma/modules/emc2/timertask.ko not found (supposed to put it in emc2)
[03:25:46] <cradek> do you know if these are used?
[03:26:07] <jmkasunich> those look like the RTPAI examples
[03:26:21] <cradek> ok, I don't think we're building them right now
[03:26:35] <jmkasunich> before the rebuild, make didn't build them, you had to do make examples
[03:26:40] <jmkasunich> I suspect that is still true
[03:27:05] <jmkasunich> "rebuild" = jeplers changes
[03:27:27] <jepler> now there are no rules to build them, since as far as I could tell they weren't used
[03:27:41] <jmkasunich> bummer
[03:27:42] <jepler> SMOP to fix that though
[03:28:04] <cradek> jepler: don't touch the makefile right now
[03:28:17] <cradek> jepler: almost done with make install
[03:28:21] <jepler> cradek: ok
[03:28:24] <jmkasunich> "for god's sake man, don't touch it!!!"
[03:28:39] <jepler> * jepler commits before chris, leaving him with tons of conflicts
[03:28:48] <cradek> I guess it would be no big deal, but it would be better to wait an hour
[03:29:17] <cradek> dh_movefiles: debian/tmp/usr/bin/fifousr not found (supposed to put it in emc2)
[03:29:19] <jmkasunich> for some reason an image of the mad scientist guy from Back to the Future flashed thru my head
[03:29:19] <jepler> not planning to do anything more to emc tonight
[03:29:21] <cradek> dh_movefiles: debian/tmp/usr/bin/hal_parport not found (supposed to put it in emc2)
[03:29:24] <cradek> dh_movefiles: debian/tmp/usr/bin/hal_skeleton not found (supposed to put it in emc2)
[03:29:27] <cradek> dh_movefiles: debian/tmp/usr/bin/shmemusr not found (supposed to put it in emc2)
[03:29:30] <cradek> how about these?
[03:29:32] <cradek> are they used?
[03:29:42] <jmkasunich> parport and skeleton are user space versions of the drivers
[03:29:50] <jepler> I grepped them in scripts/, didn't find them used
[03:30:01] <jepler> again, I didn't write the rules to build them
[03:30:06] <jmkasunich> they were an exercise to prove that you can make user and rt hal modules from the same source
[03:30:10] <jmkasunich> not used by emc at this time
[03:30:29] <jmkasunich> shmemusr sounds like the user space part of the RTAPI shmem example
[03:30:52] <cradek> jepler: I'm not getting librs274.a either
[03:30:57] <jepler> cradek: oops, it's now .so
[03:31:05] <cradek> ah, np
[03:31:37] <jmkasunich> jepler: it would be nice to have a rule for skeleton
[03:32:01] <jmkasunich> (as a sample for folks who do want to make a dual mode hal component
[03:32:11] <jmkasunich> skeleton is intended as an example
[03:32:21] <cradek> maybe we should put that stuff in a different makefile
[03:32:36] <cradek> this one's getting big enough without stuff that is not strictly needed for building emc
[03:32:59] <jmkasunich> well in the long run it might be a good idea to move all of rtapi out of emc and into the kernel package
[03:33:06] <jmkasunich> but that isn't something to do in 2.0
[03:33:42] <jmkasunich> or something to do without a lot of thought about the implications of the move
[03:34:30] <jmkasunich> how much does hal_skeleton add to the makefile? its a one-sourcefile program?
[03:34:32] <jepler> jmkasunich: good point (there is a 'Submakefile.skel', but that's geared towards building a userspace thing)
[03:34:59] <jmkasunich> the userspace one is the one that was missing I think
[03:35:12] <jmkasunich> debian/tmp/usr/bin/hal_skeleton
[03:35:46] <jmkasunich> the RT version is a kernel module, I bet its already getting built
[03:36:03] <jmkasunich> with all the other HAL RT modules
[03:36:11] <jepler> src/Submakefile.skel is an example of making a userspace file which links with libemc and libnml
[03:36:28] <jmkasunich> oh, that has nothing to do with hal_skeleton
[03:37:19] <cradek> dpkg-deb: building package `emc2' in `../emc2_2.0.0-alpha17_i386.deb'.
[03:37:19] <cradek> dpkg-deb: building package `emc2-dev' in `../emc2-dev_2.0.0-alpha17_i386.deb'.
[03:37:19] <jmkasunich> hal_skeleton is in src/hal/drivers
[03:37:24] <cradek> ahhhhhh
[03:37:29] <cradek> we have debs again
[03:37:29] <jmkasunich> everything in there is built into kernel modules
[03:37:42] <jmkasunich> but skeleton and parport can also be built as userspace programs
[03:38:02] <jmkasunich> the new make was probably unaware of that
[03:38:21] <jepler> obj-$(CONFIG_HAL_SKELETON) += hal_skeleton.o
[03:38:21] <jepler> hal_skeleton-objs := hal/drivers/hal_skeleton.o
[03:38:35] <jepler> I do build hal-skeleton the realtime module
[03:38:47] <jmkasunich> thought so
[03:38:53] <jmkasunich> but not the user version
[03:39:20] <jepler> does the user version require special flags or libraries?
[03:39:25] <jmkasunich> the difference is -DRTAPI vs -DULAPI
[03:39:58] <jmkasunich> ALL RT code should have -DRTAPI, and all user code that might use HAL or RTAPI APIs should have -DULAPI
[03:40:49] <jmkasunich> the user skeleton links with rtapi and hal libs
[03:41:04] <jmkasunich> (not really libs, just objs)
[03:42:19] <jepler> objects/hal/drivers/hal_skeleton.o: In function `main':
[03:42:19] <jepler> hal/drivers/hal_skeleton.c:261: undefined reference to `hal_init'
[03:42:19] <jmkasunich> here is the old rule for building them:
[03:42:23] <jmkasunich> # rule to link single module binaries (user space versions of drivers)
[03:42:24] <jmkasunich> $(BIN_DIR)/% : $(TMP_DIR)/%.o $(LIB_DIR)/ulapi.o $(LIB_DIR)/hal_lib.o
[03:42:24] <jmkasunich> @ echo "Linking user space driver $@"
[03:42:25] <jmkasunich> $(CC) $(CFLAGS) $(ULFLAGS) $^ -o $@
[03:42:29] <jepler> ah, hal_lib
[03:42:52] <jepler> $ ../bin/hal_skeleton
[03:42:52] <jepler> SKELETON: ERROR: could not get I/O permission
[03:43:05] <jmkasunich> yeah, it does ioperm, needs to run sudo
[03:43:30] <jmkasunich> like I say, we don't actually use it, its an educational tool
[03:43:51] <jmkasunich> the kernel module version has no probs getting IO access ;-)
[03:50:23] <cradek> -rwsr-x--- root/root 5820 2006-02-11 21:49:23 ./usr/bin/emc_module_helper
[03:50:54] <cradek> looks like I'll have to install 4755 for the deb since it changes it to root/root
[04:01:48] <jmkasunich> didn't even realize I was on the main channel
[04:01:53] <jmkasunich> I have one item in my tree now
[04:01:57] <jmkasunich> woot!
[04:02:52] <jmkasunich> ok, a strange mix of rays code and the web example, and I think I see how to build
[04:03:04] <cradek> cool
[04:03:11] <cradek> I finally found "Tree" in the code hahaha
[04:03:13] <jmkasunich> I get a crash on shutdown, probalby not destroying something properly
[04:03:36] <jmkasunich> set treew [ Tree blah blah?
[04:03:58] <jmkasunich> line 402
[04:04:17] <jmkasunich> I copied those 6 lines and changed a few names
[04:04:27] <jmkasunich> no idea what it actually does, I hate that
[04:04:40] <jmkasunich> also had to copy proc sSlide
[04:05:39] <jmkasunich> absolutely no idea what "$treew bindText <Button-1> {workMode }" is all about
[04:07:05] <cradek> I bet that means when you click on the text with the left button, it calls workMode
[04:07:18] <jmkasunich> could be
[04:07:36] <jmkasunich> trying a loop to add the configs now
[04:07:38] <cradek> yes that's it
[04:10:16] <jmkasunich> how do you get the path part of a filename
[04:10:21] <jmkasunich> file tail gets you the name
[04:10:31] <jmkasunich> file split gets you all the pieces
[04:10:33] <cradek> file dirname
[04:10:38] <jmkasunich> duh
[04:10:57] <cradek> * cradek figured out how to install the tcl manpages
[04:12:00] <jmkasunich> drat, it doesn't like duplicate nodenames
[04:12:32] <jmkasunich> solved - use the complete name for the nodename, the tail for -text
[04:12:45] <jmkasunich> ok, I got a tree
[04:12:48] <cradek> wow
[04:12:59] <jmkasunich> defaults to closed, I want it open
[04:13:07] <jmkasunich> and I'm not properly shutting it down
[04:13:21] <jmkasunich> I close the window (click the upper right X) and it crashes
[04:13:40] <jmkasunich> inside Tree:L_destroy
[04:13:51] <jmkasunich> Tree::_destroy
[04:14:33] <jmkasunich> dunno if the scrolling is right, I'm just sticking it in my main window right now, plenty of space
[04:15:43] <cradek> $tree insert end ..... -open 1
[04:16:47] <jmkasunich> that worked
[04:17:26] <cradek> how does it look?
[04:17:50] <jmkasunich> not bad
[04:17:51] <cradek> you know, if you sometimes have multiple inis, you do have another level in the tree
[04:18:14] <jmkasunich> yeah
[04:18:27] <jmkasunich> it is gonna be a little interesting dealing with user clicks
[04:18:36] <jmkasunich> if they click a config, display the details (readme)
[04:18:37] <cradek> as soon as the right thing (a leaf on the tree) is clicked, you can highlight it, then ungray the OK button
[04:18:42] <jmkasunich> but what if they click a directory?
[04:18:48] <cradek> don't do anything
[04:19:20] <cradek> or open/close it (I'm not sure how trees with unselectable things usually work)
[04:19:21] <jmkasunich> oh, I need to do the hightlight myself
[04:19:26] <cradek> yeah probably
[04:19:42] <jmkasunich> ok (the previous one used a listbox, it had selection built in)
[04:19:46] <cradek> ah
[04:20:00] <cradek> the previous one was keyboardable too, which was nice
[04:20:09] <cradek> but that's phase II if it isn't built in
[04:20:52] <jmkasunich> right now there is a top level entry for every dir inthe path even if the dir has no configs in it
[04:21:01] <jmkasunich> (even if the dir doesn't exist)
[04:21:08] <jmkasunich> I could probably fix that
[04:21:25] <jmkasunich> gotta get the basics down first
[04:21:33] <cradek> if [ file doesn't exist ] { continue }
[04:21:36] <cradek> or something
[04:21:53] <jmkasunich> well right now I have two lists, one of dirs, another of configs
[04:21:54] <cradek> wonder what causes your crash
[04:22:17] <jmkasunich> I'm probably not shutting the event loop down right
[04:22:35] <cradek> you did find file:///usr/share/doc/bwidget/html/Tree.html right?
[04:22:57] <cradek> it's their sorry excuse for not having a man page
[04:22:58] <jmkasunich> bet it reads alot like http://tcllib.sourceforge.net/BWman/Tree.html
[04:23:07] <cradek> I bet you're right
[04:23:22] <jmkasunich> I found the -open same time as you did ;-)
[04:24:12] <jmkasunich> right now I'm using the top window generation code that jepler added to setupconfig
[04:24:24] <jmkasunich> (fixed size window, chips on the left)
[04:24:56] <jmkasunich> I don't think I want to use my wizard_page thing
[04:25:09] <jmkasunich> I'm not gonna be running thru a sequence of pages here
[04:25:13] <cradek> cool
[04:25:24] <cradek> one fixed window is nice and simple
[04:25:27] <jmkasunich> but I'm kinda at a loss hat to do instead
[04:25:36] <cradek> what part?
[04:26:03] <jmkasunich> I need to display the tree, and a box for the readme info
[04:26:13] <jmkasunich> and some messages
[04:26:20] <jmkasunich> "please pick a configuration to run"
[04:26:49] <jmkasunich> if I use don't use another tree level to handle multiple inis in a config, then I need another screen to do that
[04:27:01] <cradek> I think you definitely want to use another tree level
[04:27:12] <cradek> the tree lets you browse everything in a familiar way
[04:27:36] <jmkasunich> so then the actual config names would NOT be clickable, only the ini names below them
[04:27:47] <cradek> yes
[04:27:55] <cradek> or, if there's only one, you might choose not to show it
[04:28:06] <jmkasunich> and make the config name clickable
[04:28:10] <jmkasunich> I can handle that
[04:28:14] <cradek> but by highlighting only when a valid thing is chosen, the user learns through exploration how it works
[04:28:49] <jmkasunich> the readme display won't change if you click stepper_inch, then stepper_mm
[04:28:56] <jmkasunich> but if they are named right thats ok
[04:29:02] <jmkasunich> if they are named dumb, too bad
[04:29:03] <cradek> agreed
[04:29:25] <cradek> we know ours are named well; if the user does differently it's his own dumb fault
[04:29:32] <jmkasunich> actually, if there are multiple inis, the readme should explain them
[04:30:06] <cradek> ouch I want to get off on a tangent
[04:30:06] <jmkasunich> ok, I'm gonna redo my "build a list of configs" code
[04:30:08] <cradek> ouch ouch ouch
[04:30:19] <jmkasunich> ouch?
[04:30:33] <cradek> that's me trying not to complain about the inch/mm inis
[04:30:50] <jmkasunich> mechanism, not policy
[04:31:05] <cradek> I'll save it for another day
[04:31:07] <jmkasunich> this tool will display them if they're there, thats all
[04:31:07] <cradek> sorry
[04:31:27] <jmkasunich> on the good side - setupconfig will use the same tree to select the template
[04:31:46] <jmkasunich> that means you must select a specific ini as a template, so your new config will have only one
[04:31:50] <cradek> that will be nice
[04:31:55] <jmkasunich> unless you go outside the system to put another in there
[04:32:03] <cradek> also it removes a whole window
[04:32:08] <cradek> window/step
[04:32:13] <jmkasunich> yes
[04:32:23] <jmkasunich> I really like the idea of using another tree level
[04:32:26] <cradek> me too
[04:32:35] <cradek> this is a clever solution to the mess we started with
[04:32:52] <jmkasunich> now I just have to figure out how to split the window up for messages/instructions, tree, and readme display
[04:33:30] <cradek> in general, you have to make frames, pack them with the packer, put widgets in them
[04:33:41] <cradek> or do you know that? I'm not sure which part you're asking about
[04:33:43] <jmkasunich> yeah, I did that on setupconfig
[04:34:07] <jmkasunich> but I never tried to say "use 1/3 of the screen for this, and 1/2 for that, and 1/6 for this"
[04:34:21] <cradek> ah I see
[04:34:22] <jmkasunich> I just let tk resize to fit the contents
[04:34:35] <jmkasunich> jepler is the one who made it fixed size
[04:34:44] <jmkasunich> and I haven't looked at it much since he did that
[04:35:05] <jmkasunich> I'm starting to get the hang of tcl, but tk is still iffy
[04:35:16] <cradek> installing tk man pages now...
[04:36:21] <cradek> I think things have a requested dimension
[04:36:29] <cradek> you can make them bigger with pack -expand and pack -fill
[04:36:52] <cradek> so you don't have to set sizes, you just have to say which things should be expanded larger than their minimum requested size
[04:37:30] <jmkasunich> I want fixed fractions of the window
[04:37:40] <jmkasunich> say top 1/4 for messages/instructions
[04:37:47] <jmkasunich> middle 1/2 for the tree
[04:37:58] <jmkasunich> bottom 1/4 for the readme
[04:38:11] <cradek> I don't think that's what you want - if you make the window taller, you want only the tree to expand
[04:38:13] <jmkasunich> and the fifth fourth for the buttons ;-)
[04:38:27] <cradek> you sure don't want the size around the buttons to expand, for instance
[04:38:28] <jmkasunich> jepler made the main window fixed size
[04:38:37] <jmkasunich> so I don't have to worry about that
[04:38:51] <jmkasunich> (I think he did it to match the picture of chips)
[04:38:58] <cradek> yes, probably
[04:39:09] <jmkasunich> this is the main window code:
[04:39:14] <jmkasunich> # make a toplevel and a master frame.
[04:39:14] <jmkasunich> wm title . [msgcat::mc "EMC2 Configuration Selector"]
[04:39:14] <jmkasunich> set logo [label .logo -image $logo]
[04:39:15] <jmkasunich> set top [frame .main -borderwidth 0 -relief flat ]
[04:39:15] <jmkasunich> # want these too, but on windoze they cause an error? -padx 10 -pady 10 ]
[04:39:16] <jmkasunich> pack $logo -side left -anchor nw
[04:39:17] <jmkasunich> pack $top -side left -expand yes -fill both
[04:39:18] <jmkasunich> wm geo . 780x480
[04:39:21] <jmkasunich> wm resiz . 0 0
[04:39:33] <jmkasunich> that pads line should go away
[04:39:47] <jmkasunich> that is a vestige of me developing on my doze box at work
[04:39:54] <cradek> are you going to have the same logo?
[04:40:00] <jmkasunich> yes
[04:40:20] <jmkasunich> changed the window title from Configuration Manager to Configuration Selector, but otherwise the same
[04:42:06] <jmkasunich> I don't think I want to show dirs in the path if they have no configs in them
[04:42:23] <cradek> I agree that would be confusing
[04:43:14] <cradek> if you really want fixed sizes, I think you can use place instead of pack
[04:43:30] <jmkasunich> I'm not sure
[04:43:48] <jmkasunich> I decided to fix the tree build code to handle inis, then go back to the screen layout
[04:44:54] <cradek> you could even leave that for jepler, he'll be unable to leave it alone if it's ugly
[04:45:03] <jmkasunich> lol
[04:45:07] <jmkasunich> I like that
[04:45:10] <cradek> oh no, is he still in the channel? crap
[04:45:11] <cradek> haha
[04:45:41] <cradek> now he'll know my secret
[05:04:31] <jmkasunich> ok, I got the tree to build right
[05:04:35] <jmkasunich> after much swirling
[05:04:37] <cradek> allright
[05:04:48] <jmkasunich> I don't think I'll ever get used to $ and set
[05:05:15] <cradek> yeah
[05:05:26] <cradek> it's different in perl, it's different in sh, it's different in make
[05:12:06] <jmkasunich> gotta admit the tree widget it nice
[05:12:19] <jmkasunich> wish I could pop up a screenshot for you to see
[05:12:44] <cradek> yeah I wish you had working dcc
[05:12:53] <cradek> email it to me?
[05:17:15] <jmkasunich> http://home.att.net/~jmkasunich/Pics/picker_screenshot_1.png
[05:17:30] <jmkasunich> clicking on any entry returns the path
[05:17:37] <jmkasunich> if it ends in .ini, then it is legit
[05:17:51] <jmkasunich> if not, its a dir and they need to click at a lower level
[05:18:09] <cradek> cool!
[05:18:27] <cradek> I bet we can put some icons in there to help explain it
[05:18:30] <jmkasunich> should sort the entries
[05:18:32] <cradek> like folders
[05:18:55] <jmkasunich> we'll let jepler do that ;-)
[05:19:02] <cradek> right, of course
[05:19:25] <jmkasunich> buttons.... what buttons should this have
[05:19:31] <jmkasunich> ok and cancel?
[05:19:38] <cradek> OK/Cancel
[05:19:41] <jmkasunich> ok becomes enabled when they click a usable one
[05:19:52] <cradek> yeah
[05:20:00] <cradek> as well as highlighting it (setting its background color)
[05:20:00] <jmkasunich> ok, buttons at the bottom
[05:20:15] <jmkasunich> above that the text box (scrollable) for the readme
[05:20:16] <cradek> yes, bottom right
[05:20:21] <jmkasunich> above that the tree, also scrollable
[05:20:31] <jmkasunich> on top a box for messages/instructions
[05:20:49] <cradek> the tree could stay where it is
[05:20:55] <jmkasunich> the messages might be static (I originally thought it would be a multi-step process
[05:21:09] <cradek> I am not sure a message/instruction is required
[05:21:27] <jmkasunich> this is the very first thing a user will see
[05:21:34] <jmkasunich> including an aunt tillie user
[05:21:42] <cradek> ok
[05:22:16] <jmkasunich> I guess the cancel button should be next
[05:22:25] <jmkasunich> fix that crash on close
[05:22:54] <cradek> bind $cancel {system kill -9 $$}
[05:23:07] <cradek> sorry
[05:23:15] <cradek> getting late
[05:23:21] <jmkasunich> it is
[05:24:05] <jmkasunich> bind . <Escape> {button_pushed OK}
[05:24:05] <jmkasunich> bind . <Return> {button_pushed OK}
[05:24:13] <jmkasunich> is that how he made the keyboard work?
[05:24:26] <jmkasunich> wm protocol . WM_DELETE_WINDOW {button_pushed OK}
[05:24:34] <jmkasunich> and that handles the X in the top right?
[05:25:04] <cradek> yes
[05:25:17] <cradek> but you don't want it to call the thing that Cancel calls
[05:25:19] <cradek> err
[05:25:24] <cradek> but you want it to call the thing that Cancel calls
[05:25:26] <jmkasunich> I do want it to call cancel
[05:26:56] <jmkasunich> hmm, new stuff...
[05:27:05] <jmkasunich> button_depends_on_variable
[05:35:56] <jmkasunich> ok, I got a couple buttons
[05:36:13] <jmkasunich> but for some reason the tree now gets scrunched into a small box
[05:36:36] <jmkasunich> (I expected it to squish vertically, but it is also squished horizontally)
[05:36:40] <cradek> must have the frames/expands/fills wrong
[05:37:05] <cradek> maybe you need a -fill x somewhere
[05:37:16] <jmkasunich> # build the tree widgets left side
[05:37:16] <jmkasunich> set treew [Tree $f1.t -width 10 -yscrollcommand "sSlide $f1" ]
[05:37:16] <jmkasunich> set str $f1.sc
[05:37:17] <jmkasunich> scrollbar $str -orient vert -command "$treew yview"
[05:37:18] <jmkasunich> pack $str -side right -fill y
[05:37:18] <jmkasunich> pack $treew -side right -fill both -expand yes
[05:37:18] <jmkasunich> $treew bindText <Button-1> { node_clicked }
[05:37:21] <jmkasunich> pack $f1
[05:37:53] <jmkasunich> I bet I need fill and expand on the pack f1
[05:37:55] <cradek> $f1 configure -fill x
[05:38:04] <cradek> yeah whatever the format is
[05:38:33] <jmkasunich> better
[05:41:39] <lilo> [Global Notice] Hi all. If you're interested in tracking the near term winter storms and blizzard conditions in the northern US, you might try ##earth .... it's not that busy at the moment, but you can make it so. :)
[05:41:58] <jmkasunich> hmm, it almost looks better with the tree on the side instead of above the readme box
[05:42:29] <cradek> I thought it might (that's the main thing jepler changed on the old setupconfig)
[05:42:55] <cradek> I think screens with a wide aspect ratio (like our monitors) are generally more pleasing
[05:43:42] <cradek> and a left-to-right flow is just as natural as top-to-bottom
[05:44:54] <cradek> also trees are usually on the left, think of any modern mailreader, windows explorer, the firefox bookmark manager, etc
[05:45:00] <jmkasunich> right
[05:45:07] <jmkasunich> doing that now
[05:51:49] <jmkasunich> ok, got tree on left, text box on right
[05:51:54] <jmkasunich> but the tree is too narrow
[05:53:31] <cradek> Tree -width xxx
[05:53:40] <cradek> Specifies the desired width for the tree in units of 8 pixels.
[05:54:54] <jmkasunich> better
[05:56:09] <jmkasunich> ok, tree is wide enough
[05:56:23] <jmkasunich> both tree and text box are only about 1/3 of the window high
[06:00:36] <jmkasunich> better
[06:00:47] <cradek> you keep saying that - it must be really good by now
[06:02:47] <cradek> against all odds, my cvs tree compiles and runs
[06:02:56] <jmkasunich> against all odds?
[06:03:23] <cradek> yeah, I kind of feel that way, we've changed so much lately
[06:03:39] <cradek> I still want to change halcmd, but was sidetracked
[06:08:22] <jmkasunich> http://home.att.net/~jmkasunich/Pics/picker_screenshot_2.png
[06:08:35] <jmkasunich> just need to add instructions on top
[06:08:51] <cradek> wow, that's looking great
[06:09:10] <jmkasunich> button locations OK? or should they be to the right?
[06:09:21] <cradek> I think they should be at the right
[06:10:59] <jmkasunich> fixed ;-)
[06:12:20] <cradek> is it almost done? looks like you have most things working already
[06:12:28] <jmkasunich> only the shiny parts
[06:12:36] <jmkasunich> the greasy parts still need work
[06:12:55] <jmkasunich> (making things happen when you click for instance)
[06:13:01] <cradek> ah right
[06:19:13] <jmkasunich> from the man page for -wraplength:
[06:19:14] <jmkasunich> The value may be specified in any of the standard forms for screen distances.
[06:19:21] <jmkasunich> do you know what the standard forms are?
[06:19:34] <cradek> what's wraplength?
[06:19:38] <jmkasunich> never mind, figured it out
[06:19:46] <jmkasunich> word wrapping inside labels
[06:20:07] <cradek> no, no idea
[06:33:56] <cradek> I'm off to bed john... talk to you tomorrow
[06:34:06] <jmkasunich> wait one sec
[06:34:19] <cradek> ok
[06:34:31] <jmkasunich> http://home.att.net/~jmkasunich/Pics/picker_screenshot_3.png
[06:34:45] <jmkasunich> what do you think of the wording?
[06:36:25] <cradek> the only change I would suggest would be to pick Choose/chosen or Select/selected and be consistent
[06:36:43] <jmkasunich> good point
[06:36:47] <jmkasunich> Select?
[06:37:04] <cradek> I have no preference
[06:37:10] <jmkasunich> select it is
[06:37:46] <cradek> also you may want to lose the first "to run"
[06:38:04] <jmkasunich> goodnight, and thanks for all the help
[06:38:06] <jmkasunich> yes
[06:38:11] <cradek> I stumble on the sentence a bit with that in there
[06:38:22] <cradek> and you say "to run" later
[06:38:29] <jmkasunich> agreed
[06:39:01] <cradek> goodnight, and you're welcome - I think this is looking great
[06:39:03] <jmkasunich> the first time the wordwrapping just happended to coincide with sentences
[06:39:21] <jmkasunich> now that the first is shorter, the word Details appears on the first line
[06:39:35] <jmkasunich> think I'll add a newline between the sentences
[06:39:49] <cradek> I think all the text might be better left-justified, not centered
[06:39:50] <jmkasunich> any thoughts on centered vs left justified?
[06:39:55] <jmkasunich> lol
[06:39:55] <cradek> haha
[06:40:16] <jmkasunich> left and wordwrap, or left and one sentence per line?
[06:40:28] <cradek> not sure, would have to see it
[06:40:36] <jmkasunich> tomorrow then
[06:40:38] <cradek> you pick
[06:40:39] <cradek> ok
[06:40:49] <cradek> goodnight, really now
[06:40:53] <jmkasunich> heh
[06:40:55] <jmkasunich> night
[06:41:02] <jmkasunich> I need to crash soon too
[11:53:28] <alex_joni> morning
[12:05:48] <anonimasu> morning
[12:31:53] <alex_joni> hi anders
[12:31:58] <alex_joni> how's it going?
[12:48:14] <anonimasu> it's going pretty ok
[12:48:16] <anonimasu> being busy :/
[12:48:41] <anonimasu> but that's a good thing :)
[12:50:17] <alex_joni> right
[12:57:53] <alex_joni> food time
[12:57:55] <alex_joni> bbl
[14:42:29] <alex_joni> morning ray
[14:43:05] <rayh> Hi Alex. How you doing today?
[14:44:06] <SWPadnos> hi Ray
[14:45:07] <alex_joni> pretty ok
[14:45:21] <alex_joni> but I'm leaving on a business trip tomorrow, not very eager to do that
[14:46:19] <rayh> I heard you mention that you were going away for a week.
[14:46:31] <alex_joni> not a full week, till thursday night I hope
[14:46:52] <rayh> Ah. At least you will have the next weekend at home to recover.
[14:46:59] <SWPadnos> heh - I guess it's contagious, I'm headed for LAX tomorrow :)
[14:48:27] <SWPadnos> the funny thing is, a ticket to LA is the same price as a ticket to Warsaw
[14:48:33] <SWPadnos> go figure
[14:48:39] <alex_joni> * alex_joni goes
[14:49:25] <rayh> Why not got to Warsaw then, SWPadnos
[14:50:50] <SWPadnos> well - I'm headed there in September
[14:50:58] <SWPadnos> the LA trip is for work
[14:52:23] <SWPadnos> Sept. should be a fun month - Poland fora week or so at the beginning, then Germany for a week or so at the end
[14:52:37] <rayh> Fantastic.
[14:52:53] <SWPadnos> I hope so. Got a friend getting married in Poland - that shold be fun
[14:53:08] <rayh> If you get around dortmund you should let me introduce you to my kids.
[14:53:26] <SWPadnos> Dortmund - I've been through there, what is it near?
[14:53:32] <SWPadnos> (can't remember)
[14:54:21] <rayh> North of koln.
[14:54:30] <SWPadnos> ah - that's exactly where I'm headed
[14:54:41] <alex_joni> cologne, but not very near
[14:54:42] <SWPadnos> between Koln and Dusseldorf, right
[14:54:58] <rayh> Somewhere there.
[14:54:58] <alex_joni> well.. depends on your definition of near anyway
[14:55:11] <SWPadnos> or maybe that was the train destination - take the Dortmund train to get to Dusseldorf
[14:55:13] <rayh> * rayh reaches for the shell atlas.
[14:55:16] <SWPadnos> heh
[14:55:32] <SWPadnos> I'm going to the photokina trade show (I think), which is at the Koln Messe
[14:55:54] <rayh> Okay.
[14:56:41] <rayh> We were in the cathedral a few years ago when they were testing the new pipe organ.
[14:56:50] <SWPadnos> that's a very cool place
[14:56:53] <rayh> That is an awesome sound.
[14:58:41] <SWPadnos> ok - breakfast time. be back in a little bit
[14:58:49] <rayh> see you.
[15:46:37] <jmkasunich> * jmkasunich is awake (barely)
[15:47:44] <SWPadnos> welcome to the club
[15:54:53] <jmkasunich> seems I'm making a habit of missing Ray by a few mins
[15:55:09] <SWPadnos> he must be a precog ;)
[15:55:37] <jmkasunich> jepler around?
[15:56:13] <SWPadnos> he was earlier, but I may have scared him away by pointing out that "good morning" is an oxymoron :)
[15:59:09] <jmkasunich> http://home.att.net/~jmkasunich/Pics/picker_screenshot_4.png
[15:59:26] <SWPadnos> cool!
[15:59:35] <SWPadnos> I'm building right now
[15:59:48] <jmkasunich> the picker doesn't actually work yet
[16:00:01] <SWPadnos> no problem - maybe we can fix that today
[16:00:06] <jmkasunich> yeah
[16:00:15] <jmkasunich> thats why I was looking for jepler
[16:00:20] <SWPadnos> halconfig needs the same stuff that the config pocker needs as well
[16:00:27] <SWPadnos> leaf detection for clicks on the tree
[16:00:53] <jmkasunich> he added stuff to setuoconfig that greys buttons when its not appropriate to push them
[16:01:01] <jmkasunich> but I don't understand it
[16:01:11] <SWPadnos> jepler?
[16:02:18] <jmkasunich> I thought so, he's the one who changed it from all differnet sized windows to fixed size with the picture and did lots of other cleanup
[16:02:25] <SWPadnos> right
[16:03:38] <SWPadnos> ok - all those $b configure -state disabled
[16:03:44] <SWPadnos> or -state normal
[16:03:45] <jmkasunich> the tree works right when clicked, but not when you arrow up and down in it
[16:04:06] <jmkasunich> I'm hoping for help with that too
[16:04:36] <SWPadnos> so it detects the fact that the tree node isn't a leaf?
[16:04:41] <SWPadnos> the clicked node
[16:04:51] <jmkasunich> if you click on a line, I get a callback and can decide whether or not to hightlight the line (only if it is a usable config), and prints the details
[16:04:58] <alex_joni> hello
[16:05:17] <SWPadnos> ok - that's good
[16:05:29] <jmkasunich> but you can arrow the highlight up and down all day and I never get the callback (in spite of trying a wide variety of bindText options)
[16:05:31] <SWPadnos> the same needs to be in halconfig, so it can *not* add a watch fro e.g. ppmc.0
[16:05:32] <jmkasunich> hi alex
[16:06:00] <jmkasunich> I decided based on the name of the node
[16:06:19] <jmkasunich> if it ends in .ini, then highlight (and enable the OK button, once I know how to do that)
[16:06:20] <SWPadnos> ok - if it has no / then it's a leaf (or something like that)
[16:06:23] <SWPadnos> ok
[16:06:33] <jmkasunich> for ones like "
[16:06:35] <jmkasunich> oops
[16:06:50] <jmkasunich> like "stepper" that aren't leaves, but do have descriptions, I check the parent
[16:07:12] <jmkasunich> if the parent is "root", then I know its a top level like configs/, and blank the "details" box
[16:07:23] <jmkasunich> if the parent is not root, then its a config, and I print the README
[16:09:52] <alex_joni> if it's there
[16:10:18] <jmkasunich> yeah
[16:10:32] <jmkasunich> if not, I print a message like "No details available"
[16:10:45] <SWPadnos> there should be some indication of the number of children a particular node has
[16:11:25] <jmkasunich> I haven't read all the docs on the Tree widget, there probably is
[16:11:41] <SWPadnos> heh - I'm not sure anyone wawnts to read all the docs ;)
[16:12:50] <alex_joni> especially tk or tcl
[16:14:01] <jmkasunich> "nodes" will return a list of the children
[16:14:32] <jmkasunich> llength [ $tree nodes $node ] should tell you how many children $node has
[16:14:52] <SWPadnos> ok - that would be good for halconfig
[16:15:16] <jmkasunich> if you just want to know if there are any children you could do
[16:15:40] <jmkasunich> if { [ $tree nodes $node 0 ] == "" }
[16:15:54] <jepler> SWPadnos: yes?
[16:16:04] <jmkasunich> hi jepler
[16:16:11] <jmkasunich> * jmkasunich pounces
[16:16:12] <SWPadnos> was asking jmk if he meant you ;)
[16:16:17] <jepler> oh
[16:16:23] <jepler> oh well, now he knows I'm here.
[16:16:31] <SWPadnos> now you're in trouble
[16:16:34] <jmkasunich> <evil cackle>
[16:16:53] <jmkasunich> I need help
[16:17:00] <jepler> have some specific questions?
[16:17:04] <jepler> * jepler scrolls back a bit
[16:17:21] <jmkasunich> trying to understand the "enable/disable a button" magic you worked on setupconfig
[16:17:31] <jmkasunich> working on pickconfig
[16:17:35] <jmkasunich> take a look at http://home.att.net/~jmkasunich/Pics/picker_screenshot_4.png
[16:18:36] <jmkasunich> pickconfig is based on setupconfig (with much trimming)
[16:19:08] <jmkasunich> last night it was too late and my brain wasn't functioning well enough to figure out the buttons
[16:19:16] <jmkasunich> this morning it is too early ;-)
[16:19:44] <jepler> For listboxes, I create a binding on the event <<ListboxSelect>> which calls a command that enables or disables the button depending whether anything is selected in the listbox.
[16:20:12] <jepler> proc button_depends_on_listbox creates the binding, and proc button_listbox_changed is called when the <<ListboxSelect>> event is generated
[16:20:21] <jepler> I don't know if bwidget's tree has anything like <<ListboxSelect>>
[16:20:35] <jmkasunich> in my case, I don't need the binding, I already have a proc that makes the decision, I need to turn the button on and off tho
[16:20:48] <jmkasunich> can you do a cvs up? the code is in CVS
[16:20:54] <jepler> if {[condition]} { $button configure -state normal } else { $button configure -state disabled }
[16:20:58] <jmkasunich> tcl/bin/pickconfig.tcl
[16:21:10] <jmkasunich> thats it?
[16:21:36] <jepler> You have to get $button and {[condition]} right, but basically yes.
[16:22:03] <jmkasunich> so "button_depends_on_listbox" aren't directly involved in turning on and off, they are the bound functions?
[16:22:22] <jmkasunich> I thought they were some kind of callback from the button widget that handled the enable/disable
[16:22:23] <jmkasunich> duh
[16:22:25] <jepler> button_depends_on_listbox creates the binding, but you say you don't need to create a binding, you're already calling a proc sometimes
[16:22:40] <jmkasunich> ok, I think I understand
[16:23:04] <jmkasunich> I do have another place where I want a binding, but that is related to Tree, so I dunno if you'd know or not
[16:23:07] <jepler> b_d_o_l creates the binding, then calls it manually once just to make sure the button starts out the right way
[16:23:13] <jepler> I haven't used Tree
[16:23:39] <jmkasunich> $tree bindText <Button-1> { node_clicked }
[16:23:42] <jepler> did you find the documentation for it? /usr/share/doc/bwidget/html/Tree.html on my debian system
[16:23:48] <jmkasunich> yes
[16:24:07] <jmkasunich> the line above binds a proc so that when you click on a node the proc is called
[16:24:09] <jmkasunich> works fine
[16:24:16] <jmkasunich> but you can also keyboard to a node
[16:24:33] <jmkasunich> I've tried a bunch of other bind variations, can't seem to capture that
[16:25:19] <jmkasunich> so you click on node "stepper_inch.ini" and it displays the details, highlights it (and soon, enables the OK button)
[16:25:38] <jmkasunich> then you up-arrow to some other node, the highlight moves, but OK and the details don't change
[16:26:12] <jmkasunich> $tree bindText <Key-Up> { node_clicked }
[16:26:12] <jmkasunich> $tree bindText <Key-Down> { node_clicked }
[16:26:13] <jmkasunich> $tree bindText <Key-Select> { node_clicked }
[16:26:18] <jmkasunich> some of the ones I've tried
[16:29:26] <jmkasunich> cool, button enable/disable works, that was easier than I expected
[16:31:03] <staggerlytom> good morning
[16:31:38] <jmkasunich> morning tom
[16:34:43] <alex_joni> morning
[16:40:09] <jmkasunich> "$tree bindText <<TreeSelect>> { node_clicked }" didn't cause an error, so TreeSelect must be a valid event (I think)
[16:40:19] <jmkasunich> but it also didn't seem to capture anything
[16:40:29] <jepler> jmkasunich: <<Anything>> is accepted without error checking
[16:40:51] <jepler> <<TreeSelect>> works when clicking but not when using the keyboard. I don't understand if this is intentional or not, but it sure disagrees with what I would expect.
[16:41:01] <jmkasunich> Key-XK_Up wasn't ;-)
[16:41:20] <jepler> <Anything> is error checked, <<Anything>> isn't.
[16:41:25] <jmkasunich> oh
[16:42:06] <jmkasunich> <<TreeSelect>> doesn't work with clicking (at least not here)(
[16:42:37] <jmkasunich> (comment out the <Button-1>, that one does work with clicking)
[16:43:41] <jmkasunich> where would the source for bwidget be?
[16:44:04] <jmkasunich> the docs don't list the events it defines, I want to see if I can find them
[16:44:12] <jepler> I think I have a patch that works ...
[16:44:30] <jmkasunich> feel free to commit it
[16:44:50] <jmkasunich> or if its only a couple of lines, paste it here
[16:46:05] <jepler> bwidget source is /usr/lib/bwidget1.7.0/
[16:46:17] <jepler> committed
[16:47:06] <jepler> I commented out "$tree selection clear" because it seemed to make the keyboard navigation get "stuck" when it reached a non-leaf node
[16:47:27] <jmkasunich> hmm
[16:47:56] <jmkasunich> what do all those extrea {} around node do?
[16:48:06] <jepler> proc node_clicked { {node {}} } {
[16:48:06] <jepler> here?
[16:48:12] <jmkasunich> yeah
[16:48:22] <jepler> It means 'node is an optional argument. If it's not specified, its default value is {} (the empty string'
[16:48:57] <jepler> before, the selcted node was passed in by bindText, but it's not there for <<TreeSelect>>
[16:49:01] <jmkasunich> ok, thats so "node_clicked" can be invoked multiple ways
[16:49:07] <jepler> right
[16:49:15] <jepler> it really only needs one way, since it's only called from <<TreeSelect>>
[16:49:42] <jepler> like this (untested):
[16:49:43] <jepler> proc node_clicked {} {
[16:49:43] <jepler> global tree detail_box
[16:49:43] <jepler> set node [$tree selection get]
[16:49:43] <jepler> if {$node == ""} return
[16:50:09] <jmkasunich> I think I get it
[16:50:22] <jmkasunich> bit of a bummer about not being able to clear the selection
[16:50:29] <jmkasunich> (aka the highlight)
[16:50:40] <jmkasunich> I wanted to highlight only usable configs, not directlry entries
[16:51:20] <jmkasunich> but I guess turning the OK button on and off is enough to indicate which ones are usable and which ones are just navigation
[16:52:30] <jmkasunich> KeyPress-Up
[16:52:39] <jmkasunich> does that means up arrow?
[16:52:51] <jepler> Yes .. (not the keypad one)
[16:53:26] <alex_joni> who has a keypad anyways ;)
[16:53:30] <jmkasunich> I do
[16:53:40] <jmkasunich> and I use it instead of the arrows 90% of the time
[16:53:42] <jepler> KeyRelease (and KeyRelease-xxx) if you want to detect that
[16:53:50] <jmkasunich> no need
[16:54:14] <jmkasunich> at first I thought we'd need to detect left and right (expand/collapse tree) but not needed
[16:54:16] <jepler> in the tree, I think this gives better names:
[16:54:16] <jepler> set parts [file split $inifile]
[16:54:16] <jepler> $tree insert end $dir $inifile -text [lindex $parts end-1] -open 1
[16:54:37] <jepler> I had several 'sim.ini' all in different folders
[16:54:41] <jepler> and I couldn't tell the difference
[16:55:04] <jmkasunich> thats why its a tree
[16:55:35] <jepler> /etc/emc2/sim-AXIS/sim.ini
[16:55:36] <jepler> /etc/emc2/sim/sim.ini
[16:55:36] <jepler> /etc/emc2/mysim/sim.ini
[16:55:55] <jmkasunich> oh
[16:56:02] <jepler> because there's only one ini in each of these folders, they were displayed directly as children of /etc/emc2
[16:56:12] <jepler> but it says 'sim.ini', not 'sim-AXIS' etc
[16:56:23] <jepler> with my change, it says 'sim-AXIS etc
[16:56:41] <jmkasunich> the ones I'm testing with obey the convention that .ini file name matches dir name (if theres only one)
[16:56:46] <chinamill> Hello, did anyone noticed axis displayes planned path and actual path with (a guess) a scaling problem? (axis from BDI 4.38)
[16:56:49] <jmkasunich> but we shouldn't rely on that
[16:57:09] <chinamill> (when running metric ini)
[16:58:03] <jepler> chinamill: You shold probably upgrade to a newer version of axis
[16:58:20] <chinamill> jepler: ok
[16:58:22] <jepler> chinamill: first, you have to follow the instructions to rebuild the version of emc on bdi, then follow the instructions to rebuild axis.
[16:58:35] <jepler> chinamill: hold on, I'll find you some URLs with directions
[16:58:48] <jepler> chinamill: this is also a great opportunity to step up to emc2
[16:59:04] <jmkasunich> jepler: shh
[16:59:07] <jepler> chinamill: rebuilding the version of emc on bdi: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?BDI-4_Install
[16:59:19] <chinamill> I like to be braindead ;)
[16:59:28] <jepler> chinamill: building axis: http://axis.unpy.net/installing
[16:59:42] <chinamill> ok, thanks, maybe I'll will have alook at it
[16:59:52] <jepler> chinamill: building emc2 on bdi: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?BDI-4_38_Compile_EMC2
[17:00:00] <jmkasunich> jepler, can you cvs up (to get my OK button changes), then commit your tree change
[17:00:24] <jepler> chinamill: If you want new versions of axis on bdi, please tell paul_c on the new discussion lists for bdi. They're at http://ourproject.org/moin/projects/bdi4emc
[17:00:50] <chinamill> Good idea!
[17:03:44] <jepler> chinamill: and if, after installing axis 1.1.1 or 1.2a2, you still have a problem with metric and axis, please contact me on the emc-users list or at <jepler@unpy.net>.
[17:04:16] <alex_joni> odd way of development
[17:04:23] <alex_joni> at least by reading the commit logs
[17:04:38] <jmkasunich> what do you mean?
[17:04:43] <alex_joni> jmkasunich: you first submitted an initial version, and afterwards you took out parts till it works right
[17:04:46] <alex_joni> ROFL
[17:04:51] <jmkasunich> lol
[17:05:09] <jmkasunich> I copied a much larger program, kept that parts I wanted, and chopped the rest
[17:05:09] <alex_joni> ok, at least jepler seems to have added something
[17:05:15] <jmkasunich> theres still more chopping to be done
[17:05:18] <alex_joni> I am kidding
[17:05:21] <jmkasunich> I know
[17:05:26] <jepler> alex_joni: surely that approach to development will work, if you start with a large enough file...
[17:05:33] <alex_joni> lol
[17:05:43] <alex_joni> cat /dev/random > foo.file
[17:05:46] <alex_joni> might just work
[17:05:58] <jmkasunich> right - get a million monkeys to write the code, and one developer to take out the parts that don't work
[17:06:24] <jmkasunich> that's MicroSoft's approach I think
[17:07:33] <jepler> when combined with test-driven development, I don't see why it wouldn't work.
[17:07:56] <jmkasunich> ok, now we either have to fake .ini at the end of the directory ones, or delete the .ini from the other ones (and remove the bit about .ini in the message)
[17:08:13] <jmkasunich> (not the big nasty message about "don't use it", the real one that is right before that)
[17:08:22] <jmkasunich> I think I favor the latter, drop .ini entirely
[17:08:28] <jepler> I think that's fine
[17:09:09] <jmkasunich> I'm also tempted to not display details if its not a leaf node
[17:09:19] <jmkasunich> (in addition to blanking the OK button)
[17:09:45] <jmkasunich> you know, this is gonna confuse people who actually look at the directories
[17:10:03] <jmkasunich> motenc is a file inside motenc/
[17:10:13] <jmkasunich> stepper_inch is a file inside stepper/
[17:10:19] <jmkasunich> but they are displayed differently
[17:11:37] <alex_joni> * alex_joni sees more droppings ;)
[17:12:23] <jmkasunich> I thought about always displaying the dir, with the files at the next level, even if there is only one
[17:12:32] <jmkasunich> but that nearly doubles the tree length
[17:13:05] <jmkasunich> we really want to encourage the case of one .ini per directory anyway, so always displaying dir and filename is bad
[17:13:07] <jepler> show sim/sim.ini all in one entry?
[17:13:20] <alex_joni> how about absolute path?
[17:13:36] <alex_joni> like: /path/to/foo/sim/sim.ini
[17:13:48] <jmkasunich> then why bother with a tree?
[17:13:55] <alex_joni> not sure.. ;)
[17:14:04] <alex_joni> might save you some problems though
[17:14:10] <jmkasunich> we might want to make the top level ones absolute tho
[17:14:54] <jmkasunich> I kinda like jepler's idea
[17:15:03] <jmkasunich> if multiple inis:
[17:15:05] <jmkasunich> dir
[17:15:11] <jmkasunich> ---ini
[17:15:15] <jmkasunich> if only one
[17:15:16] <jmkasunich> dir/ini
[17:15:37] <jmkasunich> but the existing layout is so much prettier ;-/
[17:16:49] <jmkasunich> screw it, I like the way it is now
[17:17:02] <jmkasunich> no .ini cluttering up the tree
[17:17:27] <alex_joni> okie, you're the boss on this one :P
[17:18:00] <jmkasunich> I think the shiny parts are pretty good now, time to make the greasy parts work
[17:18:26] <cradek> hi all
[17:18:27] <alex_joni> what's up with you (machinists) and greasy ?
[17:18:30] <alex_joni> hey chris
[17:18:59] <jmkasunich> shiny: GUI elements (think car sheet metal) greasy: internals that actually do stuff (car engine)
[17:19:29] <jmkasunich> hi chris
[17:19:29] <alex_joni> car engine shouldn't be greasy.. you need to clean it up once in a while if it is ;-)
[17:19:54] <alex_joni> but I know what you mean
[17:20:36] <jmkasunich> should we allow --config /some/long/path/to/a/dir/that/isn't/even/in/configs-path ?
[17:20:40] <jmkasunich> I think no
[17:20:49] <jmkasunich> just --configs
[17:20:55] <jmkasunich> oops
[17:21:00] <jmkasunich> just --configs somename
[17:21:16] <jmkasunich> where somename must be a subdir in one of the configs-path dirs
[17:21:43] <cradek> the emc script shouldn't even call pickconfig if it's given a path to a unique config
[17:22:01] <alex_joni> what chris said
[17:22:28] <jmkasunich> currently (with setupconfig) the script calls it to validate the path (make sure an ini file exists in the specified directory, for example)
[17:22:30] <alex_joni> oh, and I just remembered (I read the logs from last night), imho we should have pickconfig not executable
[17:22:42] <alex_joni> but have a helper app (just like emc-config) in PATH
[17:22:52] <jmkasunich> in due time, right now it needs to be so I can test it
[17:23:06] <alex_joni> so any users running from the shell (even if they are not supposed to) can run with the proper params
[17:24:28] <jepler> hey, woah, wait -- not supposed to run emc from the shell?
[17:24:48] <alex_joni> I meant configpicker
[17:24:55] <alex_joni> or pickerconfig or whatever
[17:25:06] <alex_joni> surely you can run emc from the shell
[17:25:37] <alex_joni> but you can't expect a user running /usr/emc2/share/tcl/bin/pickconfig.tcl to supply the proper args
[17:26:05] <jepler> OK, I take back my shock and outrage.
[17:26:21] <alex_joni> example: /usr/emc2/share/tcl/bin/pickconfig.tcl --configs-dir /etc/emc2/configs:/usr/emc2/share/configs:~/emc2/configs
[17:26:46] <alex_joni> cradek: still there?
[17:26:59] <cradek> yes
[17:26:59] <alex_joni> * alex_joni gets a weird error when apt-get update'ing
[17:28:03] <cradek> I see no reason for someone to run pickconfig from the shell. It's a program that scans some dirs and spits out a pathname
[17:28:09] <alex_joni> GPG error: http://security.ubuntu.com breezy-security Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
[17:28:32] <jmkasunich> cradek: the only reason is the one that applies right now - we're testing it
[17:28:45] <cradek> agreed
[17:28:57] <jmkasunich> and we don't need a wrapper for that
[17:29:00] <alex_joni> then I take it back
[17:29:09] <jmkasunich> get the cmd line right one time, then use bash history
[17:29:31] <alex_joni> cradek: any idea if the GPG has changed for the Ubuntu signing ?
[17:29:32] <cradek> alex_joni: interesting, they must have messed something up
[17:29:48] <jmkasunich> btw alex, its no longer --configs-dir <list_of_dirs> its --configs-path <list_of_dirs>
[17:29:57] <cradek> alex_joni: not that I've heard, but I wouldn't have heard if so
[17:29:57] <jmkasunich> I'll fix the script that calls it once its done
[17:30:16] <alex_joni> ok, I confused it, setupconfig has (had?) --configs-dir
[17:30:25] <jmkasunich> yes, back when it was one dir
[17:30:34] <cradek> alex_joni: I don't get that error. You must have a bad download.
[17:30:35] <jmkasunich> (and still does, it hasn't been updated yet)
[17:30:52] <alex_joni> I tried again, got no error this time
[17:30:54] <jmkasunich> eventually, setupconfig will also use --configs-path
[17:31:09] <jmkasunich> and will use the tree based picker for picking a template config, etc
[17:31:18] <alex_joni> right
[17:31:19] <cradek> alex_joni: good to know it recovers from a bad download
[17:31:26] <alex_joni> it seems to
[17:31:51] <alex_joni> no new debs for me today :)
[17:32:18] <cradek> now I can build them again!
[17:32:37] <alex_joni> yeah, I noticed
[17:32:40] <alex_joni> nice job, btw
[17:32:48] <cradek> thanks
[17:32:55] <alex_joni> * alex_joni even understands it
[17:33:00] <jmkasunich> time for lunch, back in a bit
[17:33:01] <cradek> when jmk gets configgerpickerator done I'll make a new one
[17:33:16] <alex_joni> hrmm.. I still get the error
[17:33:20] <alex_joni> the GPG error
[17:33:28] <alex_joni> but I have slightly more sources
[17:33:41] <alex_joni> I enabled universe & multiverse & a few more
[17:34:22] <cradek> maybe you should ask google about the error
[17:34:31] <cradek> or try removing some stuff in /var/lib/apt/lists
[17:35:07] <alex_joni> I don't really care about it.. just pointed it out
[17:36:24] <alex_joni> ok, google has the answer as always:
[17:36:25] <alex_joni> At the moment the Release file at
[17:36:25] <alex_joni> `archive.ubuntu.com/ubuntu/dists/breezy/Release' is broken (therefore
[17:36:26] <alex_joni> `BADSIG'). If you take a look at the file it seems to be incomplete.
[17:36:54] <cradek> yay gpg
[17:37:01] <alex_joni> The good thing is, it seems to be more a technical than a security problem atm.
[17:37:04] <alex_joni> So this problem should be visible by everyone having a breezy line in
[17:37:06] <alex_joni> their `sources.list' (except those using mirrors that haven't synced
[17:37:09] <alex_joni> yet). The only thing you can do about it is to wait until this problem
[17:37:11] <alex_joni> is fixed.
[17:37:36] <alex_joni> probably my server is slow on sync, and only now has the problem, yours might already have the fix
[17:37:38] <cradek> funny I don't get it
[17:37:42] <cradek> yeah maybe
[17:47:13] <cradek> pickconfig is looking really good, guys
[17:48:34] <staggerlytom> i have 6 8255 chips on 2 pci cards.
[17:48:38] <staggerlytom> I wrote a driver for a single chip,
[17:48:47] <staggerlytom> its 3 ports and 1 control register.
[17:48:57] <staggerlytom> The call is rtload hal_zio chipbase=0x28c0 dio="IOio"
[17:49:02] <staggerlytom> Can I call it once for each chip?
[17:49:10] <staggerlytom> (Like Hall would track the multiples )
[17:49:17] <cradek> I saw that jmk answered your questions on the list
[17:49:21] <staggerlytom> or must I isntance them all at once?
[17:49:30] <alex_joni> all at once
[17:49:45] <staggerlytom> hmm, delay in the package delivery...
[17:49:48] <alex_joni> and I saw the answer too
[17:52:44] <staggerlytom> ok, got it, some name space conflict and use an array, ok
[17:54:04] <alex_joni> I would use:
[17:54:39] <alex_joni> rtload hal_zio board_addr=0x28c0,0x29c0 dio="IOio","OIoi"
[17:54:44] <alex_joni> or something like that
[17:54:53] <alex_joni> maybe even a num_boards=2
[17:55:29] <staggerlytom> yep, num_boards follows your num_channels in the stg model
[17:55:56] <alex_joni> probably :)
[17:56:43] <alex_joni> oh my.. this really WORKS great
[17:56:47] <alex_joni> jepler: hats off
[17:56:57] <alex_joni> I had it configured for make install, and compiled
[17:57:05] <alex_joni> I reconfigured for run-in-place
[17:57:12] <alex_joni> recompiled (which was only 1 file)
[17:57:16] <alex_joni> and it ran perfectly
[17:57:29] <cradek> hey I did that part
[17:57:32] <SWPadnos> heh
[17:57:34] <cradek> but actually it's a bug
[17:57:47] <alex_joni> how come?
[17:57:48] <cradek> because when you reconfigured, you may have specified a different CC etc
[17:57:54] <cradek> so it should have rebuilt everything
[17:57:57] <alex_joni> no I didn't ;)
[17:58:08] <cradek> right, but it doesn't know that, and CC is in Makefile.inc
[17:58:18] <alex_joni> and probably lost
[17:58:31] <alex_joni> because of the rewrite
[17:58:43] <cradek> so assuming you only change run-in-place, it's fine the way it is
[17:58:43] <alex_joni> leave it like this
[17:59:03] <alex_joni> if someone does configure --change-CC then they probably know how to do a make clean
[17:59:05] <cradek> but you can make changes with configure that show the dependencies are insufficient
[17:59:29] <alex_joni> cradek: so could editing the depends files
[17:59:41] <alex_joni> but we're not trying to outsmart every ill-willed user
[17:59:58] <cradek> alex_joni: slow-but-right is usually better than fast-but-wrong
[18:00:29] <cradek> alex_joni: but I agree maybe it's ok in this case
[18:00:47] <alex_joni> we'll worry when we hear the first feedback that soemthing wrong happened
[18:00:53] <alex_joni> but I guess that will never happen
[18:01:14] <cradek> I'll look at Makefile.inc with a critical eye and maybe see other things that should reasonably depend on it
[18:01:27] <alex_joni> ok
[18:01:52] <cradek> or you can :-)
[18:02:07] <alex_joni> or I can, just fixing some typos in a presentation first
[18:02:09] <alex_joni> then I will
[18:18:13] <staggerlytom> bye all
[18:48:07] <alex_joni> anyone still around?
[18:48:25] <SWPadnos> sort of
[18:48:30] <jmkasunich> * jmkasunich is here
[18:48:32] <alex_joni> heh :)
[18:48:45] <alex_joni> got a message from a german user complaining there's no probing in emc2
[18:49:01] <alex_joni> but I guess we'll worry for the next release.. right?
[18:49:37] <jmkasunich> yeah
[18:49:52] <alex_joni> ok. jmk since you're here I have an idea
[18:49:54] <jmkasunich> ask him to submit a feature request ;-)
[18:50:02] <alex_joni> regarding emc-config
[18:50:20] <alex_joni> emc-config could supply the path/to/runscript to setupconfig.tcl
[18:50:47] <alex_joni> that way setupconfig might even run a new/modified/duplicated config
[18:51:19] <jmkasunich> IOW, setupconfig could have a run button?
[18:51:30] <alex_joni> it does now.. doesn't it?
[18:51:50] <jmkasunich> yes
[18:52:03] <alex_joni> if you follow the path to make a new config, at the end it asks you if you want to run it
[18:52:13] <jmkasunich> but I wasn't sure it would later
[18:52:28] <alex_joni> ok..
[18:52:38] <jmkasunich> but think I like that idea
[18:52:40] <alex_joni> if it's needed, it's easy to do
[18:52:51] <alex_joni> just say so..
[18:53:15] <jmkasunich> it asks you if you want to run, and if so, calls the runscript, and passes the exact name of the config to run, so the run picker never pops up
[18:53:25] <alex_joni> right
[18:53:34] <alex_joni> that's what I thought
[19:04:53] <jmkasunich> can you guys put pickconfig thru its paces?
[19:05:28] <jmkasunich> it's done, for some value of "done"
[19:05:59] <jmkasunich> pickconfig: 409 lines, setupconfig: 1775
[19:06:06] <jmkasunich> a little bloat in setupconfig
[19:06:16] <cradek> for a multi-ini config dir, I wonder if the text window should clear if you don't select a leaf
[19:06:27] <jmkasunich> I was thinking about that
[19:06:35] <cradek> right now, the OK button grays out and it might be confusing
[19:06:50] <jmkasunich> IOW, the make the text window track the OK button
[19:06:53] <cradek> yes
[19:07:11] <jmkasunich> I can do that ;-)
[19:07:20] <cradek> right now it seems like there are three things you can select: things that are configs, things that aren't, and things that are sort of in between
[19:07:29] <jmkasunich> yeah
[19:07:37] <jmkasunich> things that are not - dirs in configs-path
[19:07:38] <cradek> (judging only by the feedback from the disabled things on the screen)
[19:07:49] <jmkasunich> inbetween, config subdirs with more than one ini
[19:08:02] <cradek> right
[19:10:23] <alex_joni> * alex_joni tries it
[19:11:43] <alex_joni> looks good
[19:11:55] <jmkasunich> abuse it (try using keyboard, etc)
[19:11:56] <alex_joni> only thing it returns OK, not the config chosen
[19:12:07] <jmkasunich> you must have an old version
[19:12:10] <jmkasunich> cvs up
[19:12:36] <alex_joni> oh, my latest cvs up was in src/ ;)
[19:13:28] <alex_joni> hmm.. this is unexpected
[19:13:45] <alex_joni> I moved with the keyboard on stepper (which is a dir, with 2 ini's in it)
[19:13:50] <alex_joni> hitting Enter, exists
[19:14:04] <jmkasunich> was the OK button grayed out?
[19:14:08] <alex_joni> yes
[19:14:14] <jmkasunich> but enter worked anyway?
[19:14:18] <alex_joni> yes
[19:14:24] <jmkasunich> I thought I tested that
[19:15:02] <cradek> jmkasunich: if you click it, Enter is disabled; if you use the arrows to get there, it's not
[19:15:13] <jmkasunich> hmm
[19:15:34] <cradek> update before you change something - I committed a change
[19:15:41] <alex_joni> not true, I was able to click it, and still could press Enter
[19:15:43] <jmkasunich> the arrows work strangely, I'm not sure I entirely understand them
[19:16:06] <alex_joni> wait I think I know what's wrong
[19:16:10] <alex_joni> at least user-wise
[19:16:10] <jmkasunich> cradek: I hope you aren't doing the "don't display text for dirs"
[19:16:15] <jmkasunich> cause I'm doing that
[19:16:17] <cradek> no, just cosmetic things
[19:16:30] <alex_joni> when I click an ok entry, then enter gets enabled
[19:16:43] <alex_joni> when I afterwards click an not-ok entry, it never gets disabled again
[19:16:43] <cradek> off to find ... uh, breakfast
[19:16:46] <alex_joni> same for keys
[19:16:54] <alex_joni> cradek: hunt a chicken
[19:17:10] <alex_joni> or a henn, get her eggs ;)
[19:17:22] <jmkasunich> ok, clicking on an invalid tree item, hitting enter, its disabled
[19:17:40] <alex_joni> yup, click one that's valid, then repeat the procedure
[19:17:40] <jmkasunich> click on a valid one, then and invalid, and hit enter, it exits
[19:17:53] <alex_joni> yup, probably some bad checking somewhere
[19:17:56] <jmkasunich> when I see a valid one I bind to <return>
[19:18:07] <jmkasunich> when I see an invalid I'm supposed to unbind
[19:18:14] <jmkasunich> bet its not happening
[19:18:15] <alex_joni> yup
[19:19:01] <jmkasunich> I think I see the prob
[19:19:15] <jmkasunich> yep, that fixed it
[19:19:22] <jmkasunich> mistake on the bind call
[19:22:01] <jmkasunich> committed
[19:22:34] <cradek> that's much better
[19:23:50] <alex_joni> agreed
[19:25:22] <jmkasunich> I'm starting to make the changes to hook it to the emc script
[19:25:55] <jmkasunich> EMC2_CONFIG_DIR=$sysconfdir/emc2
[19:26:03] <jmkasunich> do we want that to have multiple dirs now?
[19:26:11] <jmkasunich> and if so, how do they get set?
[19:29:03] <alex_joni> I think it will be a deb policy
[19:29:26] <jmkasunich> works for debs, what about make install?
[19:30:26] <alex_joni> looking now
[19:30:59] <jmkasunich> hmm, seems I made a mistake when I spec'ed the interface to pickconfig
[19:31:15] <jmkasunich> I did --config <name> --ini <name>
[19:31:52] <alex_joni> for ubuntu (and other debians) we would have /etc/emc2 and /usr/local/etc/emc2
[19:31:59] <jmkasunich> but emc is passing <whatever-user-enters> which might be a complete path to an ini file, or might be total nonsense
[19:32:31] <alex_joni> only the later for make install
[19:32:52] <jmkasunich> how does that get into "emc"
[19:33:17] <jmkasunich> @EMC2_CONFIG_DIR@ ?
[19:33:49] <alex_joni> yes
[19:34:27] <jmkasunich> ok, we need a discussion:
[19:34:40] <jmkasunich> which of the following should be legal (and what should they do)?
[19:34:42] <jmkasunich> emc
[19:34:45] <jmkasunich> emc foo
[19:34:47] <jmkasunich> emc foo.ini
[19:34:57] <jmkasunich> emc <somepath>/foo.ini
[19:35:04] <jmkasunich> emc <somepath>/foo
[19:35:21] <alex_joni> I think only : emc and emc absolute_path/foo.ini should be valid
[19:35:43] <alex_joni> anything else starts the picker, maybe with the entry already selected (but that's matter of taste)
[19:36:48] <jmkasunich> the picker is intended to validate a name that it is passed (and not pop the GUI if the name is OK)
[19:37:14] <alex_joni> so how does it deal with decision processes?
[19:37:20] <alex_joni> say I want to run sim
[19:37:28] <jmkasunich> for example, picker --configs-path ./configs --config foo will return ./configs/foo/foo.ini if such a thing exists
[19:37:28] <alex_joni> but there are 5 sim.ini
[19:37:38] <jmkasunich> first one in the path
[19:38:11] <jmkasunich> if path is ~/emc2/configs:/usr/local/emc2/:/etc/emc2, and all have a sim, and you call:
[19:38:33] <jmkasunich> picker --configs-path ~/emc2/configs:/usr/local/emc2/:/etc/emc2 --config sim
[19:38:50] <jmkasunich> it will return ~/emc2/configs/sim/sim.ini (if there is one)
[19:39:02] <jmkasunich> if no sim in that dir, it will check the next one, and so on
[19:39:49] <jmkasunich> note that picker will never return something outside the path that it is given
[19:40:12] <jmkasunich> (unless you trick it with --config ../../../somewhere/else/sim
[19:45:18] <jmkasunich> should we remove all validation from pickconfig (and also all args to it except the path)
[19:45:46] <jmkasunich> let the run script validate anything passed on the cmd line, and have pickconfig always pop the GUI?
[19:46:15] <alex_joni> hrmm.. that's tough to call
[19:46:36] <jmkasunich> things like validation are probably easier to do in tcl
[19:46:45] <cradek> I agree with alex_joni that we should allow "emc" (picker runs) or "emc path/to/an/ini" (picker doesn't run)
[19:46:52] <jmkasunich> but we need to get our sh*t straight aboyt what we pass to the picker
[19:46:56] <cradek> explicit is better than implicit
[19:47:11] <alex_joni> emc sim is bad imho
[19:47:15] <jmkasunich> what about defaults?
[19:47:25] <alex_joni> emc
[19:47:38] <cradek> I forgot about defaults, but the emc script can check for them when called with no args
[19:47:40] <alex_joni> if default is there, picker returns path/to/default.ini
[19:47:44] <jmkasunich> yesterday we were gonna have emc call picker with --config default --ini default
[19:47:45] <alex_joni> or script
[19:47:54] <jmkasunich> if they exist, picker will return them, if not it will pop the GUI
[19:48:12] <cradek> jmkasunich: what if I have two configs named default?
[19:48:12] <alex_joni> * alex_joni is lost on --config default --ini default
[19:48:37] <alex_joni> first in PATH I guess
[19:48:38] <jmkasunich> --config foo --ini bar
[19:48:47] <alex_joni> what's --config and what's --ini ?
[19:49:03] <jmkasunich> things passed to the picker
[19:49:34] <jmkasunich> ###############################################################
[19:49:34] <jmkasunich> #
[19:49:34] <jmkasunich> # usage:
[19:49:34] <jmkasunich> # pickconfig [options]
[19:49:35] <jmkasunich> #
[19:49:36] <jmkasunich> # Validates a desired emc2 config or asks the user to choose
[19:49:38] <jmkasunich> # one, then prints the complete path to the ini file.
[19:49:40] <jmkasunich> #
[19:49:42] <jmkasunich> # options:
[19:49:44] <jmkasunich> # --configs-path <dir>[:<dir>]
[19:49:46] <jmkasunich> #
[19:49:48] <jmkasunich> # Required - if not supplied, exits with an error
[19:49:50] <jmkasunich> # Colon separated list of directorys in which to search
[19:49:53] <jmkasunich> # for configurations.
[19:49:54] <jmkasunich> #
[19:49:56] <jmkasunich> # --config <config-name>
[19:49:58] <jmkasunich> #
[19:50:00] <jmkasunich> # Desired configuration name. If specified, pickconfig
[19:50:02] <jmkasunich> # will search the configs-path and use the first sub-
[19:50:04] <jmkasunich> # directory that matches. If there is no match, or if
[19:50:06] <jmkasunich> # this option was not specified, it will display a list
[19:50:08] <jmkasunich> # of all configurations and ask the user to choose one.
[19:50:10] <jmkasunich> #
[19:50:12] <jmkasunich> # --ini <ini-name>
[19:50:14] <jmkasunich> #
[19:50:16] <jmkasunich> # Desired ini file name. If specified, and if a matching
[19:50:18] <jmkasunich> # one is found in the chosen config, it will be used. If
[19:50:20] <jmkasunich> # no match exists, or if this option was not specified,
[19:50:22] <jmkasunich> # and the chosen config contains more than one ini file
[19:50:24] <jmkasunich> # it will list all the ini files and ask the user to choose
[19:50:26] <jmkasunich> # one. If the chosen config contains only one ini file,
[19:50:28] <jmkasunich> # that file will be used regardless of any -ini option.
[19:50:30] <jmkasunich> #
[19:50:32] <jmkasunich> ###############################################################
[19:50:40] <jmkasunich> we agreed on that yesterday before I started coding
[19:50:42] <jmkasunich> you might have been gone already
[19:52:03] <cradek> while I remember agreeing to this, I'm not so sure anymore
[19:52:12] <cradek> I think --config and --ini are unnecessary complexity
[19:52:14] <jmkasunich> ok, lets come up with something better
[19:52:47] <jmkasunich> if we don't care about defaults, then I agree
[19:52:52] <cradek> I'm just trying to figure out where to put the default
[19:53:04] <jmkasunich> emc <explicit-path> runs that path, emc <nothing> runs the picker
[19:53:12] <jmkasunich> but how do you get a default in that case?
[19:53:13] <cradek> right
[19:53:16] <cradek> I don't know
[19:53:38] <jmkasunich> the idea was that emc would invoke picker with --config default --ini default
[19:54:04] <jmkasunich> so IF those existed, they would be invoked with no GUI, if not, the GUI would pop up
[19:54:12] <cradek> defaults could sure be specified in e.g. ~/.emc2rc
[19:54:41] <cradek> .emc2rc contains the absolute path
[19:54:51] <jmkasunich> let emc parse that, and call picker if and only if it needs a GUI (aka input from the user)
[19:54:52] <cradek> setupconfig writes it/deletes it
[19:54:52] <SWPadnos> or /etc/emcrc
[19:55:08] <cradek> jmkasunich: yes
[19:55:12] <jmkasunich> ok, suits me
[19:55:18] <jmkasunich> that much more code I can delete
[19:55:28] <cradek> IMO the less done in tcl the better
[19:55:37] <jmkasunich> lol
[19:55:45] <jmkasunich> I was thinking the less done in bash the better
[19:56:02] <jmkasunich> tcl is cleaner and easier to read for things like manipulating filenames and such
[19:56:21] <cradek> haha, I do NOT agree
[19:56:33] <SWPadnos> the picker restarts itself with wish, right?
[19:56:41] <jmkasunich> look at line 228 in the picker
[19:56:52] <jmkasunich> 228 thru 259
[19:57:01] <jmkasunich> in bash I think that would be a lot worse
[19:57:09] <jmkasunich> but maybe I just suck at bash
[19:57:22] <SWPadnos> that's a common affliction
[19:57:43] <cradek> jmkasunich: I think it would be about the same, except for punctuation
[19:57:58] <jmkasunich> ok, then I'll rip it out
[19:58:32] <cradek> instead of writing if { [ file isdirectory $subdir ] == 1 } you write if [ -d $subdir ]
[19:58:36] <cradek> etc
[19:58:37] <jmkasunich> --config, --ini, and all code associated with them (which is basically those lines, plus 189-220)
[19:58:47] <cradek> mostly it would be much shorter
[19:59:01] <cradek> cool, I think that's great
[19:59:12] <jmkasunich> what about file join, file dirname, etc
[19:59:34] <cradek> A=$a/$b
[19:59:39] <cradek> A=$(dirname $a)
[19:59:42] <SWPadnos> or basename and dirname
[19:59:48] <jmkasunich> you're probably right tho, its a matter of syntax and familiarity
[19:59:57] <jmkasunich> I just find bash harder to read
[20:00:13] <SWPadnos> wouldn't that be $a=$(dirname $A)
[20:00:18] <jmkasunich> decision made, stand by for commit ;-)
[20:00:20] <cradek> SWPadnos: no
[20:00:46] <cradek> jmkasunich: just wait until I make a directory named {}[][]]} and run your tcl program
[20:00:55] <cradek> jmkasunich: (same applies for sh though)
[20:01:02] <SWPadnos> hmm, as in "if A is a/b, then dirname(A) will be a"
[20:01:15] <cradek> SWPadnos: the two statements weren't related
[20:01:22] <jmkasunich> ok, one more question
[20:01:24] <cradek> SWPadnos: but your $a= syntax was wrong
[20:01:37] <jmkasunich> picker now has only one "option", --configs-path
[20:01:45] <jmkasunich> and its not optional, you must supply a path
[20:01:53] <cradek> good question
[20:01:54] <jmkasunich> so I think I should just lose the option
[20:02:03] <cradek> probably so
[20:02:16] <alex_joni> loose it
[20:02:16] <jmkasunich> usage "pickconfig <path>"
[20:02:28] <alex_joni> * alex_joni hides from cradek
[20:02:42] <jmkasunich> now, should path be <dir>:<dir>:<dir> or just a space separated list of dirs?
[20:03:05] <cradek> probably : separated still
[20:03:06] <jmkasunich> probably keep the :, so it can be stuck in a shell variable without quoting?
[20:03:13] <cradek> it will come from configure as one option
[20:03:18] <jmkasunich> ok
[20:04:09] <cradek> tcl/bin/pickconfig.tcl --configs-path '~/emc2/configs'
[20:04:16] <cradek> when I do this, then pick one, the ~ gets expanded
[20:04:19] <cradek> what expands it?
[20:04:26] <jmkasunich> bash I think
[20:04:31] <jmkasunich> I don't
[20:04:36] <cradek> no, not bash
[20:04:40] <cradek> that's what the '' prevent
[20:04:41] <jmkasunich> tcl?
[20:05:17] <cradek> without the '' it is expanded before pickconfig (and shows up in the tree expanded)
[20:05:57] <cradek> maybe tcl's file join does it
[20:07:18] <SWPadnos> where are you seeing the sxpansion?
[20:07:23] <SWPadnos> I see ~/ in the tree
[20:07:25] <alex_joni> the result printed back
[20:07:29] <cradek> yes the output
[20:07:33] <SWPadnos> ok
[20:07:41] <cradek> I do want ~ in the tree
[20:08:45] <cradek> it's not a full sh expansion because if I change it to $HOME I get nothing
[20:09:06] <cradek> oh well
[20:09:10] <cradek> "it's a feature"
[20:09:12] <jmkasunich> is the expansion in the output a problem?
[20:09:22] <cradek> no, it's arguably what we want
[20:09:25] <jmkasunich> ok, here's the new spec for pickconfig:
[20:09:29] <jmkasunich> ###############################################################
[20:09:30] <jmkasunich> #
[20:09:30] <jmkasunich> # usage:
[20:09:30] <jmkasunich> # pickconfig <config-path>
[20:09:31] <jmkasunich> #
[20:09:32] <jmkasunich> # <config-path> is one or more directories (separated with
[20:09:32] <jmkasunich> # colons) in which pickconfig should search for configs
[20:09:34] <jmkasunich> #
[20:09:36] <jmkasunich> ###############################################################
[20:09:40] <cradek> I just don't understand it
[20:09:45] <cradek> I like that spec better
[20:09:47] <jmkasunich> is that what we want?
[20:13:43] <cradek> I'm itching to make a new deb...
[20:13:57] <cradek> and axis 1.2a2
[20:14:15] <alex_joni> and?
[20:14:30] <cradek> a new emc2 deb with pickconfig
[20:14:34] <cradek> and axis 1.2a2
[20:14:54] <SWPadnos> glob does the expansion (in case anyone's still wondering)
[20:15:11] <cradek> ah
[20:15:18] <cradek> so it must handle ~ but not $ etc
[20:15:34] <alex_joni> jmkasunich: like the spec too
[20:15:35] <SWPadnos> could be
[20:15:47] <SWPadnos> I like the spec - the only thing missing is what you get out of it ;)
[20:16:02] <cradek> ah good idea
[20:16:12] <SWPadnos> (printed config location, changes to /etc/emcrc, changes to ~/.emcrc)
[20:16:30] <cradek> no, this doesn't read or write those files
[20:16:58] <SWPadnos> ok - the "prints config location" line is above that stuff, in the version IHave
[20:17:05] <jmkasunich> ###############################################################
[20:17:06] <jmkasunich> #
[20:17:06] <jmkasunich> # usage:
[20:17:07] <jmkasunich> # pickconfig <config-path>
[20:17:07] <jmkasunich> #
[20:17:08] <jmkasunich> # <config-path> is one or more directories (separated with
[20:17:08] <jmkasunich> # colons) in which pickconfig should search for configs.
[20:17:10] <jmkasunich> # pickconfig will open a GUI window displaying all configs
[20:17:12] <jmkasunich> # that it finds and ask the user to choose one, then print
[20:17:14] <jmkasunich> # the path to the chosen config and exit.
[20:17:16] <jmkasunich> #
[20:17:18] <jmkasunich> ###############################################################
[20:17:26] <SWPadnos> cool by me
[20:17:44] <cradek> ... and on cancel it prints nothing and returns an error exit code
[20:17:54] <SWPadnos> are there any plans for a non-graphical UI (like keystick) for emc2?
[20:18:05] <alex_joni> keystick should work
[20:18:22] <jmkasunich> but obviously on a non-X box, emc can't invoke keystick
[20:18:24] <jmkasunich> oops
[20:18:29] <jmkasunich> can't invoke pickconfig
[20:18:31] <SWPadnos> right
[20:18:42] <cradek> yeah that's why we don't want to REQUIRE tcl for anything
[20:19:25] <cradek> some day I want to revive xemc too - it's the best way to run on slow boxes (I had one)
[20:19:28] <SWPadnos> there is tclsh
[20:19:42] <alex_joni> cradek: how about a stripped version of axis?
[20:19:42] <SWPadnos> it's TK that gets you
[20:19:51] <alex_joni> would that be slower than xemc?
[20:19:59] <cradek> alex_joni: yes, it's interpreted
[20:20:03] <alex_joni> say you disable the plot at compile time
[20:20:05] <alex_joni> oh.. ok
[20:20:11] <cradek> you can probably not get faster than xemc
[20:20:19] <jmkasunich> how about a GTK based GUI?
[20:20:20] <alex_joni> keystick?
[20:20:21] <jmkasunich> ;-)
[20:20:21] <alex_joni> :D
[20:20:28] <SWPadnos> with pacifiers: | / - \ - | ...
[20:21:09] <SWPadnos> you want fast - make a Windows Vista interface using Aero Glass - that'll scream
[20:21:11] <SWPadnos> (in agony)
[20:21:14] <cradek> I tried both keystick and xemc on my underpowered machine, and preferred xemc
[20:21:27] <SWPadnos> what video card?
[20:21:35] <alex_joni> I prefer ssh -X from a faster machine
[20:21:36] <cradek> I don't remember - slow
[20:21:54] <jmkasunich> should pickconfig return error if the user says cancel, or just print nothing?
[20:22:04] <cradek> well anyway, I still have it in the back of my head that we should not REQUIRE tcl/tk
[20:22:14] <cradek> jmkasunich: it should simply exit with an error code
[20:22:18] <jmkasunich> (it returns error if invoked without a path, but currently returns success and prints nothing on cancel)
[20:22:22] <SWPadnos> ok - there's very little that will be faster than text prints (unless you're in framebuffer mode), but a reasonable old Matrox card can blit text glyphs pretty fast
[20:22:53] <cradek> even though all of our guis *currently* use tk
[20:23:13] <cradek> jmkasunich: be sure that error goes to stderr and you return >0
[20:23:29] <cradek> jmkasunich: but IMO the user hitting cancel is not an error condition
[20:23:41] <jmkasunich> no path: print to stderr, exit 1
[20:23:47] <jmkasunich> cancel print nothing, exit 0
[20:23:54] <jmkasunich> ok print result, exit 0
[20:24:12] <jmkasunich> thats what it does now, if you want a change speak quick!
[20:24:14] <cradek> looks fine to me
[20:24:47] <jmkasunich> alex? (you get to call it from the run script, you can live with that? ;-)
[20:25:11] <alex_joni> * alex_joni can live
[20:25:26] <jmkasunich> btw, if you call it with a non-existant path, or one that contains no configs, you get a blank tree, and only Cancel is enabled
[20:25:48] <cradek> I think a blank tree is an error condition
[20:25:50] <jmkasunich> I dunno if that case needs more intelligent handling
[20:26:15] <jmkasunich> so print to stderr "no configs found in path", exit 1
[20:26:22] <jmkasunich> ?
[20:26:50] <alex_joni> yup
[20:27:08] <jmkasunich> hmm, if there's only one config in the path, should I just print it and exit 0?
[20:27:21] <alex_joni> no
[20:27:27] <jmkasunich> why not?
[20:27:33] <jmkasunich> no choice for the user to make
[20:27:35] <alex_joni> if you go that way, to handle special cases it'll never get done
[20:27:46] <jmkasunich> well, I guess there is, he can choose to cancel
[20:27:53] <alex_joni> right
[20:28:28] <jmkasunich> if he really wants to skip the picker, tell emc what to run
[20:28:34] <cradek> agreed
[20:28:47] <jmkasunich> damn, math in tcl sucks
[20:29:07] <jmkasunich> I want "n++" ;-)
[20:29:14] <jepler> jmkasunich: cat /usr/share/dict/words | while read; do echo $i in tcl sucks; done
[20:29:20] <jepler> there's a command "incr"
[20:29:21] <cradek> n=$(($n+1))
[20:29:42] <jmkasunich> lol
[20:29:52] <jepler> % set i 3
[20:29:52] <jepler> 3
[20:29:52] <jepler> % incr i
[20:29:52] <jepler> 4
[20:29:52] <jepler> % set i
[20:29:54] <jepler> 4
[20:30:05] <jmkasunich> thanks
[20:30:08] <cradek> ok that's better than sh
[20:30:40] <SWPadnos> but way less readable than C (i++ or i+=1) :)
[20:30:57] <cradek> (setq n (1+ n))
[20:31:46] <SWPadnos> if (--i++ > n) {foo}
[20:31:57] <SWPadnos> heh - never used that one, might have to sometime ;)
[20:32:57] <cradek> jepler: read a || a=y doesn't work to set a default
[20:33:54] <jmkasunich> new version is 100 lines shorter ;-)
[20:35:04] <cradek> jepler: fixed
[20:38:43] <jepler> cradek: read || wasn't mine, but thanks for fixing it
[20:38:50] <jepler> oh, I removed the -t 5
[20:39:01] <cradek> yeah that was a timeout default thing
[20:39:14] <jmkasunich> drat
[20:39:20] <alex_joni> cradek: the read || a=y was yours
[20:39:21] <jmkasunich> BDI-4.20 is no longer building
[20:39:26] <alex_joni> huh?
[20:39:37] <jmkasunich> http://www.linuxcnc.org/compile_farm/
[20:40:05] <jmkasunich> worked at 22:55 utc yesterday, broken at 00:11 today
[20:40:10] <alex_joni> KDIR seems to be missing
[20:40:23] <alex_joni> * alex_joni looks
[20:40:59] <cradek> I don't think you can build against headers on 4.20
[20:41:16] <cradek> I think it had the full kernel source tree
[20:41:21] <jmkasunich> all these commits to pickconfig have been putting the farm thru its paces, it has no clue that the tcl doesn't need compiled
[20:41:45] <jmkasunich> what changed in that 2-3 hour period?
[20:42:05] <alex_joni> I remember some commit from jepler about KDIR
[20:42:48] <alex_joni> -KDIR := $(shell cd /lib/modules/$(shell uname -r)/build; /bin/pwd)
[20:42:48] <alex_joni> +KDIR := $(shell cd $(KERNELDIR); /bin/pwd)
[20:43:02] <alex_joni> nothing wrong there imho
[20:44:06] <cradek> where does KERNELDIR come from?
[20:44:19] <alex_joni> KERNELDIR = /usr/src/kernel-headers-2.6.10-adeos
[20:44:24] <alex_joni> from Makefile.inc
[20:44:37] <alex_joni> but it seems it finds the headers, not the sources
[20:44:46] <cradek> I bet /lib/modules/2.6.10-adeos/build -> /usr/src/kernel-source/2.6.10-adeos
[20:44:55] <alex_joni> yup
[20:44:57] <cradek> alex_joni: it *should* find the headers, not the source
[20:45:10] <cradek> alex_joni: but the headers are busted on 4.20
[20:45:15] <alex_joni> so you should be able to compile against the headers always?
[20:45:16] <jmkasunich> same error on this box (BDI-4.27)
[20:45:29] <jmkasunich> looks the same anyway
[20:45:31] <cradek> just change it back...?
[20:45:32] <alex_joni> well, when they are not busted
[20:45:43] <jmkasunich> Compiling module_helper/module_helper.c -Wall -Werror -DRIP_MODULEDIR="/home/John/emcdev/emc2head/rtlib"
[20:45:43] <jmkasunich> Makefile:529: /usr/src/kernel-headers-2.6.10-adeos/arch/i386/Makefile: No such file or directory
[20:45:44] <jmkasunich> make[1]: *** No rule to make target `/usr/src/kernel-headers-2.6.10-adeos/arch/i386/Makefile'. Stop.
[20:45:49] <cradek> yes you should always be able to compile against just headers - my ubuntu packages work that way
[20:46:29] <cradek> and $RTS --linux-dir returns the right thing in my packages
[20:50:48] <cradek> "fixed" (put it back)
[20:51:07] <cradek> jmkasunich: can you kick it again?
[20:51:53] <jmkasunich> doing a build on my 4.27 box now for a faster answer, but yes
[20:52:00] <jmkasunich> worked here
[20:52:03] <cradek> ok
[20:52:14] <jmkasunich> got the warning about warning: passing arg 2 of `rt_task_init_cpuid' from incompatible pointer type
[20:52:34] <cradek> yeah, that must be different in different rtai versions
[20:53:21] <jmkasunich> restarted slots 4 and 5
[20:53:32] <jmkasunich> (not bothering with 2 & 3, we know they don't work)
[20:54:30] <cradek> alex_joni: are you integrating pickconfig/emc.in?
[20:54:36] <jmkasunich> I started that
[20:54:41] <cradek> ok
[20:54:45] <jmkasunich> give me a few mins
[20:54:51] <cradek> I'll go make tea
[20:56:00] <alex_joni> make me some too
[20:56:18] <jmkasunich> If I change emc.in, all I need to do is re-run ./configure, right?
[20:56:42] <jepler> jmkasunich: ./config.status regenerates emc from emc.in
[20:56:53] <jepler> jmkasunich: doesn't even need to go through all the configure steps again
[20:57:16] <jmkasunich> ok
[20:57:29] <jmkasunich> works for rip
[20:57:47] <alex_joni> and for install, but you need to make install too
[20:58:20] <jmkasunich> I meant "my changes to emc.in work for rip"
[20:58:25] <jmkasunich> need to test installed now
[20:58:44] <alex_joni> oh, what changes?
[20:58:48] <alex_joni> regarding picker?
[20:58:50] <jmkasunich> to use the picker
[20:58:53] <alex_joni> commit them
[20:59:33] <jmkasunich> ok
[20:59:39] <jmkasunich> got a problem with installed
[20:59:44] <cradek> I'll make a deb and test it
[20:59:49] <jmkasunich> permissions on picker aren't right
[21:00:00] <jmkasunich> John@main:~/emcdev/emc2head/src$ sudo make install
[21:00:00] <jmkasunich> Installing in with prefix /usr/local
[21:00:00] <jmkasunich> John@main:~/emcdev/emc2head/src$ emc
[21:00:02] <jmkasunich> /usr/local/bin/emc: line 1: /usr/local/share/emc/tcl/bin/pickconfig.tcl: Permission denied
[21:00:03] <cradek> yes, you'll have to change make install
[21:00:23] <jmkasunich> what should I change?
[21:00:42] <jmkasunich> or should I commit the emc.in changes and let you do the make ones?
[21:00:47] <jmkasunich> you - alex or cradek
[21:02:04] <cradek> huh none of tcl/bin is installed executable
[21:02:07] <cradek> should they all be
[21:02:08] <cradek> ?
[21:02:16] <alex_joni> cradek: yes
[21:02:21] <cradek> $(FILE) $(TCL_BIN) $(DESTDIR)$(tcldir)/bin
[21:02:28] <cradek> on this line just change FILE to EXE
[21:02:28] <alex_joni> * alex_joni can try that
[21:02:34] <alex_joni> jmkasunich: just commit
[21:04:38] <jmkasunich> committed
[21:08:26] <alex_joni> hmm.. sudo make install gives an error
[21:08:49] <cradek> I thought the inis were sorted
[21:09:01] <cradek> but mine aren't now
[21:09:01] <cradek> alex_joni: what error?
[21:09:03] <alex_joni> no, the problem is sample-configs/ppmc
[21:09:10] <jmkasunich> you mean in pickconfig?
[21:09:10] <cradek> yeah, it's empty
[21:09:11] <SWPadnos> they were before
[21:09:12] <cradek> jmkasunich: yes
[21:09:15] <alex_joni> which usually is not there (but I ran cvs up -d last time)
[21:09:17] <jmkasunich> they're not sorted, I need to fix that
[21:09:22] <alex_joni> if cvs up -dP then it's ok
[21:09:29] <cradek> alex_joni: right, I had that too
[21:09:30] <SWPadnos> harder to do when you retrieve from multiple dirs
[21:09:43] <jmkasunich> gonna sort on each dir
[21:09:45] <cradek> alex_joni: I didn't want to make $(INSTALL_CONFIGS) even more complex so I ignored it
[21:09:53] <SWPadnos> ah - that's easy then
[21:09:54] <jmkasunich> the dirs will be listed in the order they appear in the path
[21:10:39] <alex_joni> cradek: probably the sanes choice
[21:11:01] <alex_joni> ok, running /usr/local/bin/emc gives an ERROR: no configurations found in path
[21:11:05] <alex_joni> * alex_joni investigates more
[21:11:33] <jmkasunich> same here
[21:11:44] <jmkasunich> I think emc.in is passing the wrong path to picker
[21:11:54] <jmkasunich> just modded picker to echo the path in the error msg
[21:12:21] <jmkasunich> '/usr/local/etc/emc2'
[21:12:28] <alex_joni> oh, the problem is with sample-configs
[21:12:47] <alex_joni> it should be /usr/local/etc/emc2/sample-configs
[21:12:51] <jmkasunich> right
[21:12:52] <cradek> oh yeah, I never finished that
[21:12:54] <cradek> no
[21:12:54] <alex_joni> * alex_joni modifies configure for that
[21:13:01] <alex_joni> cradek: no?
[21:13:05] <cradek> /etc/emc2/sample-configs /usr/local/etc/emc2/configs
[21:13:15] <jmkasunich> with a colon ;-)
[21:13:18] <alex_joni> well, I did a default make install
[21:13:30] <alex_joni> which installs to /usr/local/etc/emc2/
[21:13:34] <alex_joni> not to /etc/emc2
[21:13:34] <cradek> oh
[21:13:39] <cradek> ok right
[21:13:41] <cradek> hmm
[21:13:50] <jmkasunich> there should still be two dirs in the path
[21:13:54] <jmkasunich> one for samples
[21:13:56] <alex_joni> right
[21:13:57] <cradek> we'll have to allow configure --with-configs-path=...
[21:13:59] <jmkasunich> the other for the users configs
[21:14:15] <jmkasunich> and the user one should be first
[21:14:17] <cradek> or, I bet it could be based on $prefix
[21:14:37] <jmkasunich> I like --with-configs-path
[21:14:41] <alex_joni> there is a $sysconfdir (the sample-configs one)
[21:14:52] <alex_joni> that one is figured out by configure
[21:14:52] <cradek> ok right
[21:14:54] <jmkasunich> some folks might want to include $HOME, others wont,
[21:15:26] <cradek> ~/emc2/configs:/usr/local/etc/emc2/configs:$sysconfdir/emc2/sample-configs
[21:15:28] <alex_joni> we could have the second one specified by ${prefix}/share/emc2/ or something
[21:15:45] <alex_joni> ok, then ${prefix}/etc/emc2/configs
[21:16:02] <cradek> no, that'll give you /usr/etc
[21:16:05] <cradek> you don't want that
[21:16:23] <cradek> I think just what I typed is the answer
[21:16:32] <alex_joni> and have it fixed?
[21:16:36] <cradek> yes
[21:16:41] <alex_joni> /usr/local/etc/emc2/configs ?
[21:16:55] <cradek> so if you install with --prefix=/usr --sysconfdir=/etc you still get /usr/local/etc/emc2/configs
[21:17:07] <cradek> the debian resource guide says you CAN do that
[21:17:12] <alex_joni> but also /etc/emc2/sample-configs
[21:17:19] <alex_joni> ok, I can live with that
[21:17:23] <cradek> you can't put files in /usr/local/etc, but you can create a directory there so the user knows where to put something
[21:17:23] <alex_joni> * alex_joni does it
[21:17:49] <alex_joni> basicly configure will be untouched
[21:17:58] <jmkasunich> I'm glad you guys know what you are doing
[21:18:06] <cradek> jmkasunich: are you talking to us??
[21:18:09] <jmkasunich> yes
[21:18:13] <jmkasunich> lol
[21:18:16] <alex_joni> we just seem to know
[21:18:18] <alex_joni> lol
[21:18:39] <jmkasunich> just committed a version of picker that prints the path it searched if it finds nothing
[21:18:40] <cradek> we alternately pretend to know what we're doing, and play along when someone else pretends
[21:18:52] <jmkasunich> cvs up, it might help straighten this out
[21:18:55] <alex_joni> jmkasunich: hope it still errors
[21:19:11] <jmkasunich> well if it doesn't, then the problem is fixed, right?
[21:19:19] <alex_joni> don't want the runscript to take off with that path
[21:19:29] <jmkasunich> prints to stderr
[21:19:31] <alex_joni> no, I mean the returncode
[21:19:34] <alex_joni> ok then
[21:20:26] <alex_joni> darn, cvs is slow today
[21:20:28] <alex_joni> at least here
[21:22:23] <jmkasunich> probably overloaded from all these committs
[21:23:06] <alex_joni> give me 2 more mins to test
[21:23:29] <cradek> 5 BDI-4.20 (2.6.10-adeos) 02/12/06 21:13:24 PASSED
[21:23:39] <alex_joni> yay
[21:23:41] <SWPadnos> jmk - you may be able to simplify the tree code by using the -selectable attribute
[21:24:02] <SWPadnos> though it wouldn't help for printing "pick something" messages
[21:24:04] <cradek> I would like it if non-leaves are not selectable (don't highlight)
[21:24:13] <SWPadnos> I agree
[21:24:15] <jmkasunich> now you tell me
[21:24:18] <SWPadnos> heh
[21:24:20] <jmkasunich> I agree tho
[21:24:21] <cradek> but jepler said that messes up keyboard navigation
[21:24:28] <SWPadnos> just looking through the BWidget docs now
[21:25:11] <SWPadnos> there's also a "takefocus" attribute
[21:25:17] <alex_joni> hrmm.. some more issues we needto resolve
[21:25:39] <jmkasunich> ok, sorting is sorted ;-)
[21:25:44] <alex_joni> cradek: I get a permission denied on /etc/init.d/realtime
[21:25:45] <jmkasunich> one line...
[21:25:58] <SWPadnos> one word, plus some brackets, I imagine ;)
[21:26:15] <jmkasunich> set subdir_list [ lsort $subdir_list ]
[21:26:40] <SWPadnos> you can do that in the assignment: set subdir_list [lsort [glob ... ] ]
[21:26:57] <jmkasunich> I'm not gonna worry about sorting multiple inis in one config, we're gonna discourage that practice anyway
[21:27:11] <jmkasunich> yeah, I could
[21:27:22] <jmkasunich> don't like heavy nesting tho
[21:27:25] <SWPadnos> heh
[21:27:42] <SWPadnos> not like performance will be a big issue there
[21:28:25] <SWPadnos> this stuff so very much screams for an xml-like config mechanism
[21:28:34] <SWPadnos> one file per config, instead of one dir
[21:28:59] <jmkasunich> makes the configs/common thing harder to do
[21:29:17] <SWPadnos> true
[21:29:33] <jmkasunich> damn, that reminds me
[21:29:47] <jmkasunich> my work is never done - now gotta make setupconfig work with the new layout
[21:29:52] <SWPadnos> heh
[21:30:04] <SWPadnos> cp pickconfig setupconfig ;)
[21:30:09] <cradek> jmkasunich: pickconfig looks *great*
[21:30:28] <jmkasunich> I don't think it ever worked with installed, esp. the new function - permission issues, etc
[21:30:31] <jmkasunich> thanks
[21:30:49] <jmkasunich> (and thanks to all who helped with code, and comments)
[21:31:30] <alex_joni> ok, emc should work now with the new picker on installed
[21:31:46] <alex_joni> * alex_joni digs up the permission denied problem
[21:31:47] <jmkasunich> farm BDI-4.20 slot is happy now!
[21:33:58] <alex_joni> darn, stupid typo again
[21:34:18] <jmkasunich> ERROR: no configurations found in path '/home/John/emc2/configs:/usr/local/etc/emc2/configs:sample-configs'
[21:34:22] <jmkasunich> that typo?
[21:34:30] <alex_joni> the last one, yes
[21:35:03] <alex_joni> it should be /usr/local/etc/emc2/sample-configs
[21:35:08] <alex_joni> not only 'sample-configs'
[21:35:30] <alex_joni> too many things I'm working on right now :)
[21:36:00] <alex_joni> cradek: still there?
[21:36:04] <cradek> yes
[21:36:21] <alex_joni> I have a question. any reason to install /etc/init.d/realtime as $(FILE) not $(EXE) ?
[21:36:36] <cradek> you're right, it needs to be EXE
[21:36:42] <jmkasunich> ERROR: no configurations found in path '/home/John/emc2/configs:/usr/local/etc/emc2/configs:=/usr/local/etc/emc2/sample-configs'
[21:36:56] <cradek> jmkasunich: you're joking
[21:36:56] <alex_joni> := ????
[21:36:57] <jmkasunich> whats with the :=?
[21:37:24] <jmkasunich> cvs up -dP ; cd src ; ./configure ; make ; sudo make install ; emc
[21:37:33] <alex_joni> hang on a minute
[21:37:34] <jmkasunich> aren't you doing that before you commit?
[21:37:49] <alex_joni> make/sudo make install; /usr/local/bin/emc
[21:37:59] <alex_joni> but I get configs from all 3 locations
[21:38:22] <alex_joni> so if the last is missing I don't notice right away :(
[21:38:22] <cradek> EMC2_CONFIG_DIR==${sysconfdir}/emc2/sample-configs
[21:38:24] <cradek> another typo
[21:38:52] <alex_joni> will someone else please fix that, I can't do it properly
[21:38:55] <alex_joni> :(((
[21:38:58] <cradek> I'll do it
[21:39:14] <alex_joni> thanks.. I need a closer position to my monitor
[21:39:44] <cradek> done
[21:40:08] <jmkasunich> one more time I test
[21:40:36] <jmkasunich> YES!
[21:40:43] <jmkasunich> damn...
[21:40:54] <alex_joni> something fishy with the realtime script
[21:40:56] <cradek> realtime not exe?
[21:40:58] <alex_joni> and location of modules
[21:41:05] <cradek> argh
[21:41:09] <jmkasunich> /usr/local/etc/emc2/sampld-configs is wider than the tree window
[21:41:14] <jmkasunich> (cosmetic only)
[21:41:38] <alex_joni> cradek: /usr/realtime-2.6.12-magma/modules/rtapi.ko no such file or directory
[21:41:59] <cradek> should be modules/emc2/
[21:42:30] <alex_joni> I think rtapi.conf doesn't get found, or is wrong looking now
[21:43:03] <jmkasunich> when I try it I get "missing rtapi.conf. Did you run 'make rtapi'"
[21:43:08] <cradek> there's crappy code in realtime to locate rtapi.conf
[21:43:11] <alex_joni> MODPATH=/usr/realtime-2.6.12-magma/modules
[21:43:25] <alex_joni> yeah, that can go away now, that configure makes it
[21:44:51] <cradek> does configure know where rtapi.conf is?
[21:45:02] <alex_joni> it can assume
[21:45:04] <jmkasunich> I hope so
[21:45:13] <alex_joni> because it goes to $sysconfdir
[21:45:13] <cradek> it's in $sysconfdir I guess
[21:45:26] <cradek> ok who is fixing realtime?
[21:46:48] <alex_joni> it's not realtime
[21:46:57] <alex_joni> the Submakefile that makes rtapi.conf
[21:47:00] <alex_joni> * alex_joni is fixing it
[21:47:09] <cradek> well realtime is also broken
[21:48:13] <alex_joni> I wonder why INSMOD and RMMOD get replaced differently in realtime
[21:48:22] <cradek> howso?
[21:48:29] <alex_joni> hang on, pasting
[21:49:17] <alex_joni> INSMOD="/usr/local/bin/emc_module_helper insert"
[21:49:18] <alex_joni> RMMOD="${exec_prefix}/bin/emc_module_helper remove"
[21:49:46] <cradek> I have never seen that
[21:50:11] <alex_joni> ok, seems the code in configure is different
[21:50:20] <cradek> I guess I did change it all recently
[21:50:25] <alex_joni> me too
[21:50:28] <alex_joni> but not both
[21:51:39] <alex_joni> aargh, CVS is soo slow
[21:52:20] <alex_joni> it's taking about 20 seconds to prompt for pass
[21:55:45] <SWPadnos> it's been like that for me for the past couple of weeks
[21:55:49] <SWPadnos> maybe 10-15 seconds
[21:57:01] <alex_joni> cradek: let me do the configure part
[21:57:20] <cradek> I only changed realtime.in
[21:57:24] <alex_joni> seen that
[21:57:26] <cradek> to honor RUN_IN_PLACE
[21:57:31] <cradek> chris@buster2:/usr/src/emc2$ time cvs diff directory.map
[21:57:31] <cradek> real0m5.170s
[21:57:45] <cradek> cvs response is pretty good here
[21:58:32] <alex_joni> real 0m24.801s
[21:58:37] <alex_joni> for the same one
[21:59:17] <cradek> ouch
[21:59:33] <alex_joni> now you can see why I'm bothered
[22:00:07] <alex_joni> but it's only cvs that's slow
[22:02:21] <SWPadnos> hmmm - there's got to be a way to get the vertical scrollbar to be line-based rather than character-based (when determining the scrollbar handle size)
[22:02:46] <cradek> you mean how it changes size as you scroll?
[22:02:47] <SWPadnos> it's a little disconcerting to have the size of the handle change as you scroll ;)
[22:02:49] <SWPadnos> yep
[22:02:57] <cradek> yeah, sucks, doesn't it
[22:03:01] <SWPadnos> yeah
[22:03:09] <SWPadnos> I like the program otherwise, though
[22:03:16] <jmkasunich> which program is that?
[22:03:21] <cradek> tk has had that bug for many years
[22:03:23] <SWPadnos> though double-click isn't working
[22:03:30] <SWPadnos> pickconfig
[22:03:37] <cradek> jmkasunich: any text that's line-wrapped and has a scrollbar
[22:06:18] <alex_joni> cradek: RTLIB is still wrong
[22:06:37] <alex_joni> or rtapi.conf
[22:06:57] <alex_joni> I used to generate a new rtapi.conf for the installed version
[22:07:50] <alex_joni> if you look at Makefile.inc I think the directories on top are wrong
[22:08:25] <cradek> alex_joni: I don't know what those are used for
[22:08:34] <cradek> alex_joni: they point to my source tree, even though I configured non-rip
[22:08:45] <alex_joni> they were used fo rbuilding
[22:08:53] <alex_joni> * alex_joni hacks them
[22:09:24] <cradek> * cradek stands back
[22:09:33] <alex_joni> I might break something..
[22:11:28] <cradek> that's fine
[22:11:28] <alex_joni> indeed I did
[22:11:41] <alex_joni> rtapi/rtai_ulapi.c:73:48: rtai_shm.h: No such file or directory
[22:12:50] <alex_joni> ok, I know what :)
[22:13:57] <cradek> hal/utils/m5i20cfg.c: In function `findpcicard':
[22:13:57] <cradek> hal/utils/m5i20cfg.c:447: warning: implicit declaration of function `getline'
[22:14:03] <cradek> did someone recently cause this?
[22:14:43] <SWPadnos> the last change in m5i20 was over 1 month ago
[22:16:34] <alex_joni> would be nice if jepler was around
[22:16:52] <cradek> anything I can help with?
[22:16:59] <alex_joni> there are still some Makefiles
[22:17:04] <alex_joni> in rtapi/examples
[22:17:10] <alex_joni> and hal/soemthing/vcp
[22:17:29] <alex_joni> and I was wondering what variables from Makefile.inc is he still using
[22:17:40] <alex_joni> I've seen $(LIB_DIR)
[22:17:48] <alex_joni> proabbly $(INCLUDE_DIR) too
[22:18:06] <alex_joni> err.. INC_DIR
[22:18:20] <alex_joni> not sure about TMP_DIR and RTTMP_DIR
[22:18:41] <alex_joni> there is a Makefile.lib in src/libnml
[22:18:48] <alex_joni> does that still work?
[22:19:05] <cradek> I don't know
[22:19:16] <alex_joni> see, jepler would be best now :)
[22:19:30] <alex_joni> * alex_joni is slowely working through this
[22:19:35] <alex_joni> slowly even
[22:19:58] <alex_joni> but it's compiling again
[22:20:29] <cradek> can I check in a change to emc.in?
[22:20:32] <alex_joni> sure
[22:23:06] <SWPadnos> if I apt-get source emc2 (on ubuntu), will that also grab everything needed to build emc2?
[22:23:13] <alex_joni> yes
[22:23:25] <alex_joni> including kernel
[22:23:32] <SWPadnos> ok - cool. I may blow away the BDI 4.2 on my laptop and switch to ubuntu there
[22:23:34] <cradek> or you can use apt-get build-dep emc2
[22:23:39] <SWPadnos> ok
[22:23:48] <cradek> if you just want to use the cvs version, for instance
[22:24:05] <SWPadnos> well - I may want to fiddle with some stuff on the plane tomorrow
[22:24:08] <SWPadnos> so cvs-able is good
[22:24:42] <cradek> let me know how it goes... reports have been really good lately
[22:24:53] <alex_joni> cradek: total silence?
[22:25:01] <SWPadnos> ok. I may have to download an ubuntu ISO - I may have only the AMD64 version
[22:25:17] <alex_joni> SWPadnos: bittorent better
[22:25:17] <cradek> alex_joni: the people with problems said my last kernel fixed them, other than that, not much
[22:25:28] <alex_joni> cradek: coo
[22:25:42] <alex_joni> ok, commiting soon, then I need to crash
[22:26:22] <alex_joni> cradek: can you take over if it's still not 100% ?
[22:26:48] <cradek> umm
[22:26:50] <cradek> I can try
[22:27:03] <cradek> but I'm not exactly sure what you're doing
[22:28:27] <alex_joni> fixing rtapi.conf
[22:28:48] <cradek> ok
[22:29:07] <alex_joni> another commit on the Submakefile, and I'm done
[22:30:04] <alex_joni> ask if you have any questions
[22:30:11] <alex_joni> I tried to comment as much as possible
[22:30:19] <alex_joni> in Makefile.inc.in
[22:30:22] <cradek> does it work now? :-)
[22:30:47] <alex_joni> building for the 10th time now :)
[22:32:42] <cradek> /usr/src/emc2/bin/milltask: error while loading shared libraries: librs274.so: cannot open shared object file: No such file or directory
[22:32:46] <cradek> _shm.c 238: shmget(1001(0x3E9),8192,0) failed: (errno = 2): No such file or directory
[22:32:49] <cradek> (rip)
[22:33:12] <alex_joni> /usr/local/bin/emc: line 436: /bin/emc_module_helper: No such file or directory
[22:33:32] <alex_joni> /usr/local/bin/halcmd: error while loading shared libraries: libnml.so: cannot open shared object file: No such file or directory
[22:35:17] <jmkasunich> why the hell is halcmd trying to access libnml?
[22:35:22] <alex_joni> ok, fixed the first one
[22:35:32] <alex_joni> for inifind I think
[22:35:34] <jmkasunich> oh
[22:35:52] <jmkasunich> that's stupid, inifind has nothing whatsoever to do with NML
[22:36:14] <jmkasunich> libnml should be NML, and nothing else
[22:36:26] <jmkasunich> (my 2 cents, I'll shut up now)
[22:36:34] <alex_joni> ok :)
[22:36:40] <alex_joni> but I might agree
[22:37:57] <alex_joni> ok, I'll fix emc.in (I know how), but I'm clueless on libnml.so
[22:38:15] <cradek> did it get put in /usr/local/lib?
[22:38:35] <alex_joni> hang on
[22:39:04] <alex_joni> fscking cvs again
[22:40:53] <alex_joni> yes, it's there
[22:42:25] <alex_joni> cradek: can you look what's wrong with the libnml.so ?
[22:42:32] <cradek> looking
[22:42:52] <cradek> try running ldconfig /usr/local/lib
[22:43:10] <alex_joni> lol, cvs ate my ${prefix} and ${exec_prefix} from teh commit message
[22:43:56] <cradek> did you type the message on the commandline?
[22:44:00] <cradek> or use an editor?
[22:44:04] <alex_joni> works now
[22:44:09] <cradek> ok
[22:44:20] <cradek> that fixes the libnml problem?
[22:44:23] <alex_joni> although tkemc is not executable
[22:44:25] <alex_joni> yes
[22:44:48] <cradek> I'll fix both
[22:45:06] <alex_joni> I know the later
[22:45:09] <alex_joni> but I'll let you
[22:45:41] <alex_joni> * alex_joni goes to bed
[22:45:59] <cradek> goodnight
[22:46:03] <alex_joni> night all
[22:46:04] <cradek> see you after the trip
[22:46:41] <alex_joni> rip emc barfs on pickconfig
[22:46:48] <alex_joni> because we have the same dir twice
[22:47:18] <alex_joni> ok, I'm really gone.. catch you guys later
[22:47:20] <alex_joni> bye
[22:47:28] <cradek> bye
[22:48:06] <cradek> jmkasunich: this means it's up to us...
[22:49:33] <SWPadnos> cradek, can you listen to a short feature request for axis?
[22:49:33] <cradek> hmm, this means it's up to me
[22:49:36] <SWPadnos> heh
[22:49:47] <cradek> hmm, this means it's up to me and SWPadnos
[22:49:55] <SWPadnos> urk - I'm packing for a trip ;)
[22:50:01] <cradek> what feature?
[22:50:24] <SWPadnos> put a draggable splitter between the G-code listing and the plot/control areas
[22:50:39] <SWPadnos> so I can resize the listing
[22:50:45] <cradek> we had that in 1.2 but it was buggy so we took it out
[22:50:57] <SWPadnos> ok - well, I'd prefer it withoug the bugs
[22:51:00] <SWPadnos> without
[22:51:04] <cradek> unfortunately it seems the tk widget that does that is flaky
[22:51:13] <SWPadnos> ok
[22:51:16] <cradek> but fwiw we both want that feature too
[22:51:19] <SWPadnos> bummer
[22:51:22] <SWPadnos> ok
[22:51:32] <cradek> maybe we'll work on it again sometime
[22:51:50] <SWPadnos> well - I can help a little bit (on pickconfig). I'm waiting for a download and a video capture to complete
[22:51:56] <SWPadnos> or whatever needs work now
[22:53:13] <SWPadnos> incidentally, I read an interesting thread regarding the use of .cvsignore file (for BSD, I think)
[22:53:44] <SWPadnos> they don't allow them, because make clean is supposed to return the tree to the pristine state, as though it was just untarred
[22:54:04] <SWPadnos> .cvsignore hides it when that doesn't happen
[23:04:25] <cradek> ok I think it's working right now
[23:04:35] <SWPadnos> well - glad I could help ;)
[23:05:11] <SWPadnos> it's amazing how th ehoney-do list grows when you're about to leave town
[23:11:39] <SWPadnos> ok - so I have a problem running this on BDI 4.2(something)
[23:11:54] <cradek> rip or installed?
[23:11:58] <SWPadnos> rip
[23:12:09] <cradek> what problem?
[23:12:24] <SWPadnos> one sec - gotta copy by hand ;)
[23:13:26] <SWPadnos> /Project/emc2/bin/io: relocation error: /Project/emc2/bin/io: undefined symbol: _ZN7InifileC1EV
[23:13:37] <SWPadnos> that C1EV may be ClEV (ell vs one)
[23:13:46] <cradek> wtf
[23:13:57] <cradek> did you make clean and rebuild everything?
[23:14:01] <SWPadnos> this may have to do with jmk's comments about nml and inifile being separate entities
[23:14:08] <SWPadnos> it's a clean checkout
[23:14:21] <cradek> is there an error above this one?
[23:14:24] <SWPadnos> ./configure --enable-run-in-place / make
[23:14:30] <SWPadnos> no
[23:14:34] <SWPadnos> not at run time
[23:14:40] <SWPadnos> I can make clean / make if you like
[23:15:18] <cradek> the checkout is newer than 14 mins? I just fixed some of this
[23:15:19] <SWPadnos> I may need to update though, I checked out 25 minutes ago ;)
[23:15:23] <SWPadnos> ok
[23:15:38] <cradek> and make sure you do a developer checkout
[23:15:46] <SWPadnos> yep, always do
[23:15:55] <SWPadnos> do I need to re-configure?
[23:16:00] <cradek> can't hurt
[23:16:23] <SWPadnos> ok, so ./configure / make clean / make (or is there a "more efficient" way?)
[23:16:29] <cradek> no that's it
[23:16:32] <SWPadnos> ok
[23:16:35] <cradek> don't forget --enable-run-in-place
[23:16:40] <cradek> then you need sudo make setuid at the end
[23:16:42] <SWPadnos> oops
[23:17:11] <SWPadnos> good thing the laptop is significantly faster than my real emc machine
[23:27:55] <SWPadnos> ok - that worked
[23:28:19] <cradek> great
[23:28:47] <SWPadnos> thanks, once I install axis, I'll be all set
[23:28:57] <SWPadnos> who knows what I can do on a 5 hour flight
[23:29:08] <SWPadnos> (who knows what I should do on a 5 hour flight?)
[23:29:10] <cradek> wish you had more battery, probably
[23:29:51] <SWPadnos> may be ;)
[23:30:01] <SWPadnos> I just might end up with a power jack though
[23:30:35] <SWPadnos> I actually get close to 4 hours with my big old laptop (with the 1400x1050 15" screen)
[23:47:25] <SWPadnos> wow - there's got to be something that changed in stepgen or emc2 in general
[23:47:45] <SWPadnos> the slowdown with BASE_PERIOD=50 uS is amazing
[23:48:12] <jmkasunich> on the phone, but we should talk about that
[23:48:28] <SWPadnos> ok - I'll be out for a bit, but I'll let you when I'm back
[23:51:26] <jmkasunich> I need to eat too
[23:51:39] <SWPadnos> yep - going to get take-out ;) (haven't left yet)