[14:09:08] <jepler> http://pastebin.ca/1006951
I found that you can export from lyx 1.5 to 1.3 right in the file menu.
sounds nice (if it works..)
I tried it with a little edit and it did work with our make.
how about a diff against CVS ?
I imagine if we tried some of the features of 5.3 we'd have issues.
Ah. I could try that.
my experience was that exporting to 1.3 from newer versions of lyx introduced a lot of whitespace changes, which made diffs useless.
Most of the diffs I've tried were totally changed.
wouldn't it be nice if diff hade some option like --whitespade-is-unimportant
err - whitespace
EMC: 03rayh 07TRUNK * 10emc2/docs/src/common/whatpc.png: Update simple emc2 flow chart
I thought it did.
Yea. I can commit again.
cvs diff -b
Maybe I was thinking of tkdiff or some other click thingie.
-b = Ignore trailing white space and consider all other sequences of one or more white space characters to be equivalent.
-B = Ignore changes that just insert or delete blank lines.
SWPadnos: it also has '--ignore-all-space, --ignore-blank-lines, --ignore-case, --initial-tab"
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.
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)
if you make changes to v2_2_branch (to the docs) those will only be seen in 2.2.6
I was thinking of changing the title page numbering for 2.3-pre for trunk.
Sounds like that should be okay.
heh, who wants to hear a funny story?
a friend of mine tried hardy on his laptop recently, and desktop effects didn't work at all
so I gave him the emc2 LiveCD to try, and with our CD it worked :)
I have no idea why..
ok, so I guess it's even score on laptops now :)
yeah, but I can't understand why ours would work, when the hardy one didn't
yeah, that is a puzzler :)
it didn't load the lrm from the hardy CD, same driver
hmmm. maybe you've made a newer liveCD that I should try
the last one is aj07
is that in the ISO filename?
ah, yes it is. I'll download that one and see if it works on my laptop
what didn't work last time?
I never got anything but a blank screen after the CD boot menu
I doubt it will make much difference then.. but lets hope ;)
did you try safe mode or CD test?
no keyboard lights, no video out, nothing
even CD check, and I think I even tried memtest
and stock works?
I verified the md5sum on both the iso image and using dd /dev/... | md5sum
git sure makes it easy to do something you didn't indend
* jepler just spent a good 20 minutes trying to put work he did on a branch onto the master
oh well, fixed now..
sounds like git is fun
hm now why isn't the v0.3 tag present on git.unpy.net?
do you remember what you did to fix it? (/me hints at a blog post or something :) )
me? I read the documentation over and over again, and sometimes typed things that I thought the documentation was indicating
oh, so it's the Homer Simpson method of troubleshooting? :)
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.
If i hadn't wanted a linear-looking history, I could have just used git-merge
oh, so it
it's more or less simple, as long as you're doing things the git way
SWPadnos: if you know what to type
but that's not really easy to remember..
that's always (part of) the problem
Display all 131 possibilities? (y or n)
N works as 'y'
incidentally, has anyone looked into what's needed for command-line option completion to work for halcmd? (or in general)
SWPadnos: I don't think that's interesting..
heh - from a programming perspective or as a user?
you could theoretically do that, but for all components (not just the ones loaded, like halcmd -kf does)
and if things change (new components, etc), you'll have to update it
and I *seriously* doubt you can do that in a distro-independent way
yeah. I don't know the mechanism - haven't had the gumption to look at all those completion scripts
and probably wouldn't understand them if I did
anyways.. I don't think it's important enough
one can always do halcmd -kf, and then completion works
(and does so properly)
jepler: did i ever send you english translations of the futurlec hardware? could I get a copy?
tom1: skunkworks got it for me, thanks
SWPadnos: do you mean completion in bash of commands starting 'halcmd'? because halcmd itself has had completion for quite awhile
it could be *better*
yes, it was the bash command line I was thinking of
jepler: I'm sure he meant bash
completion is shell-dependent more than distro-dependent (though distros have varying methods to read stuff into the shell at runtime as well)
when you ". emc-environment" under bash, you do get dirt-simple completion for halcmd (autocomplete .hal files) with this line:
complete -o dirnames -f -X '!*.hal' halrun halcmd
ok, I have seen that
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
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
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
except you can't, for kernel modules
if you need to run the program to get the completions ...
well, when a module loads it puts its pins/params/functs into the hal namespace
it's the load-time options you need
oh i see
for 2.6/rtai systems, 'modinfo' can provide a list of load-time options
EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/comp.g: allow component names to be specified e.g., loadrt and2 names=huey,duey,louie
EMC: 03compile-farm 07BDI-4.51 (188.8.131.52-rtai) * 10emc2head/: build FAILED ; see http://linuxcnc.org/compile_farm/emc2head_slot6_log.txt
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
* jepler scratches his head
it's because of the serport driver
it's not a singleton
but it has a count_function
I tested only on sim, must not have any like that..
I think it's a problem around line 462 in comp.g
(but I understand too little of this to actually fix it.. my first attempt failed..)
I think that else: should be changed in two cases, one for count_function one for everything else
yes that sounds right
hmm.. I might have a fix.. lets see if it compiles
I think I do; no need to keep working on it
jepler: if you commit, I can test
EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/comp.g: fix earlier compile error. document names= in manpage.
EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/comp.g: undef'ing each macro before defining it reduces unhelpful warnings
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
EMC: 03compile-farm 07BDI-4.51 (184.108.40.206-rtai) * 10emc2head/: build PASSED
whee that's fast
EMC: 03compile-farm 07Ubuntu 5.10 (breezy) realtime (2.6.12-magma) * 10emc2head/: build PASSED
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-05-04.txt