Back
[14:09:08] <jepler> http://pastebin.ca/1006951 (diff
http://pastebin.ca/1006952)
[14:25:06] <alex_joni> whee
[14:33:27] <rayh> Hi alex_joni
[14:33:37] <alex_joni> hey ray
[14:34:22] <rayh> I found that you can export from lyx 1.5 to 1.3 right in the file menu.
[14:34:48] <alex_joni> sounds nice (if it works..)
[14:36:16] <rayh> I tried it with a little edit and it did work with our make.
[14:36:37] <alex_joni> how about a diff against CVS ?
[14:36:40] <rayh> I imagine if we tried some of the features of 5.3 we'd have issues.
[14:36:50] <rayh> Ah. I could try that.
[14:37:37] <jepler> my experience was that exporting to 1.3 from newer versions of lyx introduced a lot of whitespace changes, which made diffs useless.
[14:39:08] <rayh> Most of the diffs I've tried were totally changed.
[14:39:16] <alex_joni> crap
[14:46:07] <SWPadnos> wouldn't it be nice if diff hade some option like --whitespade-is-unimportant
[14:46:13] <SWPadnos> err - whitespace
[14:46:46] <CIA-31> EMC: 03rayh 07TRUNK * 10emc2/docs/src/common/whatpc.png: Update simple emc2 flow chart
[14:46:50] <rayh> I thought it did.
[14:47:06] <rayh> Yea. I can commit again.
[14:47:39] <fenn> diff -w
[14:47:42] <alex_joni> cvs diff -b
[14:47:47] <rayh> Maybe I was thinking of tkdiff or some other click thingie.
[14:47:56] <alex_joni> maybe -bB
[14:48:12] <alex_joni> -b = Ignore trailing white space and consider all other sequences of one or more white space characters to be equivalent.
[14:48:27] <alex_joni> -B = Ignore changes that just insert or delete blank lines.
[14:49:32] <alex_joni> SWPadnos: it also has '--ignore-all-space, --ignore-blank-lines, --ignore-case, --initial-tab"
[14:50:40] <rayh> Are the docs tagged with release branches so if we make changes now it won't be reflected back when someone builds an earlier version.
[14:51:54] <alex_joni> rayh: I think the answer is yes.. (when you checkout a 2.2.5 release, you get the docs that were valid at that point)
[14:52:13] <alex_joni> if you make changes to v2_2_branch (to the docs) those will only be seen in 2.2.6
[14:52:47] <rayh> I was thinking of changing the title page numbering for 2.3-pre for trunk.
[14:53:35] <rayh> Sounds like that should be okay.
[14:57:22] <alex_joni> rayh: sure
[15:17:20] <alex_joni> heh, who wants to hear a funny story?
[15:17:38] <SWPadnos> me, me
[15:17:40] <alex_joni> a friend of mine tried hardy on his laptop recently, and desktop effects didn't work at all
[15:18:01] <alex_joni> so I gave him the emc2 LiveCD to try, and with our CD it worked :)
[15:18:10] <alex_joni> I have no idea why..
[15:18:17] <SWPadnos> ok, so I guess it's even score on laptops now :)
[15:18:41] <alex_joni> yeah, but I can't understand why ours would work, when the hardy one didn't
[15:18:56] <SWPadnos> yeah, that is a puzzler :)
[15:19:12] <alex_joni> it didn't load the lrm from the hardy CD, same driver
[15:19:14] <SWPadnos> hmmm. maybe you've made a newer liveCD that I should try
[15:19:35] <alex_joni> the last one is aj07
[15:19:40] <SWPadnos> ok
[15:20:03] <SWPadnos> is that in the ISO filename?
[15:20:40] <alex_joni> yeah
[15:20:47] <SWPadnos> ah, yes it is. I'll download that one and see if it works on my laptop
[15:21:07] <alex_joni> what didn't work last time?
[15:21:26] <SWPadnos> booting
[15:21:40] <SWPadnos> I never got anything but a blank screen after the CD boot menu
[15:21:44] <alex_joni> I doubt it will make much difference then.. but lets hope ;)
[15:21:55] <alex_joni> did you try safe mode or CD test?
[15:21:56] <SWPadnos> no keyboard lights, no video out, nothing
[15:22:00] <SWPadnos> anything
[15:22:16] <SWPadnos> even CD check, and I think I even tried memtest
[15:22:28] <alex_joni> and stock works?
[15:22:31] <SWPadnos> yes
[15:22:56] <SWPadnos> I verified the md5sum on both the iso image and using dd /dev/... | md5sum
[15:23:19] <jepler> git sure makes it easy to do something you didn't indend
[15:23:27] <SWPadnos> heh
[15:23:38] <jepler> * jepler just spent a good 20 minutes trying to put work he did on a branch onto the master
[15:24:14] <jepler> oh well, fixed now..
[15:24:24] <alex_joni> sounds like git is fun
[15:24:48] <jepler> hm now why isn't the v0.3 tag present on git.unpy.net?
[15:24:51] <SWPadnos> do you remember what you did to fix it? (/me hints at a blog post or something :) )
[15:25:48] <jepler> me? I read the documentation over and over again, and sometimes typed things that I thought the documentation was indicating
[15:26:14] <SWPadnos> oh, so it's the Homer Simpson method of troubleshooting? :)
[15:26:36] <jepler> ultimately I ended up doing git-rebase + git-merge. the first turns what was a branch into some commits on top of master, then the second moves master forward to that commit.
[15:27:06] <jepler> If i hadn't wanted a linear-looking history, I could have just used git-merge
[15:28:27] <SWPadnos> oh, so it
[15:28:37] <SWPadnos> it's more or less simple, as long as you're doing things the git way
[15:29:20] <alex_joni> SWPadnos: if you know what to type
[15:29:27] <SWPadnos> heh
[15:29:34] <alex_joni> but that's not really easy to remember..
[15:29:37] <SWPadnos> that's always (part of) the problem
[15:29:46] <alex_joni> juve@hardy:~$ git<tab><tab>
[15:29:54] <alex_joni> Display all 131 possibilities? (y or n)
[15:29:59] <SWPadnos> N
[15:30:10] <alex_joni> N works as 'y'
[15:30:11] <alex_joni> :P
[15:30:23] <SWPadnos> heh
[15:32:30] <SWPadnos> incidentally, has anyone looked into what's needed for command-line option completion to work for halcmd? (or in general)
[15:33:49] <alex_joni> SWPadnos: I don't think that's interesting..
[15:34:07] <SWPadnos> heh - from a programming perspective or as a user?
[15:34:07] <alex_joni> you could theoretically do that, but for all components (not just the ones loaded, like halcmd -kf does)
[15:34:27] <alex_joni> and if things change (new components, etc), you'll have to update it
[15:34:44] <alex_joni> and I *seriously* doubt you can do that in a distro-independent way
[15:34:53] <SWPadnos> yeah. I don't know the mechanism - haven't had the gumption to look at all those completion scripts
[15:35:20] <SWPadnos> and probably wouldn't understand them if I did
[15:35:47] <alex_joni> anyways.. I don't think it's important enough
[15:35:58] <alex_joni> one can always do halcmd -kf, and then completion works
[15:36:04] <SWPadnos> sure
[15:36:07] <alex_joni> (and does so properly)
[15:36:13] <jmkasunich> agreed
[15:37:05] <alex_joni> hi jmkasunich
[15:37:09] <tom1> jepler: did i ever send you english translations of the futurlec hardware? could I get a copy?
[15:38:48] <jepler> tom1: skunkworks got it for me, thanks
[15:39:23] <jepler> SWPadnos: do you mean completion in bash of commands starting 'halcmd'? because halcmd itself has had completion for quite awhile
[15:39:26] <jepler> it could be *better*
[15:39:39] <SWPadnos> yes, it was the bash command line I was thinking of
[15:39:42] <alex_joni> jepler: I'm sure he meant bash
[15:39:58] <jepler> completion is shell-dependent more than distro-dependent (though distros have varying methods to read stuff into the shell at runtime as well)
[15:40:34] <jepler> when you ". emc-environment" under bash, you do get dirt-simple completion for halcmd (autocomplete .hal files) with this line:
[15:40:38] <jepler> complete -o dirnames -f -X '!*.hal' halrun halcmd
[15:41:04] <SWPadnos> ok, I have seen that
[15:41:08] <SWPadnos> I think
[15:42:03] <SWPadnos> it seems that a static list of options and commands (-k, show ...) shouldn't be too hard. Extending that to include all the knowledge about where modules come from etc. is another story
[15:42:03] <jepler> bash has an option to call an external program to get completions. so the route to completing halcmd in bash would be to change halcmd so that it has a new mode: propose a completion for this partial command, which uses the current internal completion code to do so
[15:48:01] <fenn> it makes sense to auto-complete the names of modules that can be loaded, and once they're loaded you can get completions from the module
[15:48:56] <SWPadnos> except you can't, for kernel modules
[15:49:10] <SWPadnos> if you need to run the program to get the completions ...
[15:49:13] <fenn> well, when a module loads it puts its pins/params/functs into the hal namespace
[15:49:24] <SWPadnos> it's the load-time options you need
[15:49:30] <fenn> oh i see
[15:49:53] <jepler> for 2.6/rtai systems, 'modinfo' can provide a list of load-time options
[15:50:56] <SWPadnos> cool
[16:14:50] <CIA-31> EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/comp.g: allow component names to be specified e.g., loadrt and2 names=huey,duey,louie
[16:19:24] <CIA-31> EMC: 03compile-farm 07BDI-4.51 (2.6.16.20-rtai) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot6_log.txt
[16:19:42] <CIA-31> EMC: 03compile-farm 07Ubuntu 5.10 (breezy) realtime (2.6.12-magma) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot2_log.txt
[16:52:33] <jepler> * jepler scratches his head
[16:53:00] <alex_joni> it's because of the serport driver
[16:53:04] <alex_joni> it's not a singleton
[16:53:14] <alex_joni> but it has a count_function
[16:53:33] <jepler> ah
[16:53:38] <jepler> I tested only on sim, must not have any like that..
[16:53:38] <alex_joni> I think it's a problem around line 462 in comp.g
[16:54:12] <alex_joni> (but I understand too little of this to actually fix it.. my first attempt failed..)
[16:54:46] <alex_joni> I think that else: should be changed in two cases, one for count_function one for everything else
[16:56:28] <jepler> yes that sounds right
[16:57:18] <alex_joni> hmm.. I might have a fix.. lets see if it compiles
[16:57:25] <alex_joni> yuck.. nope
[16:57:51] <jepler> I think I do; no need to keep working on it
[16:58:10] <alex_joni> ok
[17:00:06] <alex_joni> jepler: if you commit, I can test
[17:04:26] <CIA-31> EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/comp.g: fix earlier compile error. document names= in manpage.
[17:05:10] <CIA-31> EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/comp.g: undef'ing each macro before defining it reduces unhelpful warnings
[17:05:41] <CIA-31> EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/ (4 files): halcmd -c "start of command" produces completion like inside halcmd. in theory this can be used to improve bash completion of halcmd
[17:06:22] <CIA-31> EMC: 03compile-farm 07BDI-4.51 (2.6.16.20-rtai) * 10emc2head/: build PASSED
[17:06:32] <alex_joni> whee that's fast
[17:07:16] <CIA-31> EMC: 03compile-farm 07Ubuntu 5.10 (breezy) realtime (2.6.12-magma) * 10emc2head/: build PASSED
[21:29:42] <skunkworks> logger_dev:bookmark
[21:29:42] <skunkworks> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-05-04.txt