Back
[17:05:32] <rayh> logger_devel: bookmark
[17:05:32] <rayh> See
http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emcdevel/2006-01-01#T17-05-32
[17:53:16] <ajoni> ajoni is now known as alex_joni_
[17:58:57] <rayh> alex_joni_: I put the sudo in emc.in for emcio.
[17:59:12] <alex_joni_> seen the commit
[17:59:29] <rayh> think I wrote a wrong message but...
[17:59:41] <alex_joni_> you wrote emcsh in the commit message
[17:59:50] <rayh> ah.
[18:00:01] <alex_joni_> which made me wonder :D
[18:00:12] <rayh> looks like with this change io runs as root while emcsh, and the gui stuff runs as user.
[18:00:23] <cradek> rayh: was that commit supposed to be a one line change? Many lines were changed for some reason
[18:00:27] <alex_joni_> that's good
[18:00:43] <alex_joni_> cradek: noticed it too, yet nothing seems changed for all that lines
[18:00:48] <rayh> How were they changed.
[18:00:56] <cradek> not sure
[18:00:59] <alex_joni_> indenting
[18:01:03] <alex_joni_> from what I'm reading
[18:01:09] <alex_joni_> - CFGFILE=$INI_DIR/$CFGFILE
[18:01:09] <alex_joni_> + CFGFILE=$INI_DIR/$CFGFILE
[18:01:16] <alex_joni_> that's one example
[18:01:17] <rayh> I cvs up'ed and then changed the one line.
[18:01:48] <alex_joni_> maybe you used a different editor, which needed to change stuff :)
[18:01:53] <cradek> rayh: your editor must do things you don't want
[18:02:19] <alex_joni_> in this case it doesn't really matter
[18:02:35] <rayh> can we see what i did?
[18:02:55] <alex_joni_> the commit message holds all the changes
[18:02:57] <cradek> working on it...
[18:03:08] <alex_joni_> mostly (if not all), are changes from ' ' to ' '
[18:03:13] <alex_joni_> in front of the lines
[18:04:03] <cradek> looks like a lot of indention got screwed up
[18:04:12] <cradek> where there used to be 8 spaces there are now 2
[18:04:18] <cradek> so things are indented wrong
[18:05:01] <rayh> ah my default intent is 2 for tickle. I suppose we should pas it thorugh some sort of standard formatter.
[18:05:05] <cradek> for instance look at the block starting at line 500
[18:05:16] <rayh> Do folk stilluse 8 for standard indent.
[18:05:57] <cradek> rayh: the problem is your editor changed dozens of lines you didn't touch
[18:05:59] <rayh> Is there a standard formatter we were using.
[18:06:09] <rayh> I hear you!
[18:06:17] <alex_joni_> not for scripts, there is indent configured for .c and .h
[18:06:19] <cradek> nope there really isn't
[18:06:44] <alex_joni_> but scripts are usually non-standard with indenting
[18:06:48] <rayh> What I usggest then is that you revert to a previous version,
[18:07:12] <rayh> I'll make a bug report and let youse guys fix ie eh.
[18:07:40] <alex_joni_> rayh: it's no big problem
[18:07:48] <cradek> rayh: I fixed the indentation but kept your change, np
[18:07:50] <alex_joni_> at least not for emc.in
[18:08:15] <alex_joni_> but it might be a problem for important stuff, where these changes would just hide the obvious
[18:08:38] <alex_joni_> I always do a cvs diff before commiting, and checking that it contains only what I intend to commit
[18:08:46] <rayh> I had planned a couple hundred fixes to the config stuff.
[18:08:55] <cradek> I agree reformatting and significant changes should always be in different commits
[18:09:14] <cradek> rayh: what editor did you use? Maybe we can figure out how to configure it
[18:09:18] <rayh> kwrite
[18:09:33] <rayh> I have it configured for 2 spaces for indent
[18:09:37] <rayh> deliberately.
[18:09:46] <rayh> what would you prefer that I use.
[18:09:50] <alex_joni_> that's ok for new stuff you write
[18:10:05] <alex_joni_> but it shouldn't later existing files without asking, that's intrusive imho
[18:10:13] <alex_joni_> * alex_joni_ uses mcedit usually
[18:10:16] <rayh> I'm guessing that it also does that for stuff it opens.
[18:10:53] <cradek> rayh: I would hope you could turn that off...
[18:11:21] <rayh> I presume that I can set aside a editor someplace that will operate without reformatting.
[18:11:32] <cradek> rayh: some editors also change between spaces and tabs without asking, and I think that's wrong behavior too - cvs considers changes like that relevant
[18:11:58] <rayh> I don't believe that tabs ought to be a part of code.
[18:12:02] <cradek> rayh: sounds like an answer
[18:12:10] <alex_joni_> and other editors display tabs/spaces differently
[18:12:41] <cradek> I don't intend to debate particulars of formatting
[18:13:11] <cradek> I'm just saying we all need to use cvs-friendly editors (or editors configured in a cvs-friendly way)
[18:13:12] <rayh> I guess we decided a while back that the way it was formatted by the first author was the way it remained?
[18:13:34] <rayh> I'll try to keep that in mind for future commits.
[18:13:39] <cradek> rayh: I tend to agree - I think mass reformatting is always bad.
[18:13:53] <cradek> rayh: (when using cvs)
[18:13:59] <rayh> It did make a mess the last time it was done.
[18:14:00] <alex_joni_> rayh: we have CodeStyle
[18:14:03] <alex_joni_> "Now, some people will claim that having 8-character indentations makes
[18:14:04] <alex_joni_> the code move too far to the right, and makes it hard to read on a
[18:14:04] <alex_joni_> 80-character terminal screen. Whilst the GNU style of 2-character
[18:14:04] <alex_joni_> indentations reduces the clarity. For EMC2, a compromise of 4-character
[18:14:04] <alex_joni_> indentation has been chosen. This still spreads the code out and causes
[18:14:04] <alex_joni_> lines to wrap round leading to difficulties in reading the sources. The
[18:14:06] <alex_joni_> answer to that is that if you need more than 3 levels of indentation, you're
[18:14:08] <alex_joni_> screwed anyway, and should fix your program.
[18:15:30] <alex_joni_> but that's under /src/, so it might not apply to tcl and scripts
[18:15:47] <rayh> tickle makes a pretty common 4-5 indent
[18:15:53] <rayh> at least the way I write it.
[18:15:59] <alex_joni_> cradek: btw, did you get a commit message about the ini files?
[18:16:03] <alex_joni_> * alex_joni_ didn't
[18:16:14] <cradek> alex_joni_: which?
[18:16:28] <alex_joni_> I reverted a lot of ini's on emc1
[18:16:34] <alex_joni_> they still had RUM stuff in them
[18:16:53] <cradek> rayh: it's my opinion that you can indent your new code any way you like, contrary to CodeStyle or not
[18:16:57] <rayh> Let's discuss config formats and see if we can reach consensus about a few issues.
[18:17:11] <cradek> alex_joni_: no, I didn't see those
[18:17:12] <alex_joni_> * alex_joni_ agrees
[18:17:16] <rayh> I'll switch kwrite to 4 here.
[18:17:34] <alex_joni_> cradek: strange, I didn't get those either, yet the commit is there, and there was a CIA message about it
[18:18:15] <cradek> let me check the email config
[18:19:23] <cradek> ^emc /cvsroot/sitedocs/CVSROOT/cvstools/syncmail -u %{sVv} emc-commit@lists.sourceforge.net
[18:19:34] <cradek> err
[18:19:41] <cradek> ^emc\/ /cvsroot/sitedocs/CVSROOT/cvstools/syncmail -u %{sVv} emc-commit@lists.sourceforge.net
[18:19:53] <cradek> those should still go to emc-commit
[18:20:03] <alex_joni_> right
[18:20:39] <alex_joni_> * alex_joni_ looks under administrative tasks
[18:21:16] <rayh> odd. kwrite was not setup to change on save.
[18:21:19] <alex_joni_> nope :(
[18:24:59] <cradek> rayh: what were you saying about config formats?
[18:25:31] <rayh> I'd like to see some standardization in the hal files
[18:25:42] <alex_joni_> example?
[18:25:43] <rayh> and how they relate to ini
[18:26:22] <rayh> I'd also like to see them startup with a minimum of hardware interface required
[18:26:53] <rayh> for example limit switch inputs should be set so that they don't prevent running.
[18:26:57] <alex_joni_> you are talking about common hal stuff or hardware specific halstuff?
[18:27:14] <alex_joni_> core_stepper vs. standard_pinout ?
[18:27:19] <rayh> I'm thinkinf of both.
[18:27:31] <rayh> and I can't type for crap.
[18:27:51] <cradek> if you get 90% of the letters write we can still read it fine
[18:28:06] <rayh> That may be asking a lot.
[18:28:28] <rayh> For the example servo systems.
[18:28:58] <rayh> I'd like to see them use about the same order of hal stuff.
[18:29:17] <rayh> across all the servo ones.
[18:29:44] <alex_joni_> maybe one way to do that is split stuff in smaller hal files
[18:29:59] <cradek> I have another idea too
[18:30:10] <alex_joni_> or maybe have more common stuff.. (I'm just thinking ideology, without looking at specifics now)
[18:30:16] <rayh> Right. in univstep i separated out the load and addf
[18:30:21] <alex_joni_> cradek: shoot
[18:30:23] <cradek> the sim has some differentiators to give signals xpos,xvel,xacc ... that can be seen in halscope
[18:30:37] <cradek> I think that's so useful it should be added to core-stepper and core-servo
[18:30:49] <rayh> right i did a similar thing in univstep but not complete
[18:31:01] <alex_joni_> right.. how about this:
[18:31:20] <alex_joni_> 1. have a common_emc (where all the motion specific stuff happens, axes, vels' acc's, etc)
[18:31:30] <alex_joni_> 2. next have either common_servo or stepper
[18:31:46] <alex_joni_> 3. next have aditional common files (to load PID, limits, whatever)
[18:32:00] <alex_joni_> 4. have specific HW hal's (templates)
[18:32:20] <alex_joni_> 5. have specific HW hal's (defined by the integrator)
[18:33:14] <cradek> yes, it would be nice if the code for stg limit switches was in stg-limit-switches.hal for instance
[18:33:28] <rayh> In univstep I added a 4th axis.
[18:33:34] <cradek> it would seem simpler to someone trying to find the right thing to edit
[18:34:16] <rayh> I had another idea that i got from halcmd save
[18:34:53] <rayh> if we make the load commands separate, we could easily configure all of the rest of hal from
[18:35:05] <rayh> a gui
[18:35:14] <alex_joni> ok, so load first
[18:35:21] <alex_joni> then connect
[18:35:23] <alex_joni> then tune ?
[18:35:31] <rayh> yes.
[18:35:57] <rayh> One problem with the save way is that the ini file is only going to be honored the first time around.
[18:38:35] <rayh> I like this approach
[18:38:37] <rayh> <alex_joni> ok, so load first
[18:38:38] <rayh> <alex_joni> then connect
[18:38:38] <rayh> <alex_joni> then tune ?
[18:38:38] <rayh> <rayh> yes.
[18:38:48] <alex_joni> thanks..
[18:38:50] <rayh> oops
[18:39:03] <alex_joni> I have a ssh client set up :)
[18:39:32] <ajoni> ajoni is now known as alex_joni_
[18:39:38] <alex_joni_> I hate it when this happens :(
[18:40:06] <rayh> proves you are supposed to be on holiday not on irc.
[18:40:08] <alex_joni> anyways, back to config
[18:40:14] <alex_joni> rayh: probably
[18:40:29] <alex_joni> but I'm not letting it defeat me :D
[18:40:35] <alex_joni> fighting back at all cost :P
[18:40:50] <rayh> that's the spirit.
[18:41:08] <alex_joni> I think that approach might be doable..
[18:41:21] <alex_joni> but it has the downside of splitting stuff in a lot of files
[18:41:30] <alex_joni> if we do them each in a differnet file
[18:42:00] <rayh> maybe separate sections of a single file.
[18:42:06] <rayh> after the core_xx
[18:42:37] <rayh> I guess I'm thinking of a written page that describes what a new integrator
[18:42:38] <alex_joni> right
[18:42:39] <SWP_Away> it would be nice to have a cross between a hal file and an ini file - a hal file with sections
[18:42:41] <SWP_Away> hi
[18:42:47] <rayh> will find when they open up a config.
[18:42:56] <alex_joni> hi Swampy
[18:43:16] <alex_joni> rayh: that's a must
[18:43:24] <alex_joni> we are lacking quite a bit of documentation
[18:43:39] <alex_joni> especially for the new stuff
[18:43:59] <rayh> If we had them all layed out the same a single description would do the job.
[18:44:18] <rayh> and that could be a part of Hal_Introduction.pdf
[18:44:39] <alex_joni> I think this goes beyond HAL_Introduction
[18:44:49] <alex_joni> or maybe the name is not perfectly fit for it
[18:45:22] <rayh> Right. much of the introduction is reference now.
[18:45:51] <alex_joni_> HAL_Introduction should stay HAL_Introduction
[18:45:56] <alex_joni_> the examples in there are nice
[18:46:10] <alex_joni_> but HAL_EMC_config stuff is a whole different story
[18:49:52] <rayh> phone
[18:50:10] <alex_joni_> ok.. I'm booting a linux, to work on the tcl stuff
[18:50:10] <alex_joni_> brb
[18:50:26] <alex_joni> my screen will be here ;)
[19:13:49] <alex_joni_> you still there guys?
[19:15:04] <rayh> yep
[19:17:43] <alex_joni_> ok.. just wondering, cause it's quiet
[19:26:17] <rayh> Okay. I'm back
[19:26:36] <alex_joni_> * alex_joni_ still busy on the setup stuff
[19:26:51] <alex_joni_> I gave up trying to translate "config" "quit" "run"
[19:27:39] <rayh> How about we build all of the configs to take advantage of core_xx
[19:27:55] <rayh> and then add on the additional stuff
[19:28:35] <rayh> If we added a load.hal as a first hal file it would allow either separate
[19:28:43] <rayh> file systems or the save notion.
[19:29:44] <alex_joni_> * alex_joni_ didn't get that (from the load.hal on)
[19:30:09] <rayh> load.hal would be first in the ini file list
[19:30:18] <rayh> then core_xx
[19:31:04] <rayh> Then the specific
[19:31:09] <rayh> * rayh looks back.
[19:31:47] <rayh> <alex_joni_> 1. have a common_emc (where all the motion specific stuff happens, axes, vels' acc's, etc)
[19:31:47] <rayh> <alex_joni_> 2. next have either common_servo or stepper
[19:31:48] <rayh> <alex_joni_> 3. next have aditional common files (to load PID, limits, whatever)
[19:31:48] <rayh> <alex_joni_> 4. have specific HW hal's (templates)
[19:31:50] <rayh> <alex_joni_> 5. have specific HW hal's (defined by the integrator)
[19:31:52] <rayh> <cradek> yes, it would be nice if the code for stg limit switches was in stg-limit-switches.hal for instance
[19:32:01] <rayh> I like this sort of layout.
[19:32:39] <rayh> under 3 there could be a core_bridgeport.hal
[19:34:58] <rayh> HAL is so flexible that there are many ways to handle it's config.
[19:38:39] <rayh> brb
[19:41:12] <alex_joni_> right
[19:50:08] <alex_joni_> gawd I hate this.. :(
[19:50:31] <alex_joni_> seems my bad fonts stuff affects de.msg, so I can't commit without trashing it :(
[19:54:31] <alex_joni_> alrighty.. that should do it
[19:54:48] <alex_joni_> I'll be back later guys
[20:19:53] <rayh> I put up a tarball www.linuxcnc.org/Dropbox/hal_saves.tgz that includes five files saved using the "halcmd save" command.
[20:20:35] <rayh> I find this format easier to read and understand that the separate files.