Back
[00:03:17] <alex_joni> hey paul
[00:06:19] <logger_aj> * logger_aj is already logging
[00:10:09] <paul_c> We need to sort out this aegument about paths
[00:12:01] <alex_joni> agreed
[00:12:26] <alex_joni> thing is... we could need a poll or smthg...
[00:12:32] <paul_c> Hard coding absolute paths suck (in my opinion)
[00:12:33] <alex_joni> to decide what goes where...
[00:12:56] <alex_joni> well... I only can think of /etc/emc2 as an absolute path
[00:14:27] <alex_joni> but... I think if the user doesn't intervine while installing it should always go to the same location
[00:14:59] <alex_joni> so debugging users works easy... (even if they know nothing about their system)...
[00:15:28] <paul_c> Let's ignore the terms user, integrator, & developer for the moment
[00:16:50] <paul_c> Using EMC as the reference point...
[00:17:28] <paul_c> the current run script checks the path to see where it is located...
[00:17:50] <paul_c> and also checks for an -ini parameter
[00:18:09] <alex_joni> yes
[00:18:38] <paul_c> if -ini does not contain a path, then the current directory is used
[00:18:56] <alex_joni> * alex_joni fires up his devel-box
[00:19:47] <paul_c> if an ini file is found in the same directory as the run script, then it is used (if no path is given).
[00:20:12] <paul_c> If a full path is given, then this is checked instaed.
[00:20:23] <alex_joni> so emc.run is in the same path as emc.ini ?
[00:20:48] <paul_c> In both cases, if the file is not found, the run aborts with an error.
[00:20:53] <alex_joni> like /usr/local/bin ... ?
[00:21:50] <paul_c> /foo/yadda/emc need not be in PATH
[00:22:16] <paul_c> run /foo/bar/emc/emc.run
[00:22:21] <alex_joni> I see...
[00:22:34] <paul_c> and emc.run checks to see where it is
[00:22:37] <alex_joni> so we don't copy emc.run to some $PATH folder?
[00:23:37] <paul_c> emc.run does not have to be in a directory listed in the PATH
[00:24:23] <paul_c> if it is called either with a "cd /foo/bar/emc && emc.run" or "/foo/bar/emc/emc.run"
[00:24:30] <alex_joni> ok... thought it should...
[00:24:51] <alex_joni> * alex_joni rethinks stuff....
[00:25:25] <paul_c> the current EMC tree would place all libs, scripts, and bins in sub-dirs of the emc.run directory
[00:26:26] <alex_joni> I'm lost...
[00:26:29] <alex_joni> emc1?
[00:26:35] <paul_c> Yes
[00:26:39] <alex_joni> ohhh... ok
[00:27:10] <alex_joni> so with emc everything goes in subdirs
[00:27:32] <alex_joni> from the main dir (which contains, emc.run and one or more .ini, .var, .tbl )
[00:27:44] <paul_c> yes
[00:28:02] <alex_joni> well.. then.. why is it with emc2 different?
[00:28:42] <alex_joni> there must have been some ideas why to put confs in configs/, emc.run in scripts/
[00:28:45] <paul_c> * paul_c is working round to that in a bit...
[00:29:35] <paul_c> The original reason for using the emc2 structure was to reduce the amount of cruft in the top level directory
[00:30:54] <alex_joni> I can see that...
[00:32:01] <paul_c> Once emc.run has found the ini
[00:32:38] <paul_c> emc.nml, emc.var, and emc.tbl are then parsed
[00:33:08] <paul_c> they can either have full paths, or just the file names
[00:33:17] <alex_joni> i see
[00:33:31] <alex_joni> if they have just the file names.. you can have a problem
[00:33:37] <alex_joni> with other programs that get run
[00:33:38] <paul_c> No path, the current directory (where emc.run is loacted) is used.
[00:33:52] <alex_joni> e.g. milltask
[00:34:03] <alex_joni> it has to run from the dir where emc.ini is
[00:34:13] <alex_joni> (cd inipath && run milltask)
[00:36:21] <paul_c> milltask is passed an ini parameter (that may or may not contain a path)
[00:38:52] <alex_joni> I looked briefly at milltask's components... gotta take a deeper look
[00:39:05] <alex_joni> don't think that paths in emc.ini are handled anywhere
[00:39:25] <alex_joni> so you think emc.ini should contain some information about the paths?
[00:40:55] <paul_c> No... What I was getting at is currently emc(1) will use full paths or default to the location where the run script is
[00:42:16] <paul_c> but if full paths are used, they are spec'd in the one ini file.
[00:45:18] <paul_c> Thinking about it.... The ini file IS the place to specify where kernel modules are located
[00:46:34] <paul_c> The hal configs are already listed, so it is a small matter to add path names
[00:48:00] <alex_joni> hmmm... how about the hal alone issue
[00:48:30] <paul_c> What about hal alone ?
[00:49:12] <paul_c> Like rtapi, without emc2, hal is nothing more than a odd little kernel module
[00:50:44] <alex_joni> yes.. but I thought it is desired that it can run alone... (hence have it's own config file)
[00:51:17] <paul_c> John would like to run it as a seperate entity
[00:52:00] <paul_c> * paul_c thinks the idea of turning everything in to modules is really insane
[00:54:46] <alex_joni> I don't really know, so I have no opinion.
[00:56:12] <alex_joni> but.. I know this...
[00:56:22] <alex_joni> I would like to see emc as an rpm
[00:56:26] <alex_joni> or at least tar.gz
[00:56:39] <alex_joni> and... ./configure, make, make install
[00:56:49] <alex_joni> should be everything someone should need
[00:57:02] <alex_joni> and type emc.run ... and there it is
[00:57:28] <paul_c> Right - And hard coded paths make the task of producing an rpm or deb that much more difficult.
[00:58:35] <alex_joni> ok.. then scrap the whole stuff...
[00:58:43] <alex_joni> and we're back to the autoconf stuff
[00:59:44] <alex_joni> which I don't really like...
[01:00:33] <paul_c> I'm not overly keen on all the extras that autoconf has sprouted either.
[01:03:03] <alex_joni> well...
[01:03:21] <alex_joni> maybe we need something like install.map but also for VARIABLES used
[01:03:39] <alex_joni> I am really starting to loose track of all VARS that get used
[01:03:40] <alex_joni> :(
[01:04:22] <paul_c> same here
[01:05:45] <alex_joni> but.. if we would have those autoconf dirs.. we would still need some hardcoded info what goes where
[01:06:06] <alex_joni> smthg like: emcsh goes to libexecdir/
[01:06:45] <alex_joni> * alex_joni is not really sure why that should be that way...
[01:07:26] <paul_c> * paul_c thinks if something is compiled to emc2/bin
[01:07:50] <paul_c> then it is installed in ${prefix}/usr/bin
[01:08:20] <cradek> hi all
[01:08:21] <alex_joni> ${prefix}/usr/bin ?
[01:08:25] <alex_joni> hi ...
[01:08:33] <alex_joni> we were just stirring up the soup
[01:08:39] <cradek> I see that
[01:08:49] <paul_c> emcsh is an executable - therfor ${prefix}/usr/bin is where it should go.
[01:08:54] <cradek> not sure I want any soup today
[01:08:59] <cradek> ${prefix}/bin
[01:09:09] <alex_joni> ${prefix}/usr/bin is new...
[01:09:32] <paul_c> ${prefix}/bin works too...
[01:09:57] <alex_joni> if ${prefix} = /usr .. then /usr/usr/bin ?
[01:10:08] <cradek> fwiw, I think the user should be able to start emc by typing `emc'
[01:10:17] <cradek> let's pretend we're all normal here
[01:10:43] <alex_joni> well.. emc or emc.run is pretty same stuff.. that's not the issue
[01:11:05] <alex_joni> you can always type emc and hit Tab
[01:11:43] <cradek> well, not if lots of other garbage is in the path
[01:11:52] <cradek> (what is emcsh?)
[01:11:53] <alex_joni> like emcsh ?
[01:11:56] <alex_joni> hihihi
[01:11:58] <cradek> hmm
[01:12:04] <alex_joni> emcsh is an extension of wish
[01:12:09] <alex_joni> with emc-stuff in it
[01:12:10] <paul_c> for me - It is a case of getting rid of a multitude of damned silly little configs
[01:12:32] <alex_joni> paul: we could settle for emc.ini only
[01:12:38] <cradek> for me it's about polluting the user's path for the sake of a tiny bit of simplicity or laziness on the part of the development
[01:13:24] <cradek> a new user will say "how do I start emc now that it's installed? I type emcsh and only get a blank rectangle"
[01:13:39] <cradek> that's bad.
[01:13:55] <paul_c> type wish
[01:14:07] <paul_c> Same response
[01:14:25] <cradek> right, but it's not named xtermsh or emacssh
[01:14:37] <cradek> wish is an interpreter. If I install it, I want an interpreter.
[01:14:52] <cradek> if I install emc, I don't want a tk interpreter. I want a machine controller.
[01:15:32] <cradek> in reality I don't care about emcsh so much - it's the subprograms that it makes NO sense to run that I care about more
[01:15:57] <cradek> grr I should have left my emc machine on
[01:17:27] <paul_c> So as an end user, you don't care where things like emcsh are, as long as emc[1|2] works
[01:18:16] <alex_joni> As an end user I care to know how to start emc[1|2]
[01:18:20] <alex_joni> and where to find configs
[01:18:38] <alex_joni> and what to change to make things work (hardware stuff)
[01:18:45] <cradek> and I want it installed in a sane way - the configs don't go in the root directory, for instance.
[01:20:02] <paul_c> configs either in ~/.emc2 or ${prefix}/share/emc2
[01:20:24] <cradek> sure
[01:20:30] <cradek> or maybe ${prefix}/etc/emc2
[01:20:45] <cradek> we should be just like every other program as far as the user can tell
[01:23:13] <paul_c> * paul_c favours ~/.emc2 or ${prefix}/share/emc2 and ${configs}/etc/emc2 for those that really need it to set up an embedded system
[01:23:54] <paul_c> but then etc/emc2 can be used with a customised run script without any detriment
[01:26:56] <alex_joni> let me get this straight...
[01:27:12] <alex_joni> everything goes to ${prefix}/something ?
[01:27:23] <alex_joni> or some go to ~/.emc2
[01:27:34] <alex_joni> and some go to ${prefix}/bin ?
[01:28:42] <paul_c> To my way of thinking - Yes (on the whole).
[01:29:12] <paul_c> The only problematic stuff is the realtime kernel modules.
[01:29:20] <alex_joni> and who decides which variant?
[01:29:38] <alex_joni> the user when running ./configure? or ./configure itself maybe?
[01:29:38] <paul_c> Do these go in /lib/modules/KVER/yadda
[01:30:32] <paul_c> or in ${prefix}share/emc2/modules
[01:33:51] <alex_joni> * alex_joni thinks that we really need to get more people to talk about this...
[01:33:58] <alex_joni> but not only talk... to decide stuff
[01:35:26] <cradek> but you're not going to get consensus
[01:36:23] <alex_joni> hmmm....
[01:37:08] <alex_joni> well... that's one of the reasons there's a board...
[01:37:28] <cradek> I'm tempted to suggest that you quit asking for opinions and do what you think is best, since you're the one doing the work.
[01:38:07] <cradek> you're willing to break with the old way and have knowledge about how other sane packages install, so I think you should do your thing
[01:38:19] <alex_joni> actually I'm not the only one doing the work...
[01:38:27] <alex_joni> and I'm not doing the work for me...
[01:38:32] <cradek> if you make a big mistake, we can just fix it, yay cvs
[01:38:38] <paul_c> All I can do is offer guidance and advice
[01:38:45] <alex_joni> I really want to make something everybody is happy with...
[01:38:47] <cradek> hmm, well I might be wrong, it's just a thought.
[01:38:56] <paul_c> and a recommendation to talk with zwisk
[01:39:03] <alex_joni> that too ;)
[01:39:15] <alex_joni> did you get the mail to the list?
[01:40:33] <alex_joni> thing is... as with everybody else, my time is pretty limited... so I don't like to waste it...
[01:40:54] <alex_joni> Don't mind it too much if I need to redo something... just not too often ;)
[01:41:25] <alex_joni> so if there are some guides: this should be done like that, or this should definately not be done like that
[01:41:30] <alex_joni> I'm very happy
[01:43:17] <paul_c> Yes, I got your last email to the list...
[01:43:41] <alex_joni> it was more to zwisk, than to the list...
[01:44:20] <paul_c> Open letters are good - As long as they don't decend into personal attacks....
[01:44:37] <alex_joni> * alex_joni kinda remembers something...
[01:45:22] <paul_c> what ever happens in the long term...
[01:45:37] <paul_c> it must be kept simple and well documented.
[01:46:04] <alex_joni> agreed
[01:46:13] <alex_joni> and it must be something very suitable
[01:47:45] <alex_joni> well I think we have to set up a group meeting
[01:48:39] <alex_joni> whoever wants to talk about paths & config stuff should be on #emc on the 7th Nov. 2004 between 14&18 GMT...
[01:48:44] <alex_joni> or smthg like this
[01:48:56] <alex_joni> * alex_joni gotta run now...
[01:48:57] <paul_c> * paul_c will write an open note to zwisk and accept shoulder some of the flack.
[01:49:49] <alex_joni> bye for now...
[05:17:48] <zwisk> hmm... I've mised alex again. drat.
[05:18:18] <zwisk> thanks for the letter paul. (And Alex, too, actually). I'm trying not to be upset :)
[05:18:35] <zwisk> Really I just wanna see us change the way we're doing things so taht more people feel like they can contribute.
[05:27:34] <paul_c> * paul_c understands the feeling...
[05:32:46] <zwisk> I know. I think everyone's 'heart' is in the right place... it's just harder to make these things actually happen than to want them to happen.
[05:35:21] <paul_c> There are three (maybe four) viewpoints out there....
[05:36:07] <paul_c> The "Keep it simple and do it well"
[05:36:33] <paul_c> the "Make everything modular and gve it a config"
[05:37:00] <paul_c> and the "I just want it to work".
[05:37:18] <zwisk> Personally, I think I'd like to see a fair bit of all of them.
[05:37:39] <zwisk> The config part is a big can of worms, however.
[05:38:11] <zwisk> I think we've somewhat proven that we've outgrown the current config mechanism, and need to visit the subject of what to do about it.
[05:38:57] <zwisk> It seems like a good thing to respect JMK's wishes on keeping hal an independent thing, but it also needs to have some stong tie in to emc2 if emc2 is going to rely on it.
[05:39:15] <zwisk> s/stong/strong/
[05:40:29] <paul_c> * paul_c thinks the hal idea has gone beyond the original proposal
[05:40:53] <paul_c> and the current hal configuration fails the "Aunt Tilly" test.
[05:41:58] <zwisk> You'll have to remind me about who Aunt Tilly is?
[05:42:45] <zwisk> Hal has gone beyond it's original purpose, which is great, IMHO... but... I sort of feel like it needs an integrated emc interface for config. If it needs a standalone interface too, that's fine, but ... emc needs more direct control.
[05:43:17] <paul_c> A fictional character that Ray refers to on the subject of configuring software
[05:43:25] <zwisk> One config file should (again, IMHO) be able to configure the entire system.
[05:44:17] <zwisk> scripts and relative paths really bug me.
[05:44:36] <zwisk> There must be a better way.?!
[05:45:12] <zwisk> So, aunt tilly can't understand how to config hal? Poor gal.
[05:46:25] <paul_c> Much of the information within a typical hal.config is implied within an emc.ini
[05:47:29] <zwisk> unfortunately, the two are different, and must be kept synchronized. To me, this is wrong. There should be only one place. Emc should configure hal from data in the ini, or it should ask hal for the data it already has and not have a value in the ini
[05:48:27] <zwisk> I'm not personally a big fan of xml, but an xml config file would have some benefits with all of this.
[05:48:42] <paul_c> Why, I do believe you have been reading the same books as me ;}
[05:49:05] <paul_c> * paul_c disagrees with the idea of xml configs...
[05:49:08] <zwisk> hmm.. what page are yo on? :)
[05:49:19] <paul_c> 763
[05:49:29] <zwisk> what's this, we're on the same page?!
[05:49:46] <zwisk> is there something better than xml, or do you just like the current ini format?
[05:50:36] <paul_c> The current format is pretty well established
[05:51:02] <paul_c> It is easy to parse, and is extensable.
[05:52:25] <Pigi> Ciao all
[05:52:32] <paul_c> ditto
[05:53:00] <zwisk> see ya, pigi...
[05:53:11] <zwisk> Are you heading out too, Paul, or just saying goodbye?
[05:53:30] <paul_c> not yet
[05:53:46] <paul_c> I had a couple of thoughts to bounce off you
[05:54:00] <zwisk> So, I don't care (at all) about "established". I know that's different than many emc'ers, but it's true...
[05:54:27] <zwisk> Extensible is interesting, though. Do you any thoughts about how hal config information might get put into the existing ini format?
[05:54:40] <zwisk> (and, of course, bounce away)
[05:55:23] <paul_c> established - Many other packages use a similar ini format, both linux & doze
[05:56:31] <Pigi> paul_c. I did a rapid read trough the code.... I have a question. May I pose it ?
[05:56:45] <zwisk> many packages have their own config formats. Many packages use xml. That one (for me personally) doesn't hold any weight for me.
[05:56:50] <zwisk> please, pose away...
[05:57:19] <Pigi> zwisk: was it for me ?
[05:57:52] <zwisk> sure, though in honesty, I misread and though paul_c was speaking :) But questiosn are good to get out in the open regardless. ;)
[05:58:10] <Pigi> eheeh. Ok
[05:58:34] <Pigi> how much the timing is important in freqmod or similar ( apart for speed ) ?
[05:58:41] <paul_c> * paul_c knows what Pigi is after - Can it wait ten mins ?
[05:58:47] <Pigi> yes
[05:59:21] <Pigi> I can wait nomatter how many time :)
[05:59:36] <Pigi> ( and apologize for my bad english )
[05:59:41] <paul_c> zwisk: Whilst XML may have advantages in some areas, I feel it does nothing to make a (typical emc) config easy to read
[06:00:26] <zwisk> I totally agree, actually.
[06:00:42] <paul_c> and unless there is a clear advantage in adopting another format, I'd be happy with the existing one - with some refinements.
[06:01:06] <zwisk> I'm afraid it needs to support some form of nesting.
[06:01:22] <zwisk> What refinements do you have in mind?
[06:01:53] <zwisk> It seems to me using some other config file libaray is in our best interest as well. We want to spend time writing and debugging emc code, not config file parsing code.
[06:02:30] <paul_c> * paul_c did find a config parser lib...
[06:03:30] <zwisk> cool. One that you like?
[06:03:38] <paul_c> Not really
[06:03:51] <zwisk> haha... well.. then what good is it? :)
[06:04:07] <paul_c> It would have required a re-write of inivar.c and a number of other sources.
[06:05:07] <zwisk> that's not *neccessarily* a bad thing.
[06:05:44] <zwisk> It seems to me that some of the tcl scripts, and hal, need a way to access whatever config file mechanism we use.
[06:08:10] <paul_c> Don't know about hal, but most (all ?) the tcl scripts accept an -ini parameter
[06:09:09] <paul_c> as do the key emc[1|2] executables.
[06:09:21] <zwisk> I don't think hal does now, but I think it needs a way to get data from the ini file. Whether it's fed to it from emc somehow or reads it from the ini itself...
[06:11:14] <paul_c> right - So should the hal stuff require a config file name to be passed on the command line ?
[06:12:23] <zwisk> I don't know... Hal doesn't seem to be set up that way at the moment...
[06:12:56] <zwisk> emc is very distributed. I think that leads to a lot of the coordination problems. I wonder if there's a way to make it less distributed somehow...
[06:13:33] <zwisk> modular is good. Distributed ... I'm not sure...
[06:13:39] <paul_c> lock everyone in the same room for three months ?
[06:14:03] <zwisk> well, actually I meant the code more than the people. But what you say has some potential good to come of it as well.
[06:15:00] <zwisk> The fact that emc.run sets up a bunch of seperate things, and that tcl, C, (and others) all have to play well together, launched potentially from different directories with potentially different paths and dependent files = distributed
[06:15:56] <paul_c> perhaps that is where the problem lies
[06:16:50] <zwisk> some of them, for sure. But I don't know that there is much to do about it...
[06:17:16] <paul_c> <bouncing thoughts> Ignoring the realtime kernel modules for a moment...
[06:17:56] <paul_c> anything that is compiled to emc2/bin gets installed to ${prefix}/bin
[06:19:05] <paul_c> key scripts such as emc2.run also install to ${prefix}/bin
[06:19:24] <zwisk> sounds right so far...
[06:20:22] <paul_c> tcl & misc scripts, along with default configs, sample ngc, etc - All install to ${prefix}/share/emc2/{what ever sub-dirs}
[06:21:19] <zwisk> This is where things get tricky. How does emc2.run find these things? Or how do these things find emc2? There are dependencies between /bin and /share/ecm2/* items, right?
[06:21:53] <paul_c> as long as ${prefix}/bin is in the usr $PATH
[06:22:36] <zwisk> So is it true that nothing in ${prefix}/bin will ever need to find anything in {$prefix}/share/emc2/ ?
[06:23:43] <paul_c> in terms of execution, that would be true.
[06:23:56] <zwisk> hmm... what else beside execution is there?
[06:24:11] <paul_c> The only remaining issues would be configs and kernel modules.
[06:24:41] <paul_c> and optionally, *.po - But these are a special case..
[06:25:11] <zwisk> My concern is that it shuoldn't be hard coded "${prefix}/share/emc2" and "${prefix}/bin". Assuming prefix and the paths are the same breaks configure, where "--datadir" can override the default "PREFIX/share" and "--bindir" can override the default
[06:25:32] <zwisk> "EPREFIX/bin"... note "EPREFIX" for execution and "PREFIX" for architecture independent files...
[06:28:13] <paul_c> the tcl scripts in ${prefix}/share/emc2/yadda rely on the ${prefix}/bin being in the $PATH, so nothing needs to be hard coded for that side
[06:28:35] <paul_c> <still bouncing ideas/thoughts>
[06:28:40] <zwisk> ok... that's cool...
[06:29:28] <paul_c> And the only thing that needs to know where the tcl scripts are is the emc2.run
[06:29:35] <zwisk> kernel modules I think should be handled at somepoint by depmod or some other system level tool.
[06:29:49] <zwisk> This requires some rethinking of hal, I think, but it's very doable.
[06:30:20] <paul_c> Right...
[06:30:49] <zwisk> ok, so do all 'scripts' get put in the same share/emc2 folder? Right now, I think there's a subdirectory within tcl for ... I'm not sure what. support libraries rather than directly callable scripts?
[06:31:11] <paul_c> Whilst giving the "end user" an infinite number of choices might be good, it can be detrimental to the developer's needs.
[06:31:49] <zwisk> In reference to ... ?
[06:33:05] <paul_c> all the choices for install directories
[06:33:41] <zwisk> yes. That is true. But if we can, I think we should.
[06:34:18] <zwisk> I wonder a bit about the ~/.emc2 idea in this context, since emc2 currently has to be run as root...
[06:35:52] <paul_c> That is the downside to emc[1|2]
[06:36:16] <zwisk> With hal, only hal touches anything that needs root privs, right?
[06:38:31] <paul_c> hal is kernel space, so can only be loaded/unloaded by root
[06:39:53] <zwisk> right. Once loaded, though, does anything else in emc require root? (Or, in other words, if hal was already loaded, and we had a way for hal to speak to a user other than root, could emc run as a user level process?)
[06:41:40] <paul_c> Once all the kernel modules are loaded, there is nothing that needs root access for normal operation of emc[1|2]*
[06:42:15] <paul_c> Only the IO tcl scripts and the IO controller currently require root priv.
[06:42:32] <zwisk> that's pretty cool. There's hope then that we could make emc run as a normal user...
[06:42:53] <zwisk> The IO tcl scripst and IO controller speak to hal now, right?
[06:43:59] <paul_c> Nope.
[06:44:44] <zwisk> oh.
[06:44:53] <paul_c> At the moment, we don't have a functioning IO control for emc2
[06:45:23] <zwisk> oh, IO control is like the 'extra' bridgeport control features? (coolant, spindle speed, etc?)
[06:45:39] <paul_c> Yes.
[06:46:08] <zwisk> right. So, they will speak to hal once ... reimplemented...
[06:46:29] <paul_c> maybe...
[06:48:41] <paul_c> Short term fix for this is to do a check for sudo, and if emc2.run is being run by a lusr, prefix IO scripts/executables with sudo.
[06:49:23] <paul_c> This would also work for insmod/rmmod
[06:49:31] <zwisk> yep.
[06:49:43] <zwisk> That seems like a good short term fix, actually.
[06:49:56] <zwisk> $SUDO could be added to all the script lines needing that, and defined to nothing if sudo doesn't exist.
[06:50:21] <paul_c> or if whoami returns "root"
[06:50:30] <paul_c> Hi daryl
[06:50:39] <zwisk> greetings, Daryl!
[06:50:40] <daryl> Hey
[06:50:46] <daryl> * daryl looks around.
[06:51:03] <zwisk> sudo as root just executes the command...
[06:51:04] <paul_c> they are all lurkers over there
[06:51:16] <daryl> * daryl lurks.
[06:51:50] <daryl> Never been here before... thought I'd drop by and see what's up.
[06:52:56] <paul_c> if (whomai != root && !f sudo) ; echo "Gotta be root Jimbo"; else SUDO=sudo ; fi
[06:53:23] <zwisk> yep... looks good at first glance.
[06:53:30] <paul_c> * paul_c isn't very good with off-the-cuff bashing
[06:53:47] <zwisk> You're too polite for that :)
[06:54:07] <paul_c> daryl: Currently discussing alternatives for emc2 run scripts & install locations.
[06:55:15] <paul_c> back to <bouncing ideas>
[06:55:18] <daryl> Good stuff.
[06:55:20] <zwisk> I gotta run and take care of some away-from-the-desk stuff, but feel free to continue to dump ideas here... I'll comment as I can...
[06:55:41] <paul_c> If we agree that emc2.run is in $PATH
[06:56:05] <paul_c> the only thing we need to feed it is the ini file
[06:56:42] <paul_c> it can default to looking in ${prefix}/emc2/configs and/or ~/.emc2
[06:57:02] <paul_c> if it isn't given an explicit path/file name
[06:57:40] <Pigi> why don't use the unix standard ? something like ${prefix}/etc or ${prefix/share/emc2/ or with the -f ( or -c ) flag ?
[06:58:03] <paul_c> Any other configs and oddball script locations could be spec'd within tis one file
[06:58:54] <Pigi> yes. or there could be some ini section descriving the location. I think btw that ~/.emc2 could be the better choice
[06:59:20] <paul_c> the default location(s) could include ${prefix}/etc/emc2
[07:00:40] <Pigi> in a lot of programs the location is hardcoded in sourcefiles, starting fromsome -D (define ) that could be choose in configure phase, and could be overwritten
[07:00:50] <Pigi> via some flag
[07:01:00] <Pigi> at runtime, or in configure/make phase
[07:02:10] <paul_c> Hard coding is OK for some things.... But it does make things a little difficult when building debs & rpms
[07:03:11] <Pigi> but in rpms or debs there is some "packager" that do the work. So a standard location for install could be some /usr/bin or whatever
[07:03:24] <Pigi> and then have the /etc/emc2 config dir
[07:05:21] <paul_c> The other problem with hard coded paths - If you want to test without doing an install, and/or intend to use different directories.
[07:05:51] <zwisk> getting 'standard' locations from configure is my preference... "--bindir", "--sysconfdir"
[07:06:27] <Pigi> in test phase you can always work with aa chrooted environment, and in any case you could always have the flag at execution time that point to the config file/dir
[07:07:10] <zwisk> chrooted environment? How do you get your tools into you chrooted environment for test?
[07:07:27] <zwisk> hmm... oh well.. Bye! :)
[07:08:16] <Pigi> sorry....
[07:08:20] <paul_c> chroot & fakeroot have their uses - But not everyone will have them installed
[07:09:05] <zwisk> chroot I'm familiar with. Fakeroot sounds like a useful tool (that is in fact not installed) that I should go look at...
[07:09:26] <Pigi> I know. But what I think is that the biggest part of emc user probably won't never knows where the configurations file or whatever are.
[07:10:05] <Pigi> Some more advanced *x users won't complain in pass some flags to executables or to recompile with some configure option
[07:10:09] <Pigi> ( i suppose )
[07:13:56] <paul_c> zwisk: That's about all as far as bouncing ideas around goes - Much of this is a repeat of a discussion with Alex earlier today.
[07:14:57] <zwisk> It seems we should consolidate the key ideas somehow and put them into something we can refer to rather than repeating the conversation...
[07:15:43] <Pigi> eheheh right
[07:15:45] <paul_c> OK... I'll take your latest emc-dev mail and add to it
[07:16:29] <paul_c> But please, please, don't take offence...
[07:16:56] <daryl> Don't know if this is already covered, or obvious, but it would be good if there is a way to configure both a prefix and an install prefix.
[07:16:59] <paul_c> Consider it a "point of discussion" to be taken with a pinch of salt
[07:17:35] <zwisk> ummm.. ok.. Are you planning on saying something offensive? If so, I wouldnt' see it as a summary of what we've discussed today?
[07:18:04] <zwisk> My feeling of offense is in feeling like I've been good about commenting other folks code that was changed out, commenting why I've changed it, and then commenting my changes.
[07:18:08] <paul_c> Generally, ${prefix} is the install prefix
[07:18:44] <zwisk> It's offensive when someone else bulk deletes your changes without any explanation of why. It gets worse when you feel their changes remove functionality that you've put in, and want, and use... with no reasoning.
[07:18:52] <daryl> Not necessarily done at ./configure time. The point of it is to allow isntalling the whole thing to a different dir so that it can be tar'd up and put on another computer.
[07:19:06] <daryl> Without breaking the local computer.
[07:19:18] <daryl> local = build
[07:19:50] <paul_c> zwisk: I have no intention of drecrying your work and hard efforts...
[07:21:19] <paul_c> In hind sight, I think it would have been preferable if the quilty party and commented out rather than deleting your work.
[07:21:50] <paul_c> But at least we can revert it all in a few keystrokes.
[07:22:27] <zwisk> speaking of such things, is the overhead for tags relatively low? If I wanted to do some experimetnal work on emc2, can I create a tag for that without cluttering things up?
[07:22:47] <paul_c> Use as many tags as you like
[07:23:28] <zwisk> ok... cool. Moving and creating directories in a tag doesn't create a big mess anywhere?
[07:23:31] <paul_c> If you want to do some stuff outside of SF, I can even set you up with an account on my cvs server...
[07:24:09] <zwisk> I have a cvs server as well, but changelogs are important to me. My interest would be in making sure the changelogs can be kept with the changes if things are ever merged.
[07:25:02] <paul_c> Well... Feel free to tag & branch - Delete the entire tree within the branch if you want to...
[07:25:26] <paul_c> It won't affect any of the other branches
[07:25:48] <paul_c> and is much more preferable to creating a new top level module.
[07:25:56] <zwisk> excellent. Ok. Thanks.
[07:26:34] <paul_c> If anyone gives you ANY grief about a tagged branch, you send them to me.
[07:26:53] <paul_c> In other words - You have my full support !
[07:27:07] <daryl> * daryl hands zwisk a bowl of grief.
[07:27:26] <paul_c> * paul_c gets ready to kick/ban daryl ;}
[07:28:15] <daryl> So did my question/comment about being able to specify a different install dir make any sense?
[07:29:45] <paul_c> Oh yes... But we have two camps at work
[07:30:11] <paul_c> One side wants to run from the directory were the code was compiled
[07:30:30] <paul_c> the other wants to run after a "make install"
[07:31:06] <paul_c> Then there is a bunch on the fence that wants both.
[07:31:10] <zwisk> I *think* everyone wants to run from the directory where the code was compiled, and additionally after "make install". Is there someone who does not want run-in-place?
[07:31:15] <zwisk> oh..
[07:31:46] <daryl> Both would be cool. My set up has two PC's: the slow one runs rtai and emc, the other runs the gui. Being able to compile things on the fast machine and just copy them over would be nice. (Maybe this is possible... been a long while since I've played with compiling emc)
[07:32:14] <zwisk> rpms or .debs are pefect for you... (and me!)
[07:32:47] <daryl> And one of these days I'm going to trash the slow computer, so it doesn't really matter. It's just a comment.
[07:33:12] <paul_c> One answer might be the kernel build trick of passing an install dir at the make stage rather than configure
[07:33:31] <daryl> Being able to specify a temporary install directory to allowing creating an archive to be put on another machine (to run out of the ./configure'd prefix) can be handy.
[07:34:08] <daryl> yeah... passing the make install stage is what I was thinking.
[07:34:13] <paul_c> If you are building deb/rpm packages, it is essential
[07:34:28] <daryl> passing the directory even.
[07:35:05] <paul_c> ./configure --prefix=/usr && make INSTALL_DIR=/usr/src/build
[07:35:53] <daryl> Something like that would be good. Just as long as it doesn't affect where the executables think things are.
[07:36:41] <Pigi> but ( if I remember well) with gnu make you could always specify some install directory, but that doesn't mean that the executable would be able to "find" the config files
[07:37:14] <Pigi> you should, at least, specify something in source code
[07:37:19] <daryl> Not finding the config files is fine.
[07:38:01] <Pigi> as per: #ifdef SOMETHING confdir=$INSTALLDIR #ENDIF
[07:38:23] <Pigi> daryl: not too much if the binary depends on it....
[07:38:30] <zwisk> RTAI uses $DESTDIR as a 'silent' prefix to all install paths for package building.
[07:38:45] <daryl> Pigi, I think you're missing the point.
[07:38:49] <paul_c> Look for a config in a default location and about if a) none found, or b) no config passed on the command line
[07:39:01] <paul_c> \aboout\abort\
[07:39:29] <daryl> My point is not to make a working install. It's to make an install image to be moved to the real machine at the real prefix.
[07:40:11] <Pigi> I can't really see the problem then, especially if using some package manager.....
[07:40:22] <daryl> Never mind.
[07:41:10] <Pigi> Nothing could be more easy then install an rpm, that has everything needed inside.... Am I missing yet the point ?
[07:41:45] <zwisk> Pigi: The problem is *creating* the pacakge (rpm). As developers, we want the compile system to make creation of rpms, debian packages, or whatever to be easy.
[07:42:56] <zwisk> Currently, we aren't creating rpms and debian packages and tar balls that easily compile, in some part (if not completely) because it's hard for us to do at the moment! :)
[07:43:03] <Pigi> ok. But AFAIK, giving the right specs at beginning make the packaging easy .....
[07:43:33] <zwisk> you mean rpm .spec file?
[07:44:00] <Pigi> No. I mean source code specs ( for config at least )
[07:44:17] <zwisk> I think I'm lost. ? Source code specs?
[07:44:29] <paul_c> configure options
[07:44:35] <Pigi> No, you're not. It's my bad english....
[07:44:47] <Pigi> right
[07:44:57] <zwisk> sure... the correct configure options... but we need to support the configure options, which we don't do yet :)
[07:45:15] <Pigi> that's what I was trying to mean ;)
[07:45:58] <paul_c> configure options and special make options are part and parcel of an rpm.spec
[07:46:15] <zwisk> Excellent. It's not clear to me that there is a standard configure option for prefixing the install paths with a package build target location.
[07:46:56] <zwisk> DESTDIR, however, is a make option that is used a few places, including rtai-3.1, for this purpose.
[07:47:18] <zwisk> I don't really care what we call it, or if it goes in make or configure, but I do want the functinality.
[07:47:39] <Pigi> I do absolutelly agree with you.
[07:47:50] <paul_c> and I need to eat...
[07:48:31] <zwisk> have a good ... dinner? Paul...
[07:48:37] <Pigi> eheheh
[07:49:01] <Pigi> right. I will try to make my ideas clear, and eventually post it on emc-dev
[07:52:38] <Pigi> * Pigi needs to sleeps a bit. This would not improve his english, but may help.
[07:53:11] <Pigi> see ya later.
[07:53:44] <zwisk> gnight...
[07:53:49] <daryl> DESTDIR at make install time looks pretty common. I just looked at a few other packages.
[07:54:07] <zwisk> It works for me ...
[09:45:52] <robin_z> meep?
[09:45:57] <robin_z> * robin_z meeps
[09:46:01] <robin_z> again
[10:13:58] <zwisk> moop?
[10:23:43] <paul_c> zwisk: Reply on it's way.
[14:28:47] <asdfqwega> Woot!
[14:28:55] <asdfqwega> It works!
[14:29:32] <asdfqwega> * asdfqwega is using a homebrew wireless antenna to boost the range to reach from the house to the shop.
[14:30:06] <asdfqwega> Now I can pester you guys 24/7 <eg>
[14:46:13] <danfalck> * danfalck is away: going out to the shop...
[15:10:27] <lilo> [Global Notice] Hi all. There will be extensive but brief network outages in about 7 hours; for more information, please see
http://freenode.net/news.shtml .... thank you for using freenode!
[21:24:23] <alex_joni> hello paul_c
[21:32:03] <paul_c> Morning Alex
[21:35:22] <alex_joni> pretty close on the election thingy
[21:39:17] <alex_joni> did you catch zwisk in here? seems I've been missing him lately... :(
[21:39:27] <alex_joni> maybe today, I plan on gettin in pretty late...
[21:41:09] <paul_c> Had quite a long chat with zwisk last night..
[22:05:56] <alex_joni> any conclusions?
[22:07:02] <paul_c> Nothing confirmed as yet...
[22:08:24] <paul_c> had rather assumed you and zwisk were in regular contact over the details of autoconf
[22:12:23] <alex_joni> not really...
[22:12:41] <alex_joni> I started the autoconf, with your help on tagging & such
[22:12:53] <alex_joni> and zwisk jumped in and added the autoconf *dirs
[22:13:13] <alex_joni> I sent an e-mail to the list today...
[22:17:20] <paul_c> The CIA stats only show the last week or so of commits
[22:19:04] <paul_c> * paul_c checks the emc-commit mails
[22:20:21] <paul_c> OK... zwisk started working on the Makefiles, and you started with configure.in
[22:20:54] <paul_c> and the work was converging up until a few days ago.
[22:21:36] <paul_c> i.e. You were working on the same task from different ends.
[22:22:55] <alex_joni> yup.. pretty much
[22:24:08] <alex_joni> that needs to be changed
[22:25:23] <paul_c> There's nothing wrong with wonking on a task from different ends....
[22:25:57] <paul_c> As long as everyone discusses the common goals
[22:25:59] <alex_joni> yup.. but communication is still needed
[22:26:18] <paul_c> either via irc, emc-dev, or in private emails.
[22:27:03] <alex_joni> even better when all are included...
[22:27:12] <alex_joni> so irc & emc-dev& private emails
[22:27:20] <alex_joni> on emc-dev conclusions & such
[22:36:15] <paul_c> I have two basic rules - Keep it simple, & Use plenty of comments. Then I look at it and think "Can someone else maintain/modify this without needing a degree in CS".
[22:37:47] <alex_joni3> sorry... I got disconnected
[22:38:16] <paul_c> I have two basic rules - Keep it simple, & Use plenty of comments. Then I look at it and think "Can someone else maintain/modify this without needing a degree in CS".
[22:42:27] <lilo> [Global Notice] Hi all. Per the news page (
http://freenode.net/news.shtml), our sponsors core router restart should be complete. We may do a bit of route tweaking mid-afternoon. Thank you for your patience, and thank you for using freenode!
[22:51:06] <asdfqwega> Gah, I'm bushed.
[22:54:04] <paul_c> Sounds better than being "kerried"
[22:54:20] <asdfqwega> Heh...I didn't even think of that one.
[22:54:24] <paul_c> Afternoon Tom.
[22:54:44] <asdfqwega> Morning, Paul.
[22:55:09] <asdfqwega> I mailed out the little signs on Monday.
[22:56:07] <asdfqwega> I sent you three...one for you, one for "the little sis", and one extra for emergencys
[22:56:24] <paul_c> * paul_c needs to go to the Post Office to get some more stamps...
[22:57:11] <asdfqwega> And your away message will read "Going postal - be back later."
[22:58:21] <paul_c> The local post office has been closed down
[22:58:27] <asdfqwega> Oh, and I sent you one more thing with the package - my best accident.
[22:58:39] <paul_c> So I'll have to hicke a bit further to find another one.
[23:04:51] <asdfqwega> Ugh, what a night.
[23:05:09] <asdfqwega> First, I make a new lens mount/ air nozzle for the laser.
[23:06:17] <asdfqwega> Then, I tear down an old digital sat. dish, and make it into a 802.11b antenna, an put it up in the dark. But now I have internet out to the shop.
[23:06:36] <alex_joni3> what distance?
[23:06:45] <alex_joni3> alex_joni3 is now known as alex_joni
[23:06:59] <asdfqwega> 100+ yards
[23:07:08] <alex_joni> hmmm.. meters?
[23:07:09] <alex_joni> :D
[23:07:28] <asdfqwega> * asdfqwega is too tired to convert in his head.
[23:07:33] <alex_joni> lol
[23:08:19] <asdfqwega> Then, to top it off, I took care of an old problem: restoring a MySQL database from a backup.
[23:08:50] <paul_c> Yards to Metres 0.9144
[23:09:10] <alex_joni> 1 yard = 0.914 401 8288 meter
[23:09:48] <paul_c> * paul_c points out the correct spelling is metre
[23:09:51] <asdfqwega> Okay, approx 90 meters
[23:10:18] <alex_joni> * alex_joni points out it was cut-n-pasted from a .gov page
[23:10:32] <alex_joni> so blame them for the correct spelling ;)
[23:10:42] <paul_c> us.gov ?
[23:10:57] <alex_joni> http://www.wsdot.wa.gov/Metrics/ftmtr2.htm
[23:11:24] <alex_joni> washington state department of transportation
[23:11:52] <asdfqwega> * asdfqwega wonders why they didn't just call the unit a "metric"
[23:11:52] <asdfqwega> That way, it would be even easier to remember :P
[23:13:31] <alex_joni> * alex_joni is not sure foot's are the proper way to go...
[23:13:55] <alex_joni> I don't really know the difference between a foot and a U.S. Survey foot.
[23:14:13] <paul_c> http://www.iso.org/iso/en/commcentre/isobulletin/articles/archives/iso31quantities2-97-09.html
[23:20:54] <asdfqwega> To which, I say: Meep.
[23:21:19] <alex_joni> that's robin's line...
[23:22:48] <asdfqwega> I wonder if I should sleep, or attempt to go pay some bills in my current state...
[23:25:28] <asdfqwega> * asdfqwega lurks.
[23:57:35] <CIA-9> 03alex_joni 07auto_configure_0_1 * 10emc2/ (10 files in 2 dirs): undoing changes done over the weekend. Those changes were intented to be a temporary try. Seems it wasn't the way to go, so it gets removed. The state to which things get restored is: 31 Oct 2004 02:00.
[23:57:36] <CIA-9> 03alex_joni 07auto_configure_0_1 * 10emc2/ (scripts/emc.run scripts/emc.run.in tcl/tkemc.tcl): undoing changes done over the weekend. Those changes were intented to be a temporary try. Seems it wasn't the way to go, so it gets removed. The state to which things get restored is: 31 Oct 2004 02:00.