#emc | Logs for 2004-10-31

[00:35:08] <paul_c> Hi Steve
[00:35:22] <paul_c> You're too early for the Sunday meeting
[00:35:38] <SteveStallings> Hi Paul, just popping in because I may not be able to make the Sunday gig this week.
[01:02:57] <asdfqwega> Is robin or les about?
[01:03:28] <paul_c> Prod them and see.
[01:05:23] <asdfqwega> * asdfqwega fetches his electric cattle prod
[01:06:51] <paul_c> * paul_c hands asdfqwega a high capacity battery pack
[01:07:23] <asdfqwega> * asdfqwega prods robin_z [ZAP]
[01:07:54] <asdfqwega> * asdfqwega prods les [ZAP]
[01:08:18] <asdfqwega> Well, I don't smell burnt skin, they must not be there
[01:10:16] <asdfqwega> Paul, I figured out how to compile emcplot3d on non-realtime systems...now, is there any way to make invoking it easier?
[01:10:27] <asdfqwega> I wish I could just place it in /usr/local/bin
[01:11:08] <paul_c> is /usr/local/bin in your PATH ?
[01:11:18] <asdfqwega> Of course
[01:11:46] <paul_c> and have you tried moving the bin to there ?
[01:12:36] <asdfqwega> Hm...I think I did...I was kind of tired last night...I'll try again right now.
[01:15:41] <asdfqwega> Ah, now I remember - while it launches, and even supposedly loads the .ngc file, when I have it in /usr/local/bin, emcplot3d doesn't actually display the .ngc file
[01:16:46] <paul_c> any error messages ?
[01:17:55] <asdfqwega> The usual ones about nml stuff not being there...
[01:18:00] <asdfqwega> and "rs274ngc_init failed."
[01:18:16] <asdfqwega> I wonder if moving the interpreter over would work...
[01:19:30] <paul_c> Move all the bins to /usr/local/bin
[01:19:48] <paul_c> and copy librcs*.so to /usr/lib
[01:21:29] <asdfqwega> I'll try that, thanks.
[01:22:56] <asdfqwega> Now, if les or robin were around, I could ask them about sources of ZnSe optics...
[02:35:13] <alex_joni> hello
[02:38:43] <paul_c> Afternoon
[02:41:18] <alex_joni> what's up?
[02:42:57] <paul_c> waiting for a CD image to complete building...
[02:44:01] <alex_joni> what'S new? I've been pretty... busy lately
[02:44:08] <alex_joni> I was jsut reading through the logs
[02:45:23] <paul_c> nothing much to report.
[02:46:12] <alex_joni> how's i18n going?
[02:47:24] <paul_c> Need to have a word with John tomorrow about new directories.
[02:47:54] <alex_joni> yipiee.. I just found out their are releasing CDMA 1xEV-DO
[02:48:05] <alex_joni> s/their/they/
[02:48:18] <alex_joni> that's 2.4MBps down, 154 kbps up
[02:48:24] <alex_joni> on a mobile phone ;)
[02:51:31] <alex_joni> * alex_joni is checking the latest versions out
[02:52:27] <alex_joni> paul_c: did you get a chance to check BDI-TNG out? to see why configure is failing?
[03:03:27] <paul_c> nope
[03:04:16] <alex_joni> I'll figure it out with jmk tomorrow.. ok?
[03:05:14] <zwisk> greetings all...
[03:05:52] <alex_joni> hello.. just the man needed ;)
[03:06:01] <zwisk> oh? How can I be of service?
[03:06:15] <alex_joni> we'll need to discuss some tasks
[03:06:24] <alex_joni> what needs to be done, who'll do it etc
[03:06:27] <zwisk> Ok.
[03:06:39] <zwisk> So... What needs to be done and who will do it? :)
[03:06:39] <alex_joni> but I'm a little out of synch right now... catching up
[03:07:00] <Imperator_> Hi all
[03:07:09] <zwisk> hello!
[03:07:19] <Imperator_> Alex somebody is maybe interestet in your counter card
[03:07:28] <Imperator_> du you sell it ?
[03:09:32] <alex_joni> depends on how many...
[03:09:34] <alex_joni> ;)
[03:09:46] <Imperator_> i don't know
[03:10:08] <Imperator_> if you have more informations write me a mail, i forward it to him
[03:10:16] <alex_joni> what info?
[03:10:26] <alex_joni> zwisk: how about I18N ?
[03:11:28] <alex_joni> GTK_VER is not 100% accurate
[03:11:53] <Imperator_> what typ of card, how many counters, ..... price
[03:11:54] <zwisk> I put limited support for i18n in, and Paul did some touch up. I'm not sure what else needs work there. I guess strings need to be pulled out for 'english' and everything needs to be changed to gettext or somesuch.
[03:12:26] <alex_joni> from tcl, and c-source files?
[03:12:47] <alex_joni> question is: how much do we need internationalized?
[03:12:51] <zwisk> I guess so. That's an interesting problem. I dont' think I've ever seen an i18n tcl or bash file... ?
[03:12:55] <Imperator_> * Imperator_ have to run, must wash the lion mens
[03:13:05] <alex_joni> lol
[03:13:20] <alex_joni> Imperator_: tell us when they're awake ;)
[03:13:27] <Imperator_> * Imperator_ youcan see me on the webcam
[03:13:30] <alex_joni> :D
[03:13:35] <zwisk> see ya, Imperator_ :)
[03:13:51] <Imperator_> Imperator_ is now known as Imperator_away
[03:14:16] <alex_joni> how appropiate... I'm just listening to Queen - I'm going slightly mad ;)
[03:14:24] <zwisk> I don't know how much we *need* i18n, but I'd say if we have volunteers who want to do the translation, we should provide the framework for them.
[03:14:34] <zwisk> mm... classic queen...
[03:14:50] <alex_joni> better than most of the new stuff
[03:15:13] <alex_joni> well.. I could do some translations ... but I don't see the need here ;)
[03:15:21] <zwisk> I have a hard time listening to it straight through though. I don't know why, but I nee somethign to break them up a little.
[03:18:08] <alex_joni> guess i18n is on hold for now ;)
[03:18:36] <zwisk> on a completely different topic, has anyone been able to get INPUT_SCALE and OUTPUT_SCALE to work for them with emc2? I may just be doing things wrong (probably) but I seem to recall those being the way to adjust steps / inch on the display.
[03:19:06] <alex_joni> I don't think INPUT_SCALE & OUTPUT_SCALE are used right now in emc2
[03:19:07] <zwisk> yeah i18n is sorta paul_c's baby, I think... I'm happy to help out, but he's the point main I think.
[03:19:20] <zwisk> hmm... That seems to amke a lot of sense. :)
[03:19:26] <zwisk> I didn't see them doing anything.
[03:19:32] <alex_joni> you do have the scales however
[03:19:44] <alex_joni> as parameters to the *mod you use
[03:19:59] <alex_joni> freqmod, stepmod.. if my memory serves me right
[03:20:07] <alex_joni> can check if you want...
[03:20:11] <paul_c> * paul_c has one section ready for translation
[03:20:41] <zwisk> hmm... I'll take a look at module params...
[03:20:49] <alex_joni> * alex_joni is away for about 15 mins ... gotta make some wine :D
[03:21:20] <zwisk> paul_c, can you check your section into the autoconf branch?
[03:21:33] <zwisk> (Or is that what you're waiting to talk to the board about regarding directories?)
[03:21:57] <paul_c> Not the board, just jmk
[03:22:04] <zwisk> ahh...
[03:38:19] <alex_joni> * alex_joni is back
[03:39:17] <zwisk> it looks like scaling is now taken care of in core_stepper.hal, with position-scale. Does that sound right?
[03:39:22] <zwisk> (Welcome back, Alex)
[03:39:32] <alex_joni> let me check
[03:40:30] <zwisk> This seems to check out. The default is 5080, which is 2.54 times larger than 2000, which is what I need...
[03:41:06] <alex_joni> yup
[03:41:16] <alex_joni> right now they are fixed in core_stepper.hal
[03:41:28] <alex_joni> gotta talk to jmk how it should be done...
[03:41:34] <zwisk> right.
[03:41:42] <alex_joni> either loose INPUT_SCALE & OUTPUT_SCALE from emc.ini
[03:41:47] <alex_joni> and keep emc.ini generic
[03:41:54] <alex_joni> and set things in the proper hal
[03:41:56] <alex_joni> or:
[03:42:21] <alex_joni> read values from emc.ini and put those into the appropiate hal (defined also in emc.ini)
[03:42:35] <zwisk> right.
[03:43:13] <alex_joni> * alex_joni adds a mental note to ask jmk
[03:43:26] <zwisk> ok... I'm gonna go see if my mill moves properly now :)
[03:43:36] <zwisk> Thanks for the pointer, alex...
[03:44:23] <alex_joni> ;)
[03:46:30] <alex_joni> what is sharedstatedir?
[03:49:27] <alex_joni> zwisk: is #define bindir "@@bindir@@" supposed to be? so it doesn't get changed by configure? if yes.. who'll change it?
[03:53:00] <alex_joni> in rtapi.conf: RTLIB_DIR=... should that not include /emc2 as the last thing? gotta talk to the board (or at least jmk) about that
[04:29:59] <Imperator_away> Imperator_away is now known as Imperator_
[04:31:57] <alex_joni> hello back
[04:32:04] <alex_joni> how are the lion men?
[04:45:31] <alex_joni> * alex_joni is wondering if things are still broken for emc2-autoconf....
[04:53:00] <alex_joni> * alex_joni takes it back.. I just read the makefile... and found make run ;)
[05:00:32] <alex_joni> seems I'm having a small problem on emc2-autoconf
[05:00:57] <Imperator_> hi alex, the lions are good :-)
[05:01:08] <alex_joni> I can't jog... when I jog the machine goes into ESTOP
[05:02:14] <alex_joni> I think I traced it... it seems that modules (hal_parport, stepgen, scope-rt) don't get loaded
[05:02:24] <Imperator_> * Imperator_ is a bit busy at the moment must fly to south africa this night, and havent prepared anything
[05:05:31] <alex_joni> hmmm.. south africa sounds nice... ;)
[05:08:41] <Imperator_> i will see
[05:08:49] <zwisk> alex: I think the @@bindir@@ is probably an error...
[05:10:01] <zwisk> hopefully make run is going away...
[05:13:31] <zwisk> John! :)
[05:13:36] <jmkasunich> hi
[05:13:45] <zwisk> greetings!
[05:14:04] <jmkasunich> you've been busy this week
[05:14:15] <jmkasunich> * jmkasunich is trying to catch up
[05:14:17] <zwisk> I suppose so...
[05:14:46] <jmkasunich> I have some thoughts on how halcmd.c should find modules - but I need to look closer at what you've already done forst
[05:14:50] <jmkasunich> first
[05:15:04] <zwisk> ok...
[05:15:18] <zwisk> wait for it ....
[05:15:21] <jmkasunich> right now I'm bringing the compile farm back online (we had a brief power failure yesterday afternoon)
[05:15:26] <CIA-3> 03zwisk 07auto_configure_0_1 * 10emc2/src/config.h.in:
[05:15:26] <CIA-3> fixed a typo which caused bindir to be incorrectly set. Thanks go to
[05:15:26] <CIA-3> alex_joni for spotting it.
[05:15:41] <zwisk> That's so cool.
[05:15:47] <jmkasunich> yep
[05:15:56] <jmkasunich> I wish I could get the farm to react that fast
[05:16:16] <zwisk> yeah. But if any one of us could do that, we'd be making big bucks in a whole different field.
[05:17:01] <alex_joni> hello john
[05:17:12] <zwisk> I'd like to get your thoughts at some point about configuration of hal components as well. I ran into INPUT_SCALE and OUTPUT_SCALE not working (and being replaced by stepgen.x.position-scale, and wonder how we'll fix that in a longer term way.
[05:18:00] <alex_joni> zwisk: regarding that.. is stepgen always the one to output pulses?
[05:18:25] <zwisk> hm... that may be a better question for john? :) I think it is for me :)
[05:19:17] <zwisk> Changing position-scale did fix things for me; I am not outputting the proper number of steps per unit distance.
[05:19:24] <jmkasunich> sorry, kvm'ed away to the farm - I'll be back in a bit
[05:19:27] <zwisk> umm... s/not/now/
[05:21:03] <alex_joni> sorry ;) wanted to ask you something.. but then I wrote the question for john ;)
[05:22:33] <jmkasunich> * jmkasunich is back
[05:22:53] <alex_joni> hey john... long time ;)
[05:23:19] <jmkasunich> only since last weekend
[05:23:29] <alex_joni> yup.. but then it was pretty short
[05:23:34] <alex_joni> quick question:
[05:23:43] <jmkasunich> I don't get much time online during the week, even on a normal week, and last week wasn't normal
[05:23:45] <alex_joni> could I ssh to the farm?
[05:24:05] <jmkasunich> not without me doing some more setup that I'm not sure I know how to do
[05:24:13] <alex_joni> ;)
[05:24:21] <jmkasunich> also, I don't have a static IP address
[05:24:27] <alex_joni> well.. then .. better not
[05:24:38] <alex_joni> I wanted to figure out what's happening to BDI-TNG
[05:24:40] <jmkasunich> I don't know how often it changes, but it does change
[05:24:44] <alex_joni> why configure is failing
[05:25:07] <jmkasunich> I can try to help
[05:25:23] <alex_joni> thx
[05:25:25] <jmkasunich> BTW, the latest results should be online now
[05:26:05] <zwisk> what's the url again?
[05:26:16] <jmkasunich> linuxcnc.org/compile_farm
[05:26:21] <zwisk> cool.
[05:27:47] <jmkasunich> BTW, this box (my main one) is also running TNG
[05:28:16] <jmkasunich> * jmkasunich does a cvs up
[05:29:35] <jmkasunich> "kernel source tree not configured"
[05:29:45] <alex_joni> yup...
[05:29:54] <jmkasunich> and "version.h now fount - is the the kernel headers package installed?"
[05:29:55] <alex_joni> means that rtai-setup is somehow fishy
[05:30:21] <alex_joni> version.h is looked for in the Kerneldir specified in realtime-config
[05:30:37] <alex_joni> but unfortunately realtime-config doesn't include the kerneldir
[05:30:47] <jmkasunich> where is realtime-config again?
[05:31:00] <alex_joni> it should be in /usr/realtime
[05:31:06] <alex_joni> but.. it's not there ;)
[05:31:16] <alex_joni> because rtai hasn't been installed
[05:31:22] <jmkasunich> there is no /usr/realtime
[05:31:31] <alex_joni> it's still in /usr/src/rtai.../scripts/realtime-config
[05:31:45] <alex_joni> that's correct, that there is no /usr/realtime
[05:32:08] <zwisk> rtai-24.1.10 doesn't do the cool rtai-3 stuff with /usr/realtime. rioght?
[05:32:13] <alex_joni> you need to run some make command from /usr/src/rtai.. in order to create /usr/realtime
[05:32:19] <alex_joni> it does some
[05:32:40] <jmkasunich> since paul didn't do that, no TNG install will ever have /usr/realtime
[05:32:40] <alex_joni> but you need to make install_rt_something (forgot how it's named)
[05:32:49] <alex_joni> exactly
[05:33:02] <alex_joni> that's why we need a workaround for BDI-TNG
[05:33:15] <jmkasunich> what exactly is realtime-config supposed to tell you?
[05:33:22] <alex_joni> a lot of stuff
[05:33:36] <alex_joni> just a moment
[05:33:37] <jmkasunich> paths to rtai stuff?
[05:33:49] <alex_joni> paths, gcc used, flags, etc
[05:33:54] <alex_joni> kernel dir
[05:34:41] <zwisk> module-dir, cxx, cc, prefix, lxrt-flags ...
[05:34:48] <alex_joni> problem is there are 3 versions
[05:34:59] <jmkasunich> of realtime-config?
[05:35:00] <alex_joni> rtai-config (for rtai3.x)
[05:35:07] <alex_joni> realtime-config (for rtai24.x)
[05:35:27] <alex_joni> rtlinux-config (for some rtlinux, not sure what vers)
[05:35:41] <alex_joni> so ./configure has to figure out which exists, where it is, etc
[05:35:43] <alex_joni> and from there get stuff out of it
[05:36:18] <alex_joni> for example realtime-config doesn't have a --linux-dir ( so we grep'ed through the file to take that out)
[05:37:27] <alex_joni> zwisk: love the make run !!!!
[05:37:41] <jmkasunich> what is make run?
[05:37:49] <alex_joni> it's make all
[05:37:50] <zwisk> thanks... I'll like it better when things just run in place, though.
[05:37:56] <alex_joni> and make install into test
[05:37:59] <alex_joni> and runs emc
[05:38:03] <zwisk> make run compiles and runs emc.run in a test install directory. yeah.
[05:38:15] <alex_joni> maybe spill out some message at the end of ./configure ?
[05:38:24] <alex_joni> in order to test things do a make run
[05:39:56] <zwisk> hopefully 'make run' and 'make fresh' will go away when we get everything to where it can run from install locations, and also from the src tree. I think we're close, though the install stuff is a bit of a hack, changing relative paths to absolute paths.
[05:40:20] <alex_joni> still doesn't load the stepgen module
[05:40:24] <alex_joni> and hal_parport
[05:40:38] <jmkasunich> wouldn
[05:41:04] <jmkasunich> I wouldn't be surprised if the loadrt code in halcmd.c is totally screwed up - it was a total hack when I did it
[05:41:13] <zwisk> make run doesnt? (It works for me with rtai-3.1)
[05:41:21] <jmkasunich> it worked in place only
[05:41:25] <alex_joni> where is the insmod?
[05:41:42] <jmkasunich> halcmd.c forks and execs insmod
[05:41:44] <zwisk> Yeah, I hacked the halcmd.c to work in install as well. That's what the include.h.in file was for.
[05:42:05] <alex_joni> I meant where is the stuff called from?
[05:42:12] <jmkasunich> ?
[05:42:22] <alex_joni> don't seem to find stepgen in emc.run
[05:42:32] <jmkasunich> core_stepper.hal
[05:42:42] <jmkasunich> emc.run parses the ini file
[05:42:47] <alex_joni> I see
[05:42:52] <jmkasunich> the ini file calls out one or more .hal files
[05:43:02] <zwisk> we should talk sometime about ini files and such.
[05:43:04] <jmkasunich> those hal files are passed to halcmd
[05:43:09] <jmkasunich> yes - that needs work
[05:43:16] <alex_joni> we could now.. ?
[05:43:20] <jmkasunich> ok
[05:43:38] <alex_joni> so... as I see it, there are more .hal files
[05:43:42] <zwisk> where to start? ;) I don't really like that emc.ini gets rewritten at shutdown.
[05:44:06] <jmkasunich> that's a carryover from emc1, and I don't even know what module does it
[05:44:06] <alex_joni> can we state that some are machine specific, and some are hal-specific?
[05:44:37] <jmkasunich> alex_joni: my view of emc and hal interaction:
[05:44:55] <jmkasunich> a machine controller is a connection of interconnected hal modules and other programs
[05:44:58] <zwisk> There seems to be a problem in that potentially C, tcl, and maybe even bash scripts need to get and put info to and from the ini file(s)
[05:45:14] <jmkasunich> get at least
[05:45:27] <jmkasunich> I'm not sure how many different progs need to write to the ini
[05:45:32] <alex_joni> jmk: I agree so far
[05:45:37] <paul_c> * paul_c prods jmkasunich
[05:45:43] <zwisk> I like the idea (I think) of *only* get. The only possible exception would be some sort of 'wizard' that helps you set up the ini file(s)
[05:45:50] <jmkasunich> I'm rather command line oriented - I think only the user should write to the ini file
[05:46:08] <alex_joni> or maybe some PID tuning? -- if PID is stored in the ini
[05:46:36] <jmkasunich> true about the tuning
[05:46:49] <jmkasunich> * jmkasunich wonders what the prod was about
[05:46:58] <zwisk> what about state? The last X, Y, Z location? I dont' really know taht I feel that belongs in the .ini ...
[05:47:28] <alex_joni> you are going into a dangerous direction zwisk
[05:47:32] <jmkasunich> I was unaware that X,Y,Z was preserved from one run to another
[05:47:43] <alex_joni> that sounds like homing to me..
[05:47:53] <alex_joni> * alex_joni remembers some long talks about homing ;)
[05:48:12] <zwisk> Yeah... I know... I live dangerously, I guess. And I've not been in on homing discussions, so perhaps that's why I'm fearless.
[05:48:21] <alex_joni> lol
[05:48:37] <alex_joni> let's skip that for now... (right now the values don't get remembered)
[05:48:39] <jmkasunich> you're talking about saving locations to avoid homing
[05:48:43] <alex_joni> maybe the could and will...
[05:48:43] <jmkasunich> ?
[05:49:02] <alex_joni> jmk: yes ;) if it's certain the machine can't move while switched off
[05:49:14] <jmkasunich> perhaps the var file would be more appropriate for that - in any case, I agree we should skip it for now
[05:49:35] <zwisk> I think it's not certain ... mine certainly can move switched off. But var is exactly my thought too.
[05:50:18] <alex_joni> lets get back to .hal and .ini
[05:50:23] <jmkasunich> ok
[05:50:34] <zwisk> John, do you think you could go through the emc.ini file that we have now, and comment out all the items that no longer get used, since hal has it's own config?
[05:50:44] <jmkasunich> maybe
[05:51:11] <zwisk> That might be a good start for some cleaning.
[05:51:30] <jmkasunich> you already mentioned one that is a good example of a problem with HAL: OUTPUT_SCALE
[05:51:40] <alex_joni> and INPUT_SCALE
[05:51:41] <zwisk> right.
[05:52:06] <jmkasunich> I look at HAL as a very modular system, and think that scaling should be done close to the hardware
[05:52:09] <alex_joni> jmk: is stepgen the only one outputting step pulses?
[05:52:12] <jmkasunich> so stepgen has scaling
[05:52:25] <jmkasunich> both stepgen and freqgen can output step pulses
[05:52:25] <zwisk> hmm.. I just found emc.var. I'm not sure what that is.
[05:52:40] <alex_joni> lol... leave it be for now :D
[05:52:46] <jmkasunich> and once there is a driver for something like Jon E's USC card, it can also put out step pulses
[05:52:57] <zwisk> I haven't looked at hal in a long time (since almost a year ago, when you were first talking about hal)
[05:53:14] <alex_joni> hmmm... depends on the driver
[05:53:18] <jmkasunich> right
[05:53:24] <zwisk> How do you feel about /proc ? :)
[05:53:37] <jmkasunich> proc for what?
[05:53:44] <alex_joni> hal-stats?
[05:53:54] <jmkasunich> like pin lists, etc?
[05:54:00] <alex_joni> there are some rtapi in /proc... right?
[05:54:16] <jmkasunich> yes
[05:54:31] <zwisk> yes... pin lists, etc...
[05:54:39] <jmkasunich> but nothing you really _need_, so if your system doesn't have a /proc filesystem, you can still use rtapi
[05:54:47] <zwisk> You could use proc to manage and report on the state of almost everything.
[05:54:59] <alex_joni> halcmd does most of that
[05:55:02] <jmkasunich> if pin lists, etc were implemented thru /proc, then people without proc would be stuck
[05:55:11] <alex_joni> don't think we should need to change that...
[05:55:27] <alex_joni> s/should/could/
[05:55:36] <jmkasunich> if we could assume that everyone has /proc, I would seriously consider using it
[05:55:37] <zwisk> I guess. Who doesn't use proc? I'm getting off topic. Just curious...
[05:55:57] <zwisk> Are there any distributions without proc?
[05:56:06] <alex_joni> not that I know of
[05:56:16] <jmkasunich> you can certainly build a kernel without it, but I don't know if anybody does
[05:56:56] <alex_joni> back to .ini and .hal
[05:57:02] <alex_joni> my machine is still not working ;)
[05:57:28] <jmkasunich> it is an important issue for the hal refactor
[05:57:28] <jmkasunich> right now, halcmd can get at the linked lists, cause they live in shared mem... the refactor will move them into kernel memory, so halcmd will need a better way to access the lists
[05:57:28] <jmkasunich> the /proc filesystem could be one way
[05:57:28] <zwisk> I think alex is probably right, halcmd likely does everything we'd want already, but... proc just seems like a really ellegant solution to tuning and configuring modules.
[05:57:51] <jmkasunich> zwisk - something to keep in mind for the hal refactor
[05:57:57] <alex_joni> we can do it when the refactor is the topic..
[05:58:05] <zwisk> yeah.
[05:58:08] <zwisk> So, ini files...
[05:58:13] <alex_joni> I agree /proc sounds nice...
[05:58:16] <alex_joni> ini
[05:58:22] <jmkasunich> and scaling
[05:58:22] <alex_joni> there is a emc.ini
[05:58:26] <alex_joni> and there can be more
[05:58:29] <alex_joni> not just scaling
[05:58:31] <alex_joni> ;)
[05:58:37] <alex_joni> one ini per machine?
[05:58:39] <jmkasunich> but scaling is a good example of an issue
[05:58:46] <alex_joni> per setup
[05:58:59] <jmkasunich> IMO (and this is by no means unanimous), emc.ini should be considered an example
[05:59:16] <jmkasunich> and the real ini for a machine should be mylathe.ini or whatever
[05:59:37] <zwisk> It seems we could use a utility to handle accessing ini files. I'd like to see us have 1 config methodology. However, hal configs seem fundamentally different than ini's.
[05:59:39] <alex_joni> * alex_joni remembers some vague discussions about this from ... ray ?
[05:59:54] <alex_joni> hal configs are files that get fed to halcmd
[06:00:12] <alex_joni> just like you would enter the commands yourself (manually)
[06:00:13] <jmkasunich> I'm afraid some of my hal ideas aren't ideal for emc
[06:00:31] <alex_joni> I like them so far...
[06:00:36] <zwisk> So, from a system standpoint, do we keep emc and hal completely seperate? Or does emc provide some way to configure hal someday?
[06:00:37] <jmkasunich> HAL became a way to interactivelly build a system
[06:00:56] <alex_joni> halcmd is pretty plexible.. but it's a PITA to write all commands
[06:01:02] <zwisk> I think that's cool.
[06:01:03] <alex_joni> so .hal is heaven ;)
[06:01:24] <zwisk> Perhaps emc should build that hal system from it's config files using halcmd?
[06:01:24] <alex_joni> yup... but you wouldn't want to write them every time..
[06:01:52] <jmkasunich> note that however you build a system (.hal, or individual commands, or a mixture), you can to "halcmd save all" and the result is a .hal file that should restore that configuration
[06:02:05] <jmkasunich> (in theory - in practice, it doesn't handle loading modules yet)
[06:02:28] <zwisk> I think we should get into using modprobe at some point for that... but, again, I digress...
[06:02:46] <alex_joni> will it?
[06:02:54] <jmkasunich> but the main issue seems to be that I designed HAL to keep modules as segragated as possible
[06:02:57] <alex_joni> handle module loading I mean
[06:03:04] <jmkasunich> meaning each module has it's own configs, for example
[06:03:25] <alex_joni> insmod stepgen cfg="5 0 0"
[06:03:36] <zwisk> Can modules be modified after being loaded? Can cfg be changed after load-time?
[06:03:48] <jmkasunich> zwisk: no
[06:03:53] <jmkasunich> not now anyway
[06:04:14] <jmkasunich> for the refactor, I want to get away from insmod time parameters
[06:04:16] <zwisk> Good thing to think about for refactoring... Being able to easily and quickly tweak/change things is desireable, methinks.
[06:04:21] <alex_joni> it has been discussed...
[06:04:46] <jmkasunich> the insmod command you gave above does two things - first it loads the realtime stepgen module
[06:04:48] <alex_joni> ok.. so we have one .ini
[06:04:59] <jmkasunich> second, it exports 3 drivers, one mode 5 and two mode 0
[06:05:00] <alex_joni> I forgot the period param
[06:05:11] <jmkasunich> I'l like to separate the loading and exporting parts
[06:05:34] <jmkasunich> so you could load it with "insmod stepgen"
[06:05:55] <jmkasunich> then export drivers (channels, whatever you want to call them) with a halcmd command
[06:06:00] <jmkasunich> "export 5"
[06:06:01] <zwisk> right. In the past, I've used proc for this. You can send commands to modules through proc, like "instantiate 1" or "export 5 0 0"...
[06:06:07] <alex_joni> cool..
[06:06:20] <jmkasunich> hopefully you could "unexport" as well
[06:06:32] <zwisk> yes. Or list attributes and modify them.
[06:06:46] <alex_joni> sound's flexible all right...
[06:06:50] <zwisk> Proc can be a directory tree, as well, so your cool configuration node concepts (with numbered items) can be proc nodes ...
[06:07:11] <zwisk> It keeps configuration seperated to a per module concept if you like, or you can have modules intermix in directories.
[06:07:57] <jmkasunich> good discussions here - want to save them
[06:08:04] <alex_joni> ok.. let's drift back
[06:08:11] <alex_joni> logger_aj, bookmarks
[06:08:11] <alex_joni> See
[06:08:14] <alex_joni> logger_aj, bookmark
[06:08:14] <alex_joni> See
[06:08:23] <zwisk> alex_joni: you were saying, "one .ini file" ...
[06:08:47] <alex_joni> yup.. so we have one ini file which includes more .hal files (points to them)
[06:09:29] <alex_joni> reading from emc.ini:
[06:09:42] <alex_joni> HALFILE1 = core_stepper.hal
[06:09:51] <alex_joni> HALFILE2 = standard_pinout.hal
[06:10:19] <zwisk> hmm... we get into all sorts of interesting semantics quikcly.
[06:10:32] <jmkasunich> modularity is both a strength and a weakness of hal
[06:10:58] <zwisk> indeed.
[06:11:21] <jmkasunich> if you have steppers with stepgen, you set scaling by "setp stepgen.0.position-scale = 1234"
[06:11:39] <jmkasunich> if you have steppers with freqgen, you set scaling with a different setp command
[06:11:48] <jmkasunich> if you have servos, you use yet another command
[06:12:00] <alex_joni> yup...
[06:12:09] <alex_joni> on freqgen you have a velocity scale
[06:12:19] <zwisk> can the hal 'pin' model be used to connect 'servo 0' to configuration parameter 'AXIS0' somehow?
[06:12:25] <alex_joni> and you must have a different module to feedback.. right?
[06:12:32] <jmkasunich> that's good, if you build your machine from the bottom up - get the motors working, then add emc above them to do the overall controll
[06:13:10] <zwisk> I really want a config utility. :)
[06:13:10] <jmkasunich> because in the bottom up version, you can't depend on emc to set the scaling
[06:13:14] <alex_joni> zwisk: define configuration parameter 'AXIS0'
[06:13:30] <zwisk> alex: AXIS_0 from emc.ini
[06:13:31] <alex_joni> zwisk: the best thing would be a halgui
[06:13:37] <alex_joni> I see... not really
[06:13:43] <zwisk> perhaps more than just hal, though, right?
[06:13:48] <alex_joni> AXIS_0 contains a lot of things
[06:13:58] <jmkasunich> right
[06:14:02] <alex_joni> most of them to be sent to hal (using setp)
[06:14:12] <zwisk> yes, which is the point. "stepgen.0" needs to be able to axis the things in "AXIS_0" (if mapped) and take what it needs.
[06:14:12] <jmkasunich> right
[06:14:15] <alex_joni> not link pin
[06:14:35] <jmkasunich> the problem is that I want to be able to set up and test an axis using hal alone
[06:14:56] <zwisk> I think that's a fine goal, john.
[06:15:06] <zwisk> Once it's tested, though, should not the config live in emc.ini somehow?
[06:15:07] <alex_joni> I like that too
[06:15:12] <alex_joni> I did it like that
[06:15:16] <alex_joni> in .hal
[06:15:23] <alex_joni> because it's emc-independent
[06:15:38] <zwisk> so, now we have emc.ini and lots of *.hal's ...
[06:16:00] <alex_joni> well... we could have one .hal per machine.. but that would clutter things up
[06:16:06] <jmkasunich> zwisk: yes, once it's tested, you should just be able to use it without thinking about hal again
[06:16:41] <alex_joni> when splitting the .hal into more.. you could have some .hal's that you never change
[06:16:57] <zwisk> So how does hal get mapped to emc? What causes stepgen.0 to be considered AXIS_0 inside emc?
[06:16:59] <alex_joni> like (one basic for stepper operation, e.g. core_stepper.hal)
[06:17:11] <jmkasunich> that's the logic behind "core-stepper.hal" and "standard-pinout.hal"
[06:17:36] <alex_joni> you have a axis.0. inside .hal
[06:17:47] <jmkasunich> there is a xylotex-pinout.hal that flips the step and dir pins, for xylotex cards
[06:18:15] <alex_joni> e.g. Xpos-cmd (is a signal that maps axis.0.motor-pos-cmd with stepgen.0.position-cmd)
[06:18:25] <jmkasunich> zwisk: I didn't think it thru completely... but in general, *.ini should config the core of emc
[06:18:32] <alex_joni> same with Xpos-fb
[06:18:43] <zwisk> so, I think that means that all AXIS_[0123] should get pulled from emc.ini ?
[06:18:46] <jmkasunich> and *.hal connects the core to the outlying modules like stepgen
[06:19:01] <zwisk> does hal take care of PID tuning somehow then?
[06:19:23] <jmkasunich> my thoughts on that were that yes, hal would handle tuning
[06:19:35] <jmkasunich> IOW, tuning parameters would be hal parameters
[06:19:45] <jmkasunich> associated with the PID hal module
[06:19:50] <alex_joni> if you want to run an axis (joint) independent of emc.. you should have tuning
[06:19:54] <alex_joni> btw.
[06:19:58] <jmkasunich> exactly
[06:20:04] <alex_joni> it's easier to tune with some scope feedback
[06:20:14] <jmkasunich> you might tune an axis using siggen, scope, and the hal modules only
[06:20:26] <zwisk> so, what's the 'top' level that hal exports then? step/dir? Position?
[06:20:37] <alex_joni> maybe in the future (near or far) some utility which paints the motor response...
[06:20:42] <alex_joni> position-cmd
[06:20:46] <alex_joni> and position-fb
[06:20:50] <jmkasunich> zwisk: do you do electronics?
[06:20:58] <zwisk> ok. So emc says go to this position, and hal does that?
[06:21:02] <zwisk> yep, I do electronics.
[06:21:03] <alex_joni> as far as I see it in core_stepper.hal
[06:21:05] <jmkasunich> pretty much
[06:21:18] <jmkasunich> ok - so do I, and that's what drives my mental model of HAL
[06:21:25] <alex_joni> hal takes care how to get there...
[06:21:36] <zwisk> How are multiple axis coordinated?
[06:21:43] <alex_joni> how to drive (be it steppers, servo, AC, etc.)
[06:21:45] <jmkasunich> HAL is a block diagram - it shows what "blocks" you have, and how they are connected
[06:22:02] <jmkasunich> the emc core does multi-axis coordination
[06:22:26] <alex_joni> the whole thing get's fed into the NGC
[06:22:33] <jmkasunich> the "emc core" block has position command outputs for each axis (and position feedback inputs for each axis)
[06:22:48] <zwisk> Ok... but... if it's giving location data to hal, how does hal coordinate multiple locations on mulitple axis? Does EMC break it into small 1 dimensional moves for hal?
[06:22:50] <jmkasunich> you connect those outputs to whatever other HAL blocks are appropriate for the motor
[06:23:12] <alex_joni> zwisk: yes for small 1 dimensional moves
[06:23:17] <jmkasunich> * jmkasunich can't talk without draqwing pictures
[06:23:38] <jmkasunich> emc spits out position commands for all axis simultaneously
[06:24:03] <zwisk> ok.. I'm good. I think I've got it now.
[06:24:08] <jmkasunich> each command is sent to individual step generators, or PID blocks, or whatever that axis needs
[06:24:33] <zwisk> Ok, so from a bottom up architecture, Hal is really cool. The user, howevever, needs somehow to feel like they're working in a unified system.
[06:25:02] <zwisk> That may just be tools that wrap around emc and hal to make it look like one system.
[06:25:18] <jmkasunich> zwisk: you've hit the nail on the head
[06:25:35] <jmkasunich> I like the bottom up, and once you grok the concepts it's very powerfull and flexible
[06:25:39] <alex_joni> that could be halgui?
[06:25:39] <zwisk> So, am I right ins aying that (almost) all of the AXIS_* comes out of emc.ini ?
[06:25:47] <jmkasunich> but if you want to work top down, it isn't very friendly
[06:26:22] <jmkasunich> zwisk - the problem is that some info is needed by both the low level and the high level
[06:26:26] <zwisk> I think realtime configuration in the rework is even more important given this realization, because top-down folks will need tools that rework the things at the bottom, and rebuild up for them.
[06:26:46] <zwisk> could be halgui.
[06:27:07] <alex_joni> I am thinking of something LabView-like
[06:27:16] <zwisk> But it should encompass more than hal. It needs to tie in the things in emc.ini that need to be 'synced' with hal. LIke that axis 1 in lienar, and 2 is angular, etc...
[06:27:32] <jmkasunich> or axis1 max speed
[06:27:39] <alex_joni> yes... and axis scale
[06:27:53] <zwisk> axis scale right now is a hal thing. Axis max speed is ... an emc thing?
[06:27:58] <jmkasunich> the hal needs to know (stepgen max freq, for instance) and emc core also needs to know (for trajectory planning)
[06:28:31] <jmkasunich> right now, hal and emc get max vel from different places, and the user is responsible for keeping them matched
[06:28:32] <jmkasunich> that
[06:28:34] <jmkasunich> that's bad
[06:28:38] <zwisk> what if the emc.ini file contains HAL blocks?
[06:29:05] <alex_joni> that could work...
[06:29:16] <zwisk> putting a hal block within AXIS_1 that is responsible for setting up axis_1 might make sense.
[06:29:27] <jmkasunich> I don't understand
[06:29:34] <alex_joni> need some halcmd adjustments in order to disregard stuff it doesn't know
[06:29:54] <alex_joni> jmk: in emc.ini ...
[06:29:58] <alex_joni> at axis 0
[06:30:06] <alex_joni> you could have some hal stuff
[06:30:10] <jmkasunich> duh "hal block" = "sequence of halcmd commands"?
[06:30:17] <alex_joni> yup
[06:30:20] <zwisk> if [AXIS_1] in emc.ini countains a [HAL] block taht contains all the hal cmds (like the .hal file) to create all the hal modules...
[06:30:39] <zwisk> yeah... hal cmds.
[06:31:03] <alex_joni> or at least some AXIS_HAL = axis0.hal
[06:31:09] <jmkasunich> that would help - keeps related stuff together
[06:31:28] <alex_joni> or something like that (although I like the first version better)
[06:32:05] <jmkasunich> the ini format doesn't allow nested blocks
[06:32:14] <paul_c> * paul_c steps into the middle of a converstation...
[06:32:27] <jmkasunich> go right ahead
[06:32:43] <paul_c> You guys talking about nested [SECTIONS] ?
[06:32:59] <jmkasunich> not really, we just wandered into that topic
[06:33:03] <zwisk> I guess... though I'm not sure that's a requirement.
[06:33:23] <paul_c> 'cos you can't nest [FOO] inside [BAR]
[06:33:24] <jmkasunich> instead of having the hal data in it's own section, but the hal configs for each axis in that [AXIS] section
[06:33:38] <jmkasunich> exactly - that's what I just pointed out
[06:34:00] <zwisk> Maybe it's just HAL_AXIS_1 then ...
[06:34:08] <paul_c> The ini file parser treats each [ as the end of section marker
[06:34:14] <jmkasunich> would require a significant rewrite of the ini parser
[06:34:18] <alex_joni> right after AXIS_1
[06:34:27] <alex_joni> you could have HAL_AXIS_1
[06:34:37] <alex_joni> no need of rewriting
[06:34:50] <jmkasunich> if we really wanted to, we could modify the parser so it treats [/FOO] as the end of section [FOO]
[06:34:51] <alex_joni> jmk: loadrt loads the module?
[06:35:01] <jmkasunich> yes
[06:35:02] <alex_joni> XML like?
[06:35:05] <zwisk> It's almost tempting to see if there is a config library out there we could use.
[06:35:14] <paul_c> There is a couple
[06:35:22] <zwisk> Why reinvent the parser when others do it and maintain it.
[06:35:36] <jmkasunich> what we're talking about is only a partial fix tho
[06:35:44] <asdfqwega> * asdfqwega [lurking] Not wanting to derail this train of thought...
[06:36:16] <alex_joni> * alex_joni is having a closer look why halcmd loadrt is not loading the proper modules
[06:36:25] <jmkasunich> we would still have "setp stepgen.0.max_freq" and "[AXIS_0] max_speed", and the user would have to keep them in sync
[06:36:44] <jmkasunich> all we're discussing is how to keep them close together to make it easier
[06:36:45] <zwisk> that seems like a bit of a shame.
[06:37:00] <jmkasunich> zwisk:
[06:37:09] <jmkasunich> zwisk: that's the good and bad of hal
[06:37:13] <alex_joni> hmmm.. short question here
[06:37:21] <jmkasunich> being able to set stepgen.0.max_freq when testing the axis is goot
[06:37:24] <jmkasunich> good
[06:37:35] <alex_joni> what's the ration between stepgen.max_freq and max_speed ?
[06:37:35] <jmkasunich> but having to separately tell the traj planner about it is bad
[06:37:41] <zwisk> yep, the good and bad. but maybe we can make emc help out by doing more of the configuration of hal somehow?
[06:37:52] <alex_joni> s/ration/ratio/
[06:38:15] <jmkasunich> alex_joni: the ratio isn't neccessarily simple - one might be in Hz, the other in mm/sec
[06:38:22] <zwisk> hey... what if we extend HAL to allow emc to ask hal, generically, for those parameters?
[06:38:24] <alex_joni> exactly...
[06:38:25] <jmkasunich> (max speed _is_ in length/sec)
[06:38:37] <alex_joni> how could the user be able to tweak that?
[06:38:43] <jmkasunich> but emc has to know which ones to ask for
[06:38:45] <zwisk> EMC should ask the underlying HAL system what it's fastest rate is.
[06:38:50] <alex_joni> and I mean USER
[06:39:18] <jmkasunich> a stepper axis: stepgen.0.max_freq * stepgen.0.position_scale (I think)
[06:39:27] <jmkasunich> for a servo axis, it will be different
[06:39:49] <zwisk> EMC should just ask for what it knows. HAL, which knows what type it is (and has the position_scale) should answer properly.
[06:40:09] <alex_joni> yup.. that's very wise spoken
[06:40:10] <jmkasunich> but HAL doesnt' know
[06:40:19] <zwisk> what doesn't hal know?
[06:40:37] <jmkasunich> * jmkasunich needs a pencil again
[06:40:48] <jmkasunich> there is no "HAL" as an entity
[06:41:02] <alex_joni> hal after loading all the appropiate .hal files
[06:41:07] <jmkasunich> hal is just a shell that glues together blocks as the user (or configurator) instructs it
[06:41:13] <zwisk> Hmm... maybe there should be? A hal "machine" abstraction, into which all of these components load?
[06:41:25] <alex_joni> that's emc..
[06:41:32] <zwisk> slightly below that :0
[06:41:46] <jmkasunich> actually not below it at all
[06:42:07] <jmkasunich> the emc motion module is just another block
[06:42:13] <zwisk> Something that knows the concept of the axis and can feed back up the type, maximum rates, max speed, max acceleration, etc...
[06:42:15] <jmkasunich> as is the g-code interpreter, etc
[06:42:24] <jmkasunich> today, emc.run is what loads the blocks
[06:42:26] <zwisk> g-code interpreter is a hal module?
[06:42:53] <jmkasunich> no - they aren't hal blocks, but they are blocks in the larger sense of being distinct programs that are loaded by emc.run
[06:43:02] <zwisk> hmm... well it can't be both ways, right? Either hal is smart enough to load the blocks, and dictates everything, or the blocks are set up in .hal files and emc asks what gets set up for it's properties.
[06:43:21] <jmkasunich> before, there were only a few blocks - hal has made many more, which complicates things
[06:43:21] <zwisk> sorry... that should be "either emc is smart enough".
[06:43:35] <alex_joni> jmk: is there any place I should check why halcmd loadrt is failing?
[06:43:42] <alex_joni> besides trying it manually
[06:43:48] <jmkasunich> what error message does it give?
[06:43:58] <alex_joni> well it can't find the pins
[06:44:11] <alex_joni> I don't get an error message regarding the module loading
[06:44:11] <jmkasunich> pins? loadrt doesn't care about pins
[06:44:36] <jmkasunich> are you running a single loadrt command, or a hal file with loadrt and other commands as well
[06:44:45] <alex_joni> I am running emc.run :D
[06:44:48] <zwisk> doh... sorry guys, I gotta go. I'll try to catch up on the conversation tomorrow...
[06:44:56] <jmkasunich> ok zwisk
[06:45:02] <alex_joni> bye.. zwisk
[06:45:12] <zwisk> later!
[06:45:21] <alex_joni> this conversation was really needed... (however it's not over yet )
[06:45:30] <jmkasunich> definitely
[06:45:45] <alex_joni> I do get:
[06:46:00] <alex_joni> HAL: ERROR: Can't find module 'stepgen' in
[06:46:12] <alex_joni> guess it has no idea where the modules are
[06:46:19] <jmkasunich> right
[06:46:23] <jmkasunich> * jmkasunich opens halcmd.c
[06:46:43] <paul_c> which branch are you using ?
[06:47:04] <alex_joni> autoconf
[06:47:17] <paul_c> try the main trunk
[06:47:21] <alex_joni> I'
[06:47:33] <paul_c> the autocong may be broken
[06:47:33] <alex_joni> last time it worked... should work now too
[06:47:37] <alex_joni> it sure is..
[06:47:43] <alex_joni> I am trying to see where
[06:47:56] <jmkasunich> in the autoconf branch, halcmd.c, line 903
[06:48:12] <jmkasunich> add a printf there to see what file it's trying to load
[06:48:17] <jmkasunich> probably missing the path
[06:48:55] <jmkasunich> hmmmm
[06:48:58] <alex_joni> just a mo.
[06:49:11] <jmkasunich> what is the main directory called for your cvs checkout?
[06:49:24] <jmkasunich> emc2? or something else, like emc2auto?
[06:49:36] <alex_joni> it's /usr/local/nist/emc2-autoconfigure/emc2
[06:50:07] <jmkasunich> and the halcmd executable is in /usr/local/nist/emc2-autoconfigure/emc2/bin?
[06:50:16] <alex_joni> hmm.. not really
[06:50:21] <alex_joni> after make test
[06:50:21] <jmkasunich> well that's why
[06:50:59] <alex_joni> stuff get's copied into emc2/test/usr/local/bin
[06:51:04] <alex_joni> the bin stuff anyways
[06:51:17] <jmkasunich> loadrt looks up the path to it's own executable, then goes up one step, and looks for /rtlib
[06:51:39] <alex_joni> the modules go to emc2/test/lib/modules/2.4.21-adeos/rtai/
[06:51:41] <jmkasunich> that _only_ works for run in place - I planned all along to do something better, but you guys are way ahead of my
[06:51:46] <alex_joni> in the main branch yes...
[06:52:06] <alex_joni> but in the autoconf branch there are some things modifies to allow it to work... just not 100% ok yet
[06:52:39] <alex_joni> there's an ENV variable HAL_RTMOD_DIR that get's checked (around line 809)
[06:53:11] <jmkasunich> right - IF that is set correctly, then it should work
[06:53:45] <jmkasunich> otherwise you're screwed, cause the rest of that cruft breaks miserably unless the directory structure is just right
[06:53:57] <alex_joni> yup..
[06:54:10] <alex_joni> I see some /proc/self/exe support in here .. ;)
[06:54:13] <jmkasunich> so if you set the env variable manually, does it work?
[06:54:15] <alex_joni> JS-was around
[06:54:19] <alex_joni> let me try
[06:54:24] <jmkasunich> nope - that was me
[06:54:33] <alex_joni> really?
[06:54:40] <alex_joni> he did add some comments thou..
[06:54:41] <jmkasunich> yes
[06:55:27] <jmkasunich> * jmkasunich looks to see what he added (I think it's lines 825-830)
[06:57:11] <jmkasunich> then next two blocks (the one using proc/self/exe, and the one that uses the current working dir) were mine
[06:57:31] <alex_joni> strange is: the module dir gets found
[06:57:36] <alex_joni> but it's void
[06:57:37] <paul_c> while we are on the subject of adding stuff...
[06:58:07] <alex_joni> I don't get any of the first errors (cannot locate realtime modules dir or module path too long)
[06:58:17] <alex_joni> but the last, can't find module....
[06:58:37] <paul_c> jmkasunich: Did you see my proposals in the Dirctory.map ?
[06:59:00] <jmkasunich> not yet - haven't been online much this week
[06:59:20] <jmkasunich> alex_joni: do you have any idea where "moduledir" comes from?
[06:59:41] <jmkasunich> he stat's it, then uses it if the stat passes, but I can't find moduledir anywhere
[07:00:10] <alex_joni> it comes from Makefile.inc
[07:00:12] <alex_joni> I think
[07:00:15] <jmkasunich> oh... #include "../../config.h"
[07:00:21] <alex_joni> yes.. there
[07:00:28] <jmkasunich> * jmkasunich doesn't like that
[07:00:44] <jmkasunich> paul_c: which branch?
[07:00:51] <paul_c> main trunk
[07:01:06] <alex_joni> * alex_joni doesn't like that either
[07:01:30] <paul_c> It's only for language translations
[07:01:31] <jmkasunich> you mean the i18n stuff? seems good to me
[07:01:41] <alex_joni> although... I first thought this is about RTLIB
[07:01:42] <jmkasunich> is "po" a convention for i18n?
[07:01:50] <paul_c> need src/po and tcl/msgcat
[07:01:58] <alex_joni> jmk: yes (about po)
[07:02:16] <jmkasunich> * jmkasunich knows nothing about i18n
[07:02:26] <jmkasunich> I wonder how it will be done in the kernel modules?
[07:02:34] <paul_c> It won't
[07:02:36] <alex_joni> what? i18n?
[07:02:43] <alex_joni> you don't want to go there ;)
[07:02:57] <alex_joni> I would be happy if the user interface benefits from i18n
[07:03:04] <alex_joni> that's a lot...
[07:03:14] <jmkasunich> could it be done at compile time: "./configure --language=en"
[07:03:20] <alex_joni> sure
[07:03:50] <alex_joni> there is some i18n in configure.in already
[07:03:54] <paul_c> Language support needs (must) be a run time thing
[07:04:37] <alex_joni> paul_c: what if you need to compile with messages in a different language?
[07:05:32] <paul_c> Messages intended for the "user" will come via the usr interface
[07:06:21] <jmkasunich> * jmkasunich is thinking of a) messages in the kernel logs, and b) messages initiated in kernel space and passed up to user space for display to users
[07:06:52] <jmkasunich> a) would need to be handled at compile time, and could be ignored (english always)
[07:07:26] <jmkasunich> b) could possibly be translated in user space (maybe it isn't actually a message, just a message number, and the user space code looks up the actual text)
[07:07:35] <robin_z> surely, the option of kernel messages in Hungarian is worht pursuing?
[07:07:41] <alex_joni> lol
[07:07:52] <jmkasunich> * jmkasunich smacks robin_sz
[07:07:57] <robin_z> <ouch>
[07:07:58] <alex_joni> only if you use Hungarian notation of the variables
[07:08:22] <alex_joni> * alex_joni fears a smack himself...
[07:08:22] <paul_c> * paul_c asks asdfqwega for the use of his cattle prod
[07:08:51] <jmkasunich> does the linux kernel do i18n of log messages (ie, can you build a Hungarian kernel?)
[07:09:10] <alex_joni> now thats something to remember
[07:09:18] <alex_joni> "a Hungarian kernel"
[07:09:19] <alex_joni> lol
[07:09:24] <asdfqwega> paul_c: Sure. [hands it over]
[07:09:25] <robin_z> probably. but it will be more devious than your average kernel
[07:09:47] <alex_joni> maybe a Greek gcc to compile a Hungarian kernel...
[07:09:56] <jmkasunich> <bzzzzzzt>
[07:10:06] <asdfqwega> listening to you guys, I think I need to read up again on what HAL is.
[07:10:30] <alex_joni> a Hungarian Abstraction Layer :))
[07:10:34] <robin_z> I've been trying to add Greek as a languge type to an app. recently ... nightmare
[07:10:54] <robin_z> * robin_z points out he is of Hungarian abstraction ...
[07:11:04] <alex_joni> * alex_joni is too...
[07:11:12] <alex_joni> * alex_joni is too... some 25%
[07:11:17] <robin_z> kewl ;)
[07:11:21] <robin_z> 50% here ...
[07:11:28] <jmkasunich> and all along I thought "Szmeti" was a nice British name
[07:11:31] <asdfqwega> * asdfqwega rolls his eyes...
[07:11:33] <robin_z> anyway ... we digress ...
[07:11:34] <alex_joni> I never would have guessed :D
[07:11:35] <robin_z> ;)
[07:11:47] <alex_joni> well.. back to loadrt
[07:11:57] <andras> what, who's Hungarian in here?
[07:12:06] <paul_c> Don't ask
[07:12:11] <jmkasunich> Serb and Croat a coupld generations back
[07:12:17] <alex_joni> andras surely doesn't sound like hungarian
[07:12:21] <alex_joni> lol
[07:12:22] <asdfqwega> I was hungarian, but then I et lunch.
[07:12:33] <robin_z> doh
[07:13:01] <robin_z> well ... back to loadrt ...
[07:13:27] <jmkasunich> that's why I want a hal.conf sitting somewhere (maybe in /etc)
[07:13:53] <robin_z> sounds about right
[07:14:20] <alex_joni> seems it's running now
[07:14:33] <alex_joni> I exported HALRTMOD_DIR=...
[07:14:39] <robin_z> I always saw the RT side as a service that should be started at boot time, perhaps from /etc/init.d .. things then connect to it
[07:14:40] <alex_joni> I'll add it to the make run
[07:14:57] <jmkasunich> here's a thought:
[07:14:59] <alex_joni> that's how it's thought off
[07:15:22] <jmkasunich> when you insmod hal_lib, pass it the path to the rtmoddir
[07:15:44] <jmkasunich> then halcmd can ask hal_lib for the path
[07:16:25] <alex_joni> hmmm...
[07:16:34] <robin_z> or put that in /etc/hal.d/ ?
[07:16:51] <alex_joni> neah...
[07:16:52] <jmkasunich> thinking about run in place tho...
[07:17:02] <alex_joni> RT = scripts/realtime
[07:17:04] <jmkasunich> if installed, hal.conf would be in /etc
[07:17:12] <alex_joni> that can go to /etc/init.d
[07:17:13] <robin_z> 'k
[07:17:16] <jmkasunich> if run-in-place, it would be somewhere else
[07:17:44] <alex_joni> how do you feel about make test?
[07:17:52] <jmkasunich> not to happy
[07:18:06] <robin_z> hmmm
[07:18:22] <robin_z> its pretty much a standard ...
[07:18:28] <jmkasunich> robin_z: make test is not what you think (wish) it is
[07:18:33] <robin_z> 'k
[07:19:12] <jmkasunich> make test does a "test install" as a way around the fact that "make all" no longer generates something that can run where it was compiled
[07:19:35] <robin_z> hmmm
[07:19:58] <robin_z> * robin_z goes for tea
[07:20:09] <jmkasunich> you should be able to do "make" and then run the new code, once happy, do make install to install it
[07:20:27] <jmkasunich> the run-in-place must not conflict with an existing install
[07:20:28] <alex_joni> you can run make run
[07:20:29] <alex_joni> :D
[07:20:38] <alex_joni> which doesn't conflict with nothing...
[07:20:43] <jmkasunich> * jmkasunich needs to add version checking to hal shared memory
[07:20:48] <alex_joni> but I admit it needs some tweaking
[07:22:11] <alex_joni> I don't like the env thing...
[07:22:27] <jmkasunich> me neither
[07:22:45] <jmkasunich> the whole loadrt command is a kluge right now
[07:22:47] <alex_joni> I switched to another console ... and emc isn't running anymore
[07:22:58] <jmkasunich> huh?
[07:23:03] <CIA-3> 03paul_c * 10emc2/src/po/ (README rs274_err.pot): Just one of several files that will eventually go to make up the i18n translations for emc2
[07:23:13] <jmkasunich> switch to other console, switch back, and emc is dead?
[07:23:26] <alex_joni> no... switch to other console, and run emc from there
[07:23:42] <jmkasunich> that's cause the export doesn't extend to the other console
[07:23:43] <alex_joni> no export HAL_RTDIR_ stuff there so it fails..
[07:23:54] <alex_joni> I know.. that's why I don't like it
[07:24:03] <alex_joni> maybe add the export to emc.run ?
[07:24:10] <alex_joni> when installing emc.run?
[07:24:10] <jmkasunich> perhaps
[07:24:19] <alex_joni> with the proper dir...
[07:25:30] <jmkasunich> the problem is that we're starting to decline into ah-hocery
[07:26:08] <andras> quick question: does Tim Goldstein pop in here now and then, or can I reach him on another irc channel?
[07:26:14] <alex_joni> into what?
[07:26:23] <paul_c> Tim who ?
[07:26:32] <andras> :)
[07:26:40] <jmkasunich> never seen him here - I think he went away from emc a couple years ago
[07:26:47] <paul_c> You would need to email him direct
[07:26:49] <andras> ok thanks
[07:26:56] <jmkasunich> alex_joni: ad-hockery
[07:27:05] <jmkasunich> as hoc literally means "for this"
[07:27:06] <paul_c> unless it is an easy question
[07:27:11] <jmkasunich> ad hoc
[07:27:35] <jmkasunich> in other words, band-aids, instead of well thought out general solutions
[07:27:56] <alex_joni> yup... same impression here
[07:27:58] <paul_c> "band-aids" = "Sticky plaster"
[07:28:08] <jmkasunich> plaster is for walls
[07:28:11] <jmkasunich> ;-)
[07:28:45] <alex_joni> ok.. let's chew this through...
[07:29:04] <alex_joni> halcmd needs to load the module
[07:29:07] <alex_joni> right?
[07:29:09] <jmkasunich> I see one specific problem: how does halcmd loadrt know where to find it's modules
[07:29:24] <jmkasunich> but the general problem is "how does any part of emc find it's other parts"
[07:29:45] <alex_joni> well... it can be based on directory.map
[07:29:57] <jmkasunich> technically, halcmd doesn't need to do the load, you could use insmod directly
[07:30:02] <jmkasunich> but loadrt makes things cleaner
[07:30:13] <alex_joni> but... when you install .. things get moved
[07:30:30] <jmkasunich> note that loadrt can make things more secure too
[07:31:03] <alex_joni> make sure it's a hal_module, etc
[07:31:18] <jmkasunich> right
[07:31:37] <jmkasunich> that's why I want hal modules in a different dir than other kernel modules
[07:32:02] <alex_joni> deffinately
[07:32:35] <jmkasunich> can we make a list of other related issues - other programs and scripts that need to find specific paths?
[07:32:41] <alex_joni> smthg like /lib/modules/`uname -r`/emc
[07:33:08] <alex_joni> or /../rtai/emc
[07:33:17] <alex_joni> where .. is module dir
[07:34:08] <jmkasunich> yeah
[07:34:24] <jmkasunich> * jmkasunich looks at install.map and directory.mal
[07:34:51] <alex_joni> and I don't really like everything copied into /usr/local/bin/
[07:35:09] <alex_joni> I would love /usr/local/emc/bin
[07:35:36] <alex_joni> and /usr/local/emc/etc, /lib, /man, /share
[07:35:41] <alex_joni> maybe /opt/emc
[07:37:32] <jmkasunich> but then you have to add /usr/local/emc/bin to the PATH
[07:37:40] <alex_joni> hmmm.. yes
[07:38:00] <alex_joni> not good either
[07:38:17] <jmkasunich> there's a crap load of tcl files... I didn't realize there were so many
[07:38:38] <alex_joni> most are not needed for emc to run
[07:38:47] <alex_joni> they are usefull ... but not needed
[07:38:54] <alex_joni> maybe put those somewhere else?
[07:39:06] <jmkasunich> I'm the wrong person to ask
[07:39:19] <jmkasunich> don't know much about the Linux Filesystem Hierchary
[07:39:25] <jmkasunich> can't spell it either
[07:39:40] <alex_joni> lol...
[07:39:49] <alex_joni> well.. me neither
[07:39:51] <paul_c> LFSH
[07:40:13] <jmkasunich> that's easier to spell - but I still don't know crap about it
[07:40:48] <alex_joni> paul_c: hope you didn't write that pot file by hand...
[07:40:57] <paul_c> Of couse
[07:41:12] <paul_c> every single line...
[07:41:25] <alex_joni> script?
[07:41:28] <jmkasunich> paul_c: what is the url for LFSH?
[07:41:45] <paul_c> was tagged and then run through xgettext
[07:41:51] <alex_joni> * alex_joni is watching http://www.gnn.tv/content/emosh_hi.html
[07:42:13] <paul_c> one sec jmkasunich
[07:42:35] <paul_c> http://www.tldp.org/guides.html
[07:42:47] <paul_c> http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/index.html
[07:44:24] <jmkasunich> I notice that /proc doesn't appear in the root directory (even as optional)
[07:44:39] <paul_c> For a very god reason
[07:44:47] <paul_c> /god/good/
[07:44:50] <jmkasunich> enlighten me
[07:45:04] <paul_c> It is a virtual filesystem
[07:45:22] <paul_c> that does not exist until the kernel is loaded
[07:45:22] <alex_joni> procfs
[07:45:50] <jmkasunich> how common is /proc today? would we be shooting ourselves in the foot if we relied on it?
[07:46:50] <paul_c> There is a move towards /sys in the 2.6 kernel
[07:47:01] <paul_c> but /proc is still around
[07:47:13] <jmkasunich> does /sys replace proc?
[07:47:34] <paul_c> It is unlikely to disappear overnight - Too many apps rely on it.
[07:48:21] <jmkasunich> that's not encouraging tho - disappering whether overnight or not isn't good
[07:48:24] <paul_c> /sys is not a replacement for /proc
[07:49:04] <jmkasunich> I was wondering about /proc as as way for the kernel parts of the refactored hal to communicate with user space programs like halcmd
[07:49:14] <jmkasunich> lists of pins, signals, etc
[07:50:00] <paul_c> No.
[07:50:14] <jmkasunich> care to elaborate?
[07:50:44] <paul_c> Use /proc for status info and small amounts of config data
[07:51:22] <paul_c> For example, a /proc entry could be used to display the current configuration
[07:51:45] <jmkasunich> "configuration" for hal means the list of modules loaded
[07:51:51] <jmkasunich> and the lists of pins, signals, etc
[07:51:54] <paul_c> but I would caution against using it as a means to pass config data to the kernel modules.
[07:54:26] <jmkasunich> we digress
[07:54:32] <jmkasunich> * jmkasunich reads LFHS
[07:54:36] <jmkasunich> LFSH
[07:55:31] <jmkasunich> says /usr/etc (and by extension /usr/local/etc) are virtually unused these days
[07:55:47] <robin_z> yip
[07:56:15] <alex_joni> how was the tea?
[07:56:19] <robin_z> /opt is getting a bit thin as well ..
[07:56:35] <robin_z> not managed to even eat it yet ..
[07:56:48] <robin_z> small children interfered ...
[07:57:29] <jmkasunich> hmmmmm - a thought for the halcmd loadrt problem
[07:58:13] <jmkasunich> /proc/hal/module_path (created by the hal_lib module, which must be loaded before any HAL stuff works) contains the path to the hal modules
[07:59:10] <alex_joni> I think hal.conf can also solve the problem
[07:59:26] <jmkasunich> but where does hal.conf go?
[07:59:28] <alex_joni> I added a HAL_RTMOD_DIR=// into hal.conf
[07:59:32] <alex_joni> depends
[07:59:34] <paul_c> jmkasunich: Might work as long as /proc has been mounted
[07:59:46] <alex_joni> when installed it goes to /usr/local/etc
[07:59:56] <alex_joni> or even /etc/hal/
[08:00:02] <alex_joni> that has to be decided
[08:00:09] <jmkasunich> and when running in place?
[08:00:20] <alex_joni> right now it's modified by configure
[08:00:24] <alex_joni> and by make test
[08:00:36] <alex_joni> which installs it in /test/usr/local/etc
[08:00:36] <jmkasunich> and how does a halcmd or a script know which one to use
[08:00:58] <alex_joni> well emc.run get's modified by make install
[08:01:21] <alex_joni> there's a sed command inside make install (actually more)
[08:02:08] <jmkasunich> what's interesting is that there can be only one _loaded_ hal_lib.o kernel module, even if there are bunches on the disk (one installed, multiples that have been compiled in different trees)
[08:02:54] <jmkasunich> once a particular hal_lib.o has been loaded, that should determine what modules are used (I think?)
[08:03:36] <alex_joni> hmmm.. and how does hal_lib know?
[08:03:52] <jmkasunich> lol
[08:03:52] <alex_joni> should the loading of hal_lib specify the path?
[08:04:09] <jmkasunich> maybe all I'm doing is moving the problem upstream
[08:04:38] <jmkasunich> but insmod hal_lib rtlibpath=foo isn't out of the question
[08:05:11] <jmkasunich> that command would normally be part of the realtime script
[08:05:18] <jmkasunich> which has to know the paths anyway (I think)
[08:05:55] <jmkasunich> * jmkasunich backs up a step
[08:06:24] <jmkasunich> what determines whether you are running the installed version or a specific "run-in-place" version of emc?
[08:06:35] <jmkasunich> the directory where you issue the emc.run command?
[08:06:55] <jmkasunich> or the directory in which the emc.run script resides?
[08:07:05] <alex_joni> no... the fact that emc.run get's modified by install
[08:07:20] <alex_joni> but right now.. there is no run-in-place
[08:07:20] <jmkasunich> wait a minute
[08:07:30] <alex_joni> it's a installed-to-temp version
[08:07:53] <jmkasunich> I'm not talking about the installed-to-temp stuff, IMO that's something we need to get away from
[08:08:00] <jmkasunich> I'm talking about "how should it work"
[08:08:23] <alex_joni> hmmm.. but then we need to think about 2 cases...
[08:08:30] <jmkasunich> if I'm in my home directory, /home/John/, and I type "emc.run", I expect the installed version (if any) to run
[08:09:07] <jmkasunich> if I'm in /home/John/emcdev/emc2cvs and type ./emc.run, I want to run the version in the emc2cvs tree (run-in-place)
[08:09:31] <alex_joni> fair enough
[08:09:34] <jmkasunich> likewise if I'm in /home/John, but I type "emcdev/emc2cvs/emc.run"
[08:10:44] <jmkasunich> and the same goes for halcmd, and all the other binaries... If I type "halcmd", I want to run the installed one (presumably in my $PATH), if I type ./halcmd, or <path>/halcmd, I want to run a specific one
[08:11:18] <jmkasunich> same goes for the realtime script
[08:12:09] <jmkasunich> make sense to you?
[08:13:18] <alex_joni> well..
[08:13:33] <alex_joni> sure does
[08:14:07] <jmkasunich> (all I'm trying to do right now is make sure we're agree about what we want... _then_ we try to figure out how to implement it)
[08:14:41] <alex_joni> okay.. fair enough
[08:14:45] <alex_joni> so...
[08:15:05] <alex_joni> what goes where... should be clear
[08:15:15] <alex_joni> from directory.map and install.map
[08:15:19] <alex_joni> right?
[08:15:34] <jmkasunich> maybe
[08:16:27] <jmkasunich> if I say "emc.run" I want to run the installed emc.run, which by default reads the installed "emc.ini", and that in turn points to installed "foo.hal"
[08:16:40] <alex_joni> well.. even if things get changed, it's pretty clear
[08:16:44] <alex_joni> right
[08:16:57] <alex_joni> let's presume /usr/local/bin/emc.run
[08:17:15] <jmkasunich> OK, but it doesn't matter as long as it is in my $PATH
[08:17:21] <alex_joni> and /usr/local/etc/emc.ini & foo.hal
[08:17:30] <alex_joni> yup
[08:17:55] <alex_joni> same /usr/local/etc/emc.conf, hal.conf, rtapi.conf
[08:18:06] <jmkasunich> on the other hand, if I say "cvstree/emc.run", I want it to use cvstree/configs/emc.ini and cvstree/configs/foo.hal
[08:18:09] <alex_joni> maybe /etc/... (but that's a minor problem right now)
[08:18:25] <alex_joni> ok... so we agree that both emc.run are different
[08:18:40] <jmkasunich> but how different do they need to be?
[08:18:54] <alex_joni> and when installing emc.run will be parsed and changed from relative to absolute paths
[08:18:54] <jmkasunich> IMO, directory.map and install.map should look pretty similar
[08:19:06] <alex_joni> should.. but can they?
[08:19:23] <alex_joni> bc if they are 100% similar... nothing needs to be done
[08:19:36] <jmkasunich> suppose we changed the directory.map configs directory to etc
[08:19:39] <jmkasunich> and so on...
[08:20:02] <jmkasunich> such that the emc.run would mostly use lines like $PREFIX/etc/emc.ini
[08:20:26] <jmkasunich> where $PREFIX is either "/usr/local/", or "cvstree/"
[08:20:46] <jmkasunich> actually, I think "/usr/local/emc" would be better
[08:21:28] <alex_joni> me too
[08:21:38] <alex_joni> $PREFIX = /usr/local/emc
[08:21:46] <alex_joni> or $PREFIx=.
[08:22:01] <alex_joni> or $PREFIX=cvstree/
[08:22:09] <alex_joni> but...
[08:22:15] <jmkasunich> yeah - and give the installer the option to specify a different prefix, for example if they want to install to /opt/emc instead of /usr/local/emc
[08:22:29] <alex_joni> that's done already
[08:22:31] <alex_joni> but...
[08:22:39] <alex_joni> some things go into different folders
[08:22:45] <alex_joni> e.g. the realtime script
[08:22:54] <alex_joni> into /etc/init.d/
[08:22:59] <alex_joni> man stuff
[08:23:22] <alex_joni> rtapi.conf - could go to /etc/
[08:23:36] <alex_joni> bc it's not emc-tied
[08:24:40] <jmkasunich> so we basically have two kinds of files: those whose locations are the same whether it is $COMPILE_DIR/foo, or $INSTALL_DIR/foo, and those that aren't the same
[08:25:11] <alex_joni> yup
[08:25:24] <jmkasunich> first goal, make as many as possible the same
[08:25:38] <jmkasunich> even if that means re-arranging directory.map to look more like install.map
[08:26:24] <alex_joni> I see..
[08:26:34] <alex_joni> well let's take them one by one...
[08:26:51] <alex_joni> I'm looking at the installed stuff
[08:27:03] <jmkasunich> * jmkasunich opens both map files in an editor
[08:27:14] <alex_joni> I have /etc/init.d/realtime
[08:27:34] <alex_joni> actually /etc/rc.d/init.d/realtime (that's the proper way)
[08:28:15] <alex_joni> and /lib/modules/kernelver/rtai/*.o (would like to see an aditional /emc/ )
[08:28:24] <alex_joni> or emc2
[08:28:38] <jmkasunich> that's the realtime modules?
[08:28:43] <alex_joni> yes
[08:29:02] <alex_joni> blocks, debounce, encoder, etc.
[08:29:10] <alex_joni> hal_lib, etc
[08:29:35] <jmkasunich> question: why can't the modules be under /usr/local/emc2/rtmods or something like that (ie. in the same tree as the rest of the installed files, rather than in the kernel module tree)
[08:29:51] <alex_joni> no idea
[08:30:03] <jmkasunich> paul? any thoughts on that?
[08:30:17] <alex_joni> in install.map it's under /usr/realtime/modules
[08:30:29] <jmkasunich> putting them in the kernel modules tree makes it possible for insmod to find themn
[08:30:30] <alex_joni> but I think in /usr/local you have user stuff
[08:30:47] <jmkasunich> so you can do "insmod parport" instead of "insmod <path>/parport.o"
[08:31:02] <alex_joni> yup.. but that doesn't help a lot...
[08:31:21] <jmkasunich> if halcmd is gonna do the loading, it will tell insmod exactly where to look
[08:31:33] <alex_joni> * alex_joni thinking about emc.run...
[08:32:24] <jmkasunich> note that rtapi.o and hal_lib.o probably should be in the kernel modules path, but the others (parport, encoder, etc) should not
[08:32:29] <alex_joni> hmmm.. modules in /lib/modules/ is very explicite
[08:32:43] <alex_joni> misspelled that one...
[08:32:55] <alex_joni> the user knows what to expect from files there
[08:33:41] <jmkasunich> lib/modules is for kernel modules - aka modules that are actually part of the OS or drivers or other _system_ related things
[08:34:06] <jmkasunich> our modules are kernel modules in name only - they are actually specific to emc2/hal and of no use to the general system
[08:34:54] <jmkasunich> I hope paul_c is listening to this and will comment if I start going somewhere strange
[08:35:32] <paul_c> If it is kernel space, then it goes in /lib/modules/{KVER}/foo
[08:37:23] <jmkasunich> ok
[08:37:43] <jmkasunich> what about /lib/modules/{KVER}/emc/foo?
[08:37:57] <alex_joni> so /lib/modules/{KVER}/rtai/emc?
[08:37:57] <jmkasunich> so our modules don't clutter up the system modules directory
[08:38:13] <alex_joni> or /lib/modules/{KVER}/emc/ ?
[08:38:40] <paul_c> it matters not how far up the tree a module is buried as long as it is somewhere in the /lib/modules/{KVER} tree
[08:38:57] <jmkasunich> I think KVER may be something like linux-2.4.18-rtai, so the "rtai" part can be skipped
[08:39:14] <paul_c> KVER=`uname -r`
[08:39:28] <jmkasunich> ok
[08:40:38] <alex_joni> jmk: you locked me out :D
[08:40:43] <jmkasunich> ?
[08:40:55] <CIA-3> 03alex_joni 07auto_configure_0_1 * 10emc2/ (scripts/emc.run configs/hal.conf.in Makefile): a temporary hack in order for halcmd to find modules to load when loadrt. Things should be straightened out...
[08:41:08] <alex_joni> cvs commit: waiting for jmkasunich's lock in /cvsroot/emc/emc2
[08:41:19] <jmkasunich> that's strange
[08:41:26] <jmkasunich> I don't have a commit in progress...
[08:41:31] <alex_joni> hmmm...
[08:41:35] <alex_joni> maybe a checkout?
[08:41:37] <jmkasunich> (unless maybe the compile farm was doing a checkout>
[08:41:57] <alex_joni> and in the middle of a checkout no other can commit.. so the first co is not corrupted
[08:42:05] <alex_joni> I think it was the farm
[08:42:37] <jmkasunich> yep - slot 3 did a checkout 2 mins ago
[08:42:48] <jmkasunich> * jmkasunich manually kicks off all three slots since you just committed
[08:43:01] <alex_joni> shouldn't bother the make process
[08:43:09] <alex_joni> all I did affects just run-time
[08:43:58] <jmkasunich> oh well
[08:44:22] <jmkasunich> the lockout didn't make your commit fail did it? just a delay?
[08:45:06] <alex_joni> just a delay
[08:45:20] <alex_joni> cvs had to wait for your co to be over
[08:45:30] <alex_joni> and after that the commit succeeded
[08:45:37] <alex_joni> pretty nifty ;)
[08:46:25] <jmkasunich> ok, where were we
[08:46:47] <alex_joni> diffs between install-dir and make-dir
[08:46:55] <alex_joni> directory.map and install.map
[08:47:22] <alex_joni> how about $BIN-PREFIX $RTMOD-PREFIX $MAN-PREFIX ?
[08:47:50] <jmkasunich> as inputs to "make install"?
[08:48:03] <alex_joni> yup
[08:48:17] <jmkasunich> sounds reasonable
[08:48:27] <alex_joni> but.. make install uses standard values for those
[08:48:37] <alex_joni> so simply make install just installs
[08:48:52] <jmkasunich> the defaults should be the
[08:48:54] <jmkasunich> oops
[08:49:15] <jmkasunich> the "standard" locations - the prefixes would only be speficied if the user wanted to do something special
[08:49:33] <alex_joni> yes
[08:49:42] <alex_joni> and normally they are void (after make)
[08:49:51] <alex_joni> so run-in-place is possible
[08:50:05] <jmkasunich> need at least one more: $EMC_PREFIX, for the files that are in the same place in install.map and directory.map
[08:50:07] <alex_joni> maybe 2 levels are needed
[08:50:35] <alex_joni> $PREFIX/$BIN-PREFIX or smthg like that
[08:50:47] <alex_joni> not a good choice for an example
[08:53:18] <alex_joni> right now:
[08:53:43] <alex_joni> ./configure --prefix=/opt would overwrite the standard /usr/local
[08:53:53] <alex_joni> so $prefix 0 /usr/local
[08:53:59] <alex_joni> s/0/=/
[08:54:59] <jmkasunich> I would think ./configure (or make install) would have something like:
[08:55:52] <jmkasunich> if [ ! -n $PREFIX ] ; then $PREFIX=/usr/local ; fi
[08:56:06] <jmkasunich> duh
[08:56:32] <jmkasunich> if [ -z $PREFIX ] ; then PREFIX=/usr/local ; fi
[08:56:53] <alex_joni> actually there is a :
[08:57:03] <alex_joni> AC_PREFIX_DEFAULT(/usr/local)
[08:57:07] <alex_joni> in configure.in
[08:57:32] <alex_joni> which (when autoconf is run) creates ./configure that contains some code for prefix checking
[08:57:48] <alex_joni> if no other prefix is specified $prefix=/usr/local
[08:57:48] <jmkasunich> ok, that's even better
[08:58:05] <alex_joni> you can adjust a lot of dirs this way
[08:58:06] <jmkasunich> can you use that for arbitrary variables
[08:58:22] <alex_joni> not like that
[08:58:23] <jmkasunich> like AX_FOO_PREFIC_DEFAULT(/somewhere)
[08:58:33] <alex_joni> AC_PREFIX_DEFAULT is only for $prefix
[08:58:34] <jmkasunich> s/AX/AC/
[08:58:57] <jmkasunich> bummer
[08:59:01] <alex_joni> but
[08:59:18] <jmkasunich> cause we're gonna want BIN_PREFIX, RTMOD_PREFIX, and maybe others
[08:59:28] <alex_joni> you have bindir, sbindir, libexecdir, datadir, sysconfdir, sharedstatedir,
[08:59:41] <alex_joni> localstatedir, libdir, infodir, mandir
[09:00:10] <alex_joni> take a look at Makefile.inc.in
[09:00:15] <alex_joni> and at Makefile.inc
[09:01:38] <jmkasunich> sysconfdir is normally /etc, right?
[09:01:49] <alex_joni> nope
[09:01:59] <alex_joni> these all are dirs that can be used by the app
[09:02:20] <alex_joni> defined as $prefix/something
[09:02:39] <alex_joni> sysconfdir=${prefix}/etc
[09:03:15] <alex_joni> hmmm.. maybe that /etc you asked about was relative not absolute? (then yes)
[09:03:40] <jmkasunich> if $PREFIX is /usr/local/emc (or /opt/emc) then "sysconfdir" is really "emcconfdir" isn't it?
[09:04:00] <alex_joni> it's /usr/local/emc/etc
[09:04:01] <jmkasunich> I thought sysconf meant system wide config stuff, hence /etc
[09:04:13] <jmkasunich> ok, just a confusing name
[09:04:39] <alex_joni> well... that's the way the autoguys did it ;)
[09:05:25] <jmkasunich> ok
[09:06:31] <jmkasunich> binaries that need to be in the users path should go in $BIN_PREFIX, which by default will be "/usr/local/bin" (note no emc), while most other stuff (ini files, etc) will go in $PREFIX which will default to "/usr/local/emc"
[09:06:36] <jmkasunich> does that sound right?
[09:06:50] <alex_joni> hmm.. I'm dizzy
[09:07:05] <alex_joni> there is a BIN_DIR
[09:07:14] <alex_joni> and a bindir
[09:07:22] <alex_joni> and now a $BIN_PREFIX
[09:07:42] <jmkasunich> maybe I'm confused
[09:07:50] <alex_joni> no....
[09:07:52] <jmkasunich> should it be $BIN_DIR, not $BIN_PREFIX?
[09:08:03] <alex_joni> it's just way too cluttered right now
[09:08:10] <alex_joni> we need to make it simpler
[09:08:37] <alex_joni> oh.. I forgot there's $(DESTDIR)$(TESTDIR)/$(bindir)
[09:08:43] <alex_joni> lol
[09:10:13] <alex_joni> if you take a look at Makefile.inc
[09:10:21] <alex_joni> there are all things twice...
[09:10:33] <alex_joni> we need to loose half of those
[09:10:41] <alex_joni> it's confusing right now
[09:10:53] <alex_joni> the CAPS ones are used when compiling
[09:11:06] <alex_joni> and the other when installing
[09:13:42] <alex_joni> let's rewind...
[09:13:56] <alex_joni> we have bin's...
[09:14:23] <alex_joni> that go to $(prefix)/bin or $(EMC2_HOME)/bin
[09:14:46] <jmkasunich> EMC2_HOME is the cvs directory?
[09:14:54] <alex_joni> yes
[09:15:08] <alex_joni> but... problem here are the tcl files
[09:15:22] <jmkasunich> the problem is?
[09:15:27] <alex_joni> they used to go to $(EMC2_HOME)/tcl
[09:15:53] <alex_joni> on install they go to $(prefix)/bin
[09:16:12] <alex_joni> a). $(prefix)/tcl
[09:16:15] <alex_joni> or
[09:16:24] <alex_joni> b). $(EMC2_HOME)/bin
[09:16:36] <alex_joni> so we have one case
[09:16:48] <jmkasunich> question: do they need to be in the user's $PATH?
[09:17:16] <alex_joni> answer: no idea :-)
[09:17:25] <jmkasunich> cause that is a dividing line
[09:17:44] <alex_joni> * alex_joni is looking at the tcl files
[09:17:55] <jmkasunich> things that need to be in the path (once installed) go in $BIN_DIR/ (default /usr/local/bin)
[09:18:17] <jmkasunich> things that don't need to be in the path go in $prefix/bin or $prefix/tcl
[09:18:28] <alex_joni> there is tkemc.tcl
[09:18:51] <jmkasunich> but the user never (that I'm aware of) invokes tkemc from the command line
[09:19:04] <alex_joni> .....
[09:19:13] <jmkasunich> hence it doesn't need to be in the path - emc.run invokes it, and emc.run should know where to look
[09:19:45] <alex_joni> ok... so tcl goes to $(prefix)/tcl ?
[09:19:59] <jmkasunich> I'm inclined to think so
[09:20:14] <alex_joni> there is a EMC2_TCL_DIR in emc.run that can be changed
[09:20:53] <alex_joni> actually that comes from emc.conf
[09:21:26] <alex_joni> so...
[09:21:35] <jmkasunich> let's try this: look at directory.map, and determine which catagory (below) each directory fall into
[09:21:38] <jmkasunich> catagories:
[09:21:46] <alex_joni> emc.run reads the values from emc.conf, hal.conf, rtapi.conf
[09:21:55] <alex_joni> * alex_joni holds
[09:21:56] <jmkasunich> 1) same place in directory.map and install.map (only prefix changes)
[09:22:05] <paul_c> * paul_c will have to leave you guys to it...
[09:22:12] <jmkasunich> 2) don't need it at all in install.man (source stuff)
[09:22:12] <alex_joni> ok paul...
[09:22:20] <paul_c> goodnight.
[09:22:22] <jmkasunich> 3) some other place in install.map
[09:22:24] <alex_joni> night
[09:22:25] <jmkasunich> goodnight paul
[09:22:55] <alex_joni> yes
[09:22:57] <alex_joni> ok...
[09:23:01] <alex_joni> so for 1).
[09:23:16] <alex_joni> bin stuff
[09:23:19] <alex_joni> tcl stuff
[09:23:42] <jmkasunich> nc_files (should we install the sample part programs?)
[09:23:46] <alex_joni> etc stuff (was known as configs)
[09:23:50] <jmkasunich> yes
[09:23:58] <alex_joni> lib stuff
[09:24:00] <alex_joni> man stuff
[09:24:17] <jmkasunich> don't man pages go in the system man dir tree (catagory 3)
[09:25:02] <alex_joni> could go
[09:25:08] <alex_joni> * alex_joni tries smthg
[09:25:46] <alex_joni> if it's in /usr/local/man/ it works too
[09:25:56] <jmkasunich> that's what I was thinking
[09:26:08] <jmkasunich> $MAN_DIR, with the default being /usr/local/man
[09:26:23] <alex_joni> standard on my machine the man files are in /usr/share/man
[09:26:52] <alex_joni> but... never mind that ;)
[09:27:13] <jmkasunich> ./configure could do "man -w
[09:27:14] <alex_joni> if $(prefix) is /usr/local, then man is in category 1
[09:27:21] <alex_joni> configure does that
[09:27:28] <jmkasunich> ok
[09:27:50] <jmkasunich> I thought prefix was /usr/local/emc?
[09:28:09] <jmkasunich> * jmkasunich is getting confused again
[09:28:13] <alex_joni> it was a if there
[09:28:33] <alex_joni> if $(prefix) is /usr/local/emc then man is in category 3
[09:28:46] <jmkasunich> * jmkasunich looks
[09:29:05] <alex_joni> right now $(prefix) is /usr/local
[09:29:10] <alex_joni> but that can be changed
[09:29:20] <alex_joni> if it makes things clearer/simpler
[09:29:27] <jmkasunich> I thought we had decided on /usr/local/emc
[09:29:41] <alex_joni> we can...
[09:30:07] <alex_joni> ok.. define $(prefix)=/usr/local/emc
[09:30:17] <jmkasunich> I think it's really important that as much emc stuff as possible be under a <foo>/emc/<stuff> thing
[09:30:30] <alex_joni> how about bin stuff?
[09:30:37] <alex_joni> that's not in path anymore...
[09:30:47] <jmkasunich> if not in $PATH, then /usr/local/emc/bin
[09:30:53] <jmkasunich> if in path, then /usr/local/bin
[09:31:16] <jmkasunich> keep the number of files that need to be in PATH to a minimum
[09:31:26] <alex_joni> emc.run should be
[09:31:30] <jmkasunich> right
[09:31:33] <jmkasunich> and probably halcmd
[09:31:38] <alex_joni> nope
[09:31:50] <alex_joni> we can move all to /usr/local/emc/bin
[09:31:58] <alex_joni> sorry...
[09:32:03] <alex_joni> halcmd could be
[09:32:21] <alex_joni> if we want the user to be able to use the system without emc, only with halcmd
[09:32:32] <alex_joni> how about a symlink?
[09:32:44] <jmkasunich> or if he's gonna use halcmd from the command line for tweaking thingds
[09:32:52] <alex_joni> yes...
[09:33:01] <jmkasunich> symlink sounds like an _excellent_ idea - for both emc.run and halcmd
[09:33:17] <alex_joni> files in $(prefix)/bin
[09:33:20] <jmkasunich> ALL binaries in /usr/local/emc/run, and symlink those that need to be in path
[09:33:24] <alex_joni> and symlinks in $PATH
[09:33:32] <jmkasunich> s/run/bin
[09:33:34] <alex_joni> s/run/bin/ I hope
[09:33:36] <alex_joni> :P
[09:33:48] <alex_joni> ok
[09:33:52] <alex_joni> moving on
[09:34:17] <alex_joni> how about man stuff?
[09:34:33] <alex_joni> if there's only halcmd.1
[09:34:46] <jmkasunich> there will be more, I hope
[09:34:55] <jmkasunich> $MAN_DIR/man.n/filename
[09:34:59] <alex_joni> okay... leaving man stuff in 3)
[09:35:17] <alex_joni> run-in-place ... stays man in docs ?
[09:35:22] <jmkasunich> where $MAN_DIR is either /usr/local/man, or is discovered by ./configure
[09:35:23] <jmkasunich> yes
[09:35:29] <alex_joni> ok
[09:35:49] <jmkasunich> install will just copy docs/man/* to $MAN_DIR/*
[09:36:00] <alex_joni> ok
[09:36:24] <alex_joni> that sorts out $(prefix) stuff
[09:36:31] <alex_joni> now... modules
[09:36:55] <alex_joni> paul said those should go to /lib/modules/KVER/emc/
[09:37:12] <alex_joni> right?
[09:37:16] <jmkasunich> yes
[09:37:23] <jmkasunich> so they're catagory 3
[09:37:36] <alex_joni> yup
[09:37:42] <alex_joni> normaly in rtlib/*
[09:37:50] <jmkasunich> I'd prefer KVER/hal instead of KVER/emc, but not gonna fight that battle today
[09:37:58] <alex_joni> hal is ok
[09:38:22] <alex_joni> I said emc, just in order not to put them in /lib/modules/kver/rtai
[09:38:31] <alex_joni> the way it's done now
[09:38:40] <alex_joni> (zwisk did it I think...)
[09:38:45] <jmkasunich> let's do hal, if Paul objects we can discuss it
[09:38:49] <alex_joni> ok
[09:38:59] <jmkasunich> * jmkasunich edits madly in install.map
[09:39:01] <alex_joni> but I think that would be more a board decision
[09:39:19] <alex_joni> * alex_joni is eager to see install.map
[09:39:45] <jmkasunich> I will commit when we finish this discussion - want me to email what I have now?
[09:40:05] <alex_joni> neah... I think I can still remember what we have discussed
[09:40:12] <alex_joni> although... it's pretty late ;)
[09:40:18] <alex_joni> 1:32 am here
[09:40:36] <alex_joni> we need to rename configs to etc
[09:40:41] <alex_joni> any idea how?
[09:40:49] <jmkasunich> you want to wind down? I can finish editing, commit, and resume tomorrow
[09:40:56] <alex_joni> no no no
[09:40:58] <jmkasunich> under the cvs tree?
[09:41:02] <alex_joni> yup
[09:41:23] <jmkasunich> it's easy since no files are actually committed in that dir (I think)
[09:41:28] <alex_joni> * alex_joni is sleepy, but still he sees that this is going the right direction... pitty to stop
[09:41:44] <alex_joni> in configs? I think there are some files commited there...
[09:42:01] <alex_joni> * alex_joni thinks of emc.ini for example
[09:42:10] <jmkasunich> oops, I was thinking of another directory
[09:42:31] <alex_joni> * alex_joni opens the red-bean book
[09:42:48] <jmkasunich> I think renaming a directory isn't easy
[09:43:24] <jmkasunich> not something to figure out at 1:30am - that decision can wait - worst case the files continue to live in configs, but get installed to etc
[09:44:21] <alex_joni> yup.. sounds ok
[09:46:58] <alex_joni> seems https://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_7.html has the answer
[09:47:09] <alex_joni> but better to leave it undone for now...
[09:47:16] <alex_joni> ok... where were we?
[09:47:28] <jmkasunich> editing ;-)
[09:47:34] <alex_joni> right
[09:47:59] <jmkasunich> I have docs, nc_files, etc, lib and bin under $PREFIX
[09:48:04] <alex_joni> prefix
[09:48:17] <jmkasunich> oik
[09:48:17] <alex_joni> and tcl
[09:48:17] <jmkasunich> ok
[09:48:46] <jmkasunich> done
[09:48:56] <jmkasunich> now rt modules
[09:49:10] <jmkasunich> cvstree/rtlib is the cvs location
[09:49:18] <alex_joni> yup... RTLIB
[09:49:36] <jmkasunich> RTMOD_DIR?
[09:49:50] <alex_joni> and /lib/modules/KVER/hal/ the install location
[09:49:51] <jmkasunich> default being /lib/modules/KVER/hal/?
[09:50:44] <alex_joni> there is a moduledir already
[09:50:58] <jmkasunich> huh?
[09:51:12] <alex_joni> figured out by ./configure
[09:51:34] <jmkasunich> that's where all the kernel modules actually are?
[09:51:40] <alex_joni> no
[09:51:50] <alex_joni> that's where hal modules should go
[09:52:21] <jmkasunich> * jmkasunich is getting confused - I thought we just decided that they should go in /lib/modules/KVER/hal ?
[09:52:31] <alex_joni> yes
[09:52:43] <alex_joni> but.. I'm talking about the situation right now
[09:53:08] <jmkasunich> oh
[09:53:12] <alex_joni> ./configure searches for rtai or rtlinux modules
[09:53:16] <alex_joni> and finds the moduledir
[09:53:38] <alex_joni> which can / should be used as a target to where the modules should go (when installing)
[09:53:41] <jmkasunich> hmm - that's a different set of modules (but we need to know where they are too)
[09:53:48] <jmkasunich> * jmkasunich disagrees
[09:53:59] <jmkasunich> those modules belong to the RTOS
[09:54:05] <alex_joni> I don't mean that hal modules should go to rtai dir
[09:54:12] <jmkasunich> the "realtime" script needs to know where they are
[09:54:18] <alex_joni> but... (and this was paul's point)
[09:54:18] <jmkasunich> but the hal modules should go elsewhere
[09:54:35] <alex_joni> when we are compiling for a different kernel
[09:54:47] <alex_joni> let's say compiling from a unpatched kernel
[09:55:13] <alex_joni> we need to find the kernel that has been patched (that already has the rtos-modules)
[09:55:27] <jmkasunich> I think I understand
[09:55:29] <alex_joni> and install our modules to the same location (../hal)
[09:55:43] <alex_joni> not `uname -r` blindly
[09:56:00] <alex_joni> and ./configure already does that
[09:56:11] <jmkasunich> the default for $RTMOD_DIR should not be /lib/modules/KVER/hal, it should be $moduledir/hal
[09:56:15] <jmkasunich> right?
[09:56:16] <alex_joni> and provides a --with-module-dir=<path to modules install)
[09:56:30] <alex_joni> almost
[09:56:45] <alex_joni> $moduledir=$rtaimoduledir/../hal
[09:57:05] <alex_joni> $RTMOD_DIR=$moduledir
[09:57:45] <jmkasunich> the first line could as well be $rtlinuxmoduledir, or whatever
[09:57:45] <alex_joni> * alex_joni is not sure he makes himself clear...
[09:57:51] <alex_joni> yes!
[09:58:04] <jmkasunich> I think moduledir should be the RTOS dir, _without_ /hal
[09:58:05] <alex_joni> e.g. halmoduledir
[09:58:29] <alex_joni> well... the RTOS dir is /lib/modules/kver/rtai
[09:58:44] <alex_joni> do we want to install into /lib/modules/kver/rtai/hal ?
[09:59:12] <jmkasunich> oh, I missunderstood the .. in $rtaimoduledir/../hal
[09:59:32] <alex_joni> I think kver/hal is better
[09:59:34] <jmkasunich> didn't realize you were backing up one level
[09:59:37] <jmkasunich> yes
[09:59:47] <alex_joni> although rtai/hal makes it more clear... (harder to find though)
[10:00:02] <jmkasunich> still think moduledir should be $rtaimoduledir/..
[10:00:10] <alex_joni> I'll change moduledir to halmoduledir
[10:00:18] <alex_joni> then it's clear
[10:00:47] <jmkasunich> in any case, there is not really a "default", instead ./configure will set it
[10:00:49] <jmkasunich> right?
[10:01:02] <alex_joni> there is a default inside ./configure
[10:01:16] <jmkasunich> BTW, we need to decide about upper/lower case
[10:01:38] <jmkasunich> if these are env variables, I prefer uppercase
[10:01:40] <alex_joni> yes...
[10:01:54] <jmkasunich> but if the autoconf folks have already established a standard, then we should follow that
[10:01:57] <alex_joni> lower case is used for prefixes and stuff, that get changed by make install
[10:02:02] <jmkasunich> right now i have a mixture
[10:02:19] <alex_joni> well that's the way it should be...
[10:02:35] <alex_joni> everything lowercase gets replaced by install
[10:02:37] <jmkasunich> ok, I'm editing install.map, which shows things as they are installed
[10:02:45] <jmkasunich> so I'm gonna use uppercast
[10:03:21] <jmkasunich> by the way, these variables are probalby the ones that wind up in rtapi.conf, hal.conf, and emc.conf
[10:03:38] <alex_joni> yes
[10:04:10] <jmkasunich> so in install.map, I have $BIN_DIR (default /usr/local/bin)
[10:04:20] <jmkasunich> $MAN_DIR (/usr/local/man)
[10:04:47] <jmkasunich> $prefix (/usr/local/emc) -- I think that should change to $EMC2_DIR in install.map
[10:05:25] <jmkasunich> and $RTMOD_DIR (default rtosmoduledir/../hal)
[10:05:32] <jmkasunich> does that make sense?
[10:05:59] <alex_joni> I think you meant $EMC2_DIR in directory.map
[10:06:05] <alex_joni> right?
[10:06:28] <jmkasunich> well I was talking about install.map... perhaps it should be $PREFIX?
[10:06:40] <jmkasunich> all the others are *_DIR though
[10:06:57] <alex_joni> hold your horses for a minute;)
[10:07:00] <alex_joni> so...
[10:07:06] <alex_joni> when ./configure is done
[10:07:31] <alex_joni> Makefile.inc (and a lot of other files) contain $(prefix)
[10:08:06] <alex_joni> after a make install $(prefix) gets changed with /usr/local
[10:08:15] <alex_joni> after a make install $(prefix) gets changed with /usr/local/emc
[10:08:21] <alex_joni> sorry bout the first one
[10:08:33] <jmkasunich> or whatever the user specified - might be /opt or whatever
[10:08:38] <alex_joni> yes
[10:08:45] <alex_joni> so there is no $PREFIX
[10:09:03] <alex_joni> in the installed files we have /usr/local/emc all over the place
[10:09:15] <alex_joni> or whatever
[10:09:23] <jmkasunich> will the user specify /opt or whatever at ./configure time, or at make install time?
[10:09:36] <alex_joni> ./configure time
[10:09:53] <alex_joni> it gets then written to Makefile.inc
[10:09:57] <jmkasunich> in the installed files, we should have $PREFIX (or whatever - a shell variable)
[10:10:09] <alex_joni> from there included for compiling, and for installing
[10:10:13] <jmkasunich> sorry, that's wrong
[10:10:21] <alex_joni> what is?
[10:10:31] <jmkasunich> what I started to say about PREFIX
[10:10:45] <jmkasunich> I was mixed up - I think I'm starting to get it
[10:11:04] <alex_joni> when we install.. we would need to parse all the scripts and configs to absolute directories
[10:11:15] <alex_joni> so there is no confusion
[10:11:20] <jmkasunich> the installed files (scripts, etc) will have NO variable substitution, they will all have absolute directories?
[10:11:21] <alex_joni> right?
[10:11:27] <alex_joni> yes
[10:11:34] <alex_joni> that's how I'd do it
[10:12:09] <jmkasunich> that means if you add _any_ new scripts or anything like that, you need to add to the build system to do the substitution at install time
[10:12:14] <alex_joni> the only thing that can't be changed are the already compiled files (those have to rely on configs)
[10:12:27] <alex_joni> yes... but that's easy
[10:12:38] <alex_joni> if you look at how zwisk has done it...
[10:12:42] <alex_joni> in Makefile
[10:12:45] <jmkasunich> relatively easy, for somebody how is aware of the need
[10:12:59] <alex_joni> he has a list of scriptfiles
[10:13:06] <jmkasunich> but suppose some new developer wants to add a simple script to do something
[10:13:24] <jmkasunich> he copies an existing script, uses the same conventions, veriables, etc,
[10:13:35] <alex_joni> and if you add your script there (you need to add it there in order to get it installed) then it gets changed automatically
[10:13:39] <jmkasunich> but unless he adds it to the list of scriptfiles, it won't work
[10:13:54] <jmkasunich> good point - must be added to install it anyway
[10:14:00] <alex_joni> it should work from run-in-place
[10:14:22] <alex_joni> still need to figure out how to do that
[10:14:47] <jmkasunich> now I understand why he needed the make test target and the dummy install directory
[10:14:56] <alex_joni> it's easier ;)
[10:15:10] <jmkasunich> he _never_ actually runs the original scripts, only the "installed" ones that have been edited?
[10:15:16] <alex_joni> exactly
[10:15:21] <jmkasunich> ewwwww
[10:15:39] <alex_joni> well....
[10:15:53] <alex_joni> it is something... (better than nothing ;))
[10:15:59] <jmkasunich> I know
[10:16:05] <jmkasunich> * jmkasunich tries to think of a better way
[10:16:07] <alex_joni> thing is...
[10:16:18] <jmkasunich> I'd like it if the scripts always (installed or not) used variables
[10:16:43] <alex_joni> so the scripts don't get affected?
[10:16:57] <jmkasunich> right - no changes when installing them, just copy
[10:17:06] <jmkasunich> but now the variables need to get set somehow
[10:17:17] <jmkasunich> that's where rtapi.conf and friends would be used
[10:17:28] <alex_joni> yup.. but first problem
[10:17:37] <alex_joni> how do you find friends.conf ?
[10:17:57] <jmkasunich> welllll, I'm thinking about that
[10:18:04] <jmkasunich> no good answer yet ;-)
[10:18:24] <jmkasunich> if installed, you want /etc/foo.conf
[10:18:35] <jmkasunich> if not, you want cvsdir/foo.conf
[10:19:05] <alex_joni> which one do you check first?
[10:19:20] <alex_joni> I'd go with ./etc/foo.conf
[10:19:30] <jmkasunich> I must admit, having install modify the scripts is a good way of dealing with the problem
[10:19:32] <alex_joni> then /usr/local/emc/etc/foo.conf
[10:19:49] <jmkasunich> but both of those are installed locations
[10:20:02] <jmkasunich> if you're running an uninstalled version, those are the wrong place
[10:20:16] <jmkasunich> I'm begginning to change my mind about modifying the scripts
[10:20:44] <alex_joni> ;)
[10:20:52] <alex_joni> I know why...
[10:21:04] <jmkasunich> If the unmodified scripts run in place correctly, then I think modifying them for install is great
[10:21:14] <alex_joni> yup...
[10:21:25] <alex_joni> in order to do that.. we could make something like
[10:21:37] <alex_joni> ${prefix}=/usr/local/emc
[10:21:40] <jmkasunich> but if they need modified to run in place, then working on a script is annoying.... edit, make test, run, instead of just edit run
[10:22:11] <alex_joni> $SCRIPT_DIR/bin
[10:22:25] <alex_joni> maybe SCRIPT_DIR is not ok (just an example)
[10:22:40] <alex_joni> and SCRIPT_DIR defaults to $EMC2_HOME
[10:22:54] <alex_joni> but when installing it gets replaced with ${prefix}
[10:23:16] <alex_joni> what do you think?
[10:23:27] <jmkasunich> my brain hurts
[10:23:37] <alex_joni> mine too ;)
[10:23:50] <alex_joni> but less.. because it's half asleep
[10:24:18] <jmkasunich> one approach that we know will work, but is inconvenient, is the make test approach
[10:24:43] <jmkasunich> that treats the CVS version of the script as "source code", in fact it isn't runnable until make test modifies it, right?
[10:24:44] <alex_joni> yup... it's very inconvenient
[10:24:51] <alex_joni> right
[10:25:08] <jmkasunich> the trick is to make the "source code" runable
[10:25:18] <alex_joni> I modified hal.conf, and I needed 5 mins. to convince make run to install it again
[10:25:21] <alex_joni> :(
[10:26:09] <alex_joni> here's a thought...
[10:26:30] <alex_joni> what if all the things that get changed are in emc.conf and friends
[10:26:45] <alex_joni> the only thing in emc.run that needs changing is the path to emc.conf
[10:27:15] <alex_joni> and that can be skipped (check local dirs e.g. ./etc/)
[10:27:41] <alex_joni> maybe check from where emc.run was started
[10:29:11] <jmkasunich> see lines 18-28 of realtime
[10:29:32] <alex_joni> that's EXACTLY what I was looking at right now
[10:30:15] <jmkasunich> but it should be reversed, so it checks for a local .conf file before it checks /etc
[10:30:24] <alex_joni> yup
[10:30:31] <jmkasunich> that way run-in-place will find a local conf pointing to local stuff
[10:31:06] <alex_joni> only thing... not to run emc.run(from PATH) from within the cvs-dir
[10:31:28] <alex_joni> usually you run in EMC2_HOME scripts/emc.run
[10:31:37] <jmkasunich> * jmkasunich tries a test
[10:31:40] <alex_joni> but if you run emc.run then you got problems
[10:35:14] <alex_joni> * alex_joni was reading through FEST notes...
[10:35:23] <alex_joni> http://linuxcnc.org/spring_EMC_meeting_info.html contains some mail addys
[10:35:33] <alex_joni> those should be removed...
[10:36:33] <jmkasunich> noted
[10:37:03] <jmkasunich> finally finished my test
[10:37:23] <alex_joni> what test?
[10:37:25] <jmkasunich> I think it works, even when you do "emc.run" from within the cvs dir
[10:37:59] <jmkasunich> if the one in the path is called, $0 is not "emc.run", it is "/usr/local/bin/emc.run"
[10:38:00] <alex_joni> well... it should run with the cvs stuff... right?
[10:38:14] <alex_joni> I see...
[10:38:14] <jmkasunich> if you do ./emc.run, it will run the local one
[10:38:22] <jmkasunich> if you do emc.run, it will run the installed one
[10:38:27] <alex_joni> nice
[10:38:37] <alex_joni> ok... now
[10:38:45] <jmkasunich> in either case, $0 correctly identified the one thats running
[10:38:57] <jmkasunich> so it can get the corresponding conf file(s)
[10:39:03] <alex_joni> can you commit the mod's to directory.map, and install.map ?
[10:39:19] <jmkasunich> yes, just a couple more tweaks
[10:39:56] <jmkasunich> BTW, my mods are at the end of the file - I copied the original contents and edited the second copy, so the first is unchanged
[10:40:22] <alex_joni> on what branch are you working? autoconf I presume...
[10:40:27] <jmkasunich> yes
[10:40:30] <alex_joni> ok
[10:45:17] <jmkasunich> is bindir the autoconf name for the directory where the bins are?
[10:45:27] <jmkasunich>
[10:45:30] <jmkasunich> /usr/local/bin?
[10:45:52] <jmkasunich> or is that autoconf's name for the /usr/local/emc/bin?
[10:46:52] <alex_joni> http://www.gnu.org/software/ac-archive/htmldoc/stdrelpaths.html
[10:47:05] <alex_joni> worse ;) it's GNU's standard
[10:49:26] <jmkasunich> ok, my head is spinning... I'm gonna just commit what I have, I know some of it is wrong, please fix if you can
[10:50:46] <alex_joni> I'll try...
[10:58:29] <CIA-3> 03jmkasunich 07auto_configure_0_1 * 10emc2/ (directory.map install.map): added a new proposal for file locations - committed for discussion purposes
[11:00:45] <alex_joni> I don't really like the way GNU's done it
[11:02:36] <jmkasunich> I have to leave - it's way past dinner time here
[11:02:46] <jmkasunich> (and my wife is getting restless)
[11:02:50] <alex_joni> well.. I'll go to bed...
[11:03:06] <jmkasunich> OK, talk to you tomorrow
[11:03:14] <alex_joni> yup.. bye
[11:08:26] <alex_joni> * alex_joni is going to sleep...
[11:25:13] <asdfqwega> Les, you there?
[11:26:05] <asdfqwega> Man, there are times being a night-owl stinks.
[11:28:02] <les> I am here
[11:28:47] <les> after a 12+ hour day debugging some commercial robotics
[11:29:00] <les> It's late so I had to work today
[11:29:38] <les> glitches in digital logic, etc
[11:29:54] <les> I am doing golf tommorrow!
[12:02:24] <asdfqwega> Heh...and I check back half an hour later
[12:03:44] <asdfqwega> Well, if Les or Robin sees this: I'm looking for laser focusing lenses for CO2
[12:05:55] <asdfqwega> My setup is crude - I have a 4mm beam width, straight to the lens.
[12:08:05] <asdfqwega> * asdfqwega does NOT feel like grinding his own lenses from NaCl !!!
[12:34:38] <danfalck> * danfalck is back (gone 153:40:20)
[12:35:06] <danfalck> les are you there?
[12:42:57] <danfalck> * danfalck is away: going out to the shop...
[21:08:45] <alex_joni> gmorning
[21:14:39] <paul_c> Morning
[21:15:14] <alex_joni> hello paul
[21:15:28] <alex_joni> we had some major talk last night with jmk ;)
[21:16:06] <alex_joni> I've been up till 4 am trying to figure things out... and I think we were doing it the wrong way all along
[21:17:06] <paul_c> Two rules that one should follow...
[21:17:14] <alex_joni> * alex_joni is talking about make install, autoconf and such
[21:17:16] <paul_c> 1) Keep things simple
[21:17:26] <alex_joni> exactly...
[21:17:36] <paul_c> 2) Reduce the choices to a minimum
[21:18:02] <alex_joni> I think the autoconf generated dirs are not suitable (bindir, libdir, etc.)
[21:18:02] <paul_c> 3) Provide method, not policy.
[21:18:54] <alex_joni> did you get a chance to look at the latest install.map and directory.map submitted by john?
[21:19:09] <paul_c> OK... Let's look at what we have....
[21:19:18] <paul_c> (saw the commit log)
[21:19:34] <paul_c> We have:
[21:19:41] <paul_c> Kernel modules
[21:19:54] <paul_c> User space executables
[21:20:02] <paul_c> Configs
[21:20:15] <paul_c> Sample data files
[21:20:27] <paul_c> and some docs
[21:20:44] <paul_c> These go:
[21:20:46] <alex_joni> and some tcl's
[21:21:00] <alex_joni> don't think we really need to clutter things in bin ...
[21:21:06] <paul_c> Kernel modules: /lib/modules/KVER/yadda
[21:21:16] <alex_joni> Kernel modules: yes
[21:22:14] <paul_c> Binaries and launcher scripts that are to be executed by a user - /usr/bin
[21:22:18] <alex_joni> for that I modified the configure.in (MODULE_DIR outputs /lib/modules/KVER (from search)/hal
[21:22:41] <alex_joni> we discussed it last night, and though about the following scheme... (tell me your opinion)
[21:22:55] <alex_joni> everything emc goes to /usr/local/emc/
[21:23:19] <alex_joni> binaries go to /usr/local/emc/bin (but symlinks for the needed ones go to /usr/local/bin)
[21:23:29] <alex_joni> emc.run and halcmd
[21:23:36] <alex_joni> don't think more are needed
[21:23:45] <paul_c> tcl scripts, samples, etc: /usr/share/emc
[21:24:12] <alex_joni> how about /usr/local/emc/tcl and /usr/local/emc/samples
[21:24:24] <paul_c> Documentation can also go in /usr/share/emc
[21:24:52] <alex_joni> that way someone can decide with going with /opt/emc insteead of /usr/local/emc (and still get the symlinks to /usr/local/bin, and everything should work)
[21:25:25] <paul_c> ${prefix} can be /usr, /usr/local, or /opt
[21:25:53] <paul_c> (in the above, it is assumed ${prefix}=/usr)
[21:26:55] <alex_joni> * alex_joni thinks that it's too scattered...
[21:27:20] <alex_joni> anyways..
[21:27:38] <alex_joni> more important to me right now (than what goes where) is how it goes...
[21:28:19] <alex_joni> and I must say I don't really like the work zwisk has done in this direction (not his fault, it's a great job, but I don't think it's well suited to emc/hal)
[21:28:37] <alex_joni> we still have to treat a lot of dirs differently
[21:28:54] <alex_joni> if we do that, we can do it for all.. and there's no problem
[21:29:18] <alex_joni> (take what's in emccvs/bin and cp it to /usr/local/bin or wherever)
[21:29:43] <alex_joni> same for docs, man, kernel modules etc.
[21:30:33] <paul_c> * paul_c doesn't like either install.map proposals
[21:30:54] <alex_joni> * alex_joni has a thought...
[21:31:07] <alex_joni> how about we make an install.guide
[21:31:20] <alex_joni> which contains the mappings
[21:31:58] <alex_joni> make install reads the file, and gets the rules (e.g. get from `pwd`/bin and copy to ${prefix}/bin)
[21:32:12] <alex_joni> and whenever we need we change only this guide
[21:36:04] <paul_c> Way too many configs - grepping an install.guide adds another one.
[21:36:36] <alex_joni> then just code it into make
[21:36:39] <alex_joni> Makefile
[21:37:13] <paul_c> The configure/makefile is a better place to make the choice
[21:37:27] <alex_joni> yup
[21:37:33] <alex_joni> ./configure get's the prefix
[21:37:45] <alex_joni> and Makefile contains additional stuff
[21:38:42] <alex_joni> anyways... the whole stuff needs to be a lot simpler than it's right now on emc2-autoconf
[21:39:40] <paul_c> Agreed - And not just configure/Makefile
[21:39:58] <alex_joni> * alex_joni thinks to give it a go... and see what comes out (maybe commit in one piece so it can be removed)
[21:40:39] <alex_joni> can you commit an install.map I should follow?
[21:41:06] <alex_joni> or should I follow the one that is now... and what needs to be adjusted will get adjusted later?
[21:41:57] <paul_c> Let's see what we currently have in the emc2 tree...
[21:42:09] <alex_joni> emc2 main tree?
[21:42:21] <paul_c> yes
[21:42:32] <alex_joni> only man get's installed
[21:42:37] <alex_joni> and there's no install.map
[21:42:45] <alex_joni> only directory.map
[21:43:14] <paul_c> rtlib contains kernel modules - We agree on where this goes
[21:43:26] <alex_joni> yup
[21:43:40] <alex_joni> although there are some comments here too
[21:43:49] <paul_c> bin - ${prefix}/bin
[21:43:56] <alex_joni> some say /lib/modules/KVER/hal some say /emc
[21:44:29] <paul_c> * paul_c doesn't care about where in the KVER/ tree they go...
[21:44:38] <alex_joni> me neither ;)
[21:45:14] <paul_c> lib - ${prefix}/lib - For files ending in .so ONLY
[21:46:15] <alex_joni> what .so files?
[21:46:25] <alex_joni> are there any?
[21:46:32] <alex_joni> I only see .o and .a
[21:46:45] <paul_c> docs, nc_files, tcl, etc - ${prefix}/share/emc2/
[21:47:35] <paul_c> any helper scripts required to run emc - ${prefix}/bin
[21:49:44] <paul_c> lib*.so are dynamically relocatable libraries
[21:50:33] <alex_joni> yup.. but are there any for emc2?
[21:50:33] <paul_c> at the moment, emc2 is statically linked, so we don't have any *.so
[21:51:18] <alex_joni> I see.. so where do the .o and .a go?
[21:51:22] <paul_c> if there are any *.o in /lib, then they should be removed on install
[21:51:40] <alex_joni> those are linked... I see
[21:52:00] <paul_c> *.a are only of any use at linking time
[21:52:34] <paul_c> and if the headers are not installed in ${prefix}/include - No need to install *.a
[21:53:08] <alex_joni> right
[21:53:38] <paul_c> Oh... And any *.a in rtlib must not get installed in KVERS/yadda
[21:53:59] <alex_joni> only *.o in rtlib
[21:54:28] <paul_c> at the moment, yes
[21:54:50] <paul_c> and only as long as they are loadable kernel modules.
[21:55:08] <alex_joni> we will figure out later how to decide that
[21:55:12] <alex_joni> maybe a modinfo
[21:55:25] <paul_c> That should be taken care of by the makefile
[21:55:33] <alex_joni> yup
[21:55:46] <paul_c> If it isn't then it needs a kick up the
[21:55:54] <paul_c> to conform.
[21:55:57] <alex_joni> which leeds us to configs
[21:56:09] <alex_joni> uh.. we forgot the realtime script
[21:56:21] <alex_joni> I think we agree that goes to /etc/rc.d/init.d/
[21:57:20] <paul_c> Not all systems have /etc/rc.d/init.d
[21:57:27] <alex_joni> no?
[21:57:40] <paul_c> I have /etc/init.d
[21:57:57] <paul_c> and /etc/rc.X
[21:58:02] <alex_joni> well... on most /etc/init.d is a symlink to the first one
[21:58:28] <paul_c> nope
[21:58:38] <alex_joni> on older... (not most)
[21:58:55] <alex_joni> - /etc/init.d is the place to do it
[21:59:26] <alex_joni> I have /etc/init.d and /etc/rc.d as a symlink to the first one
[22:00:51] <paul_c> where as I have /etc/init.d and /etc/rc.[0-6]
[22:01:05] <paul_c> where as I have /etc/init.d and /etc/rc[0-6].d
[22:01:11] <alex_joni> how about adding a section to configure to figure that one out?
[22:03:27] <paul_c> if /etc/rc.d is a symlink to /etc/init.d - There is no problem
[22:04:08] <alex_joni> let's presume that is handled by configure
[22:04:13] <alex_joni> and we skip it for now...
[22:04:42] <alex_joni> configure can search for /etc/init.d /etc/rc.d, etc. and see what are symlinks, and what are actual dirs
[22:05:16] <alex_joni> and after that Makefile.inc contains the $(initd_dir)
[22:05:27] <alex_joni> which is the location to copy the realtime script
[22:05:29] <alex_joni> ok?
[22:06:29] <paul_c> Sounds reasonable... But
[22:07:57] <paul_c> I will not support the installation of any scripts in /etc/init.d until emc2 is stable and does not cause system lock ups.
[22:08:20] <alex_joni> sure... that's why we have time to figure that one out later
[22:08:29] <alex_joni> let's return to install locations
[22:08:31] <paul_c> In other words - The whole system must be rock solid and stable first.
[22:09:25] <alex_joni> ok... what I think...
[22:09:34] <alex_joni> 1). scrap the whole autoconf dirs
[22:10:20] <alex_joni> (bindir, libdir, libexecdir, sharedstatedir, localestatedir, etc.)
[22:10:32] <alex_joni> 2) clean out Makefile
[22:10:47] <alex_joni> (I took the Makefile from emc2, and started from there)
[22:11:39] <alex_joni> 3) configure will generate ${prefix} (standard = /usr/local, or whatever and --with-prefix=<> possible)
[22:11:51] <alex_joni> 4) make install will do:
[22:12:08] <alex_joni> 4.1. install the realtime script (right now commented out)
[22:12:32] <alex_joni> 4.2. install the kernel modules (into ${halmodulesdir} discovered by ./configure)
[22:12:54] <alex_joni> 4.3. install the cvsroot/bin/* into ${prefix}/bin
[22:13:31] <paul_c> where the ... did halmodulesdir come from ?
[22:13:33] <alex_joni> 4.4. install cvsroot/lib/*.so into ${prefix}/lib (and remove cvsroot/lib/*.a and *.o)
[22:13:55] <alex_joni> 4.5. install cvsroot/docs into ${prefix}/docs
[22:14:11] <alex_joni> it's the modulesdir (in the latesc CVS)
[22:14:53] <alex_joni> s/modulesdir/moduledir/
[22:15:18] <alex_joni> I want to rename it to make it more clear... right now you might think it's the dir where rtai-modules are
[22:15:29] <alex_joni> and may be needed for including options.. but it's not
[22:16:17] <paul_c> moduledir is sufficient
[22:16:19] <alex_joni> 4.5. install cvsroot/docs into ${prefix}/share/emc2/docs (sorry bout the typo)
[22:16:43] <alex_joni> 4.5. install cvsroot/nc_files into ${prefix}/share/emc2/nc_files
[22:16:47] <alex_joni> 4.6. install cvsroot/nc_files into ${prefix}/share/emc2/nc_files
[22:17:10] <alex_joni> 4.7. install cvsroot/tcl into ${prefix}/share/emc2/tcl
[22:17:33] <alex_joni> we still need:
[22:17:49] <alex_joni> emc.run from scripts to ${prefix}/bin
[22:18:18] <alex_joni> and the config stuff from configs to ${prefix}/etc or /etc/emc or /etc ?
[22:19:08] <paul_c> If the configs go into /etc - they MUST be in a sub-dir
[22:19:43] <paul_c> and not /etc/hal /etc/emc2 /etc/rtapi
[22:19:54] <alex_joni> but?
[22:19:59] <paul_c> Keep them all in one subdirectory.
[22:20:05] <alex_joni> ohh..
[22:20:08] <alex_joni> yes
[22:21:14] <paul_c> Oh, and don't use /etc/hal - This WILL conflict with kernel related stuff in the future.
[22:21:19] <alex_joni> how about /etc/emc ?
[22:21:27] <paul_c> /etc/emc2
[22:21:35] <alex_joni> ok
[22:22:41] <paul_c> There is just one thing missing so far
[22:22:56] <alex_joni> what?
[22:23:22] <paul_c> *.po
[22:23:39] <alex_joni> :PO
[22:23:46] <alex_joni> ok
[22:23:55] <alex_joni> where goes that?
[22:23:55] <paul_c> go into /usr/share/locale/${locale}/LC_MESSAGES
[22:24:48] <paul_c> But we can worry about that at a later stage.
[22:26:10] <alex_joni> ok I have Makefile so far
[22:26:32] <alex_joni> should I commit? (Makefile, configure.in, configure, Makefile.inc.in, Makefile.inc)
[22:28:12] <alex_joni> there must be some work on emc.run (in order to see from where it's run cvsroot or $PATH to know what .conf files to open)
[22:29:25] <paul_c> emc.run should look at a relative path, and the an absolute fo configs - Aborting if not found
[22:29:53] <paul_c> can always execute with -ini /foo/bar.ini
[22:30:31] <alex_joni> that's what we had in mind
[22:30:35] <paul_c> Install should not be modifying stuff as it installs (in my opinion)
[22:30:49] <alex_joni> same conclusion last night
[22:31:19] <alex_joni> ok.. I'm thinking about commiting... what do you think? can it be undone if it's not ok?
[22:32:15] <paul_c> There is no way that you can make a change that can not be recovered from if it turns out to be wrong.
[22:32:24] <alex_joni> ok... here it comes
[22:33:20] <alex_joni> I'll modify install.map acordingly first... ok?
[22:33:46] <paul_c> No prob.
[22:36:45] <paul_c> * paul_c stops for a tea break.
[22:44:31] <CIA-3> 03alex_joni 07auto_configure_0_1 * 10emc2/ (configure.in configure Makefile.inc.in Makefile install.map): some rework of the make install process. still a work in progress
[22:59:34] <alex_joni> * alex_joni is gone for lunch
[22:59:39] <alex_joni> i'll be back later
[23:55:39] <alex_joni> * alex_joni is back