for consideration to eliminate a confusing message: http://www.panix.com/~dgarrett/stuff/0001-emc.in-eliminate-message-to-DEBUG_FILE-for-nonexiste.patch
for consideration: http://www.panix.com/~dgarrett/stuff/0001-integ-add-gain-pin.patch
(analog computer integrators always had a gain pot)
I was going through the examples on the "git" page in the wiki, and under "3. View History", I could not get this one to work: Get a closer look at a particular change by commit: git log -C -p -1 57c609
It says: fatal: ambiguous argument '57c609': unknown revision or path not in the working
Use '--' to separate paths from revisions
Am I doing something wrong? Any advice appreciated.
(I just copied and pasted the example)
maybe there are two changes that could be identified by 57c609
OK, thanks, SWP, I'll work on that awhile and see how far I get.
jepler: I'm back if you have any questions about that Modbus patch .. sorry I had to run off.. kid commitment..
I put those Modbus changes into the latest version of ClassicLadder and they work well there also.. I think I will fix the Modbus config menu the author broke and send him a patch file.. or have Chris do it as I think he has his personal contact info.
I'd like to incorporate the CL editor, which is in the latest version of CL, into EMC. But I am not sure which makes more sense; adapt the latest CL version to EMC, or modify the current version of CL which is in EMC?
Does it matter from a license standpoint? Perhaps by running some diffs I can determine the best approach?
Dave911: you should do whatever you think is most likely to be successful - it sounds like you are the best one to decide.
OK.. I guess there is no license issues either way since the code can be modified at will.. right?
I haven't checked licensing but I heard someone here say they were compatible
Yep... CL is LGPL version 2.1
what does this error mean when I do a git pull "fatal: Entry 'docs/src/gcode/main.lyx' not uptodate. Cannot merge."
JT-Dev: you have changes in that file that aren't committed (and maybe that the file is also changed in what you just pulled). commit your changes then pull
I did comment to gcode/main.lyx recently to restore the NURBS docs
I'm getting all kinds of errors now with git pull... but time to get ready for work now
Hi JT-Work, did you get the packages to install?
no, I had to reload 10.04 this morning it hosed up my video output somehow so all I had was vertical lines
rob got his to work but he downloaded all of the debs and I missed one
Ok, I see.
I'll try again this evening if I get time
for consideration: http://www.panix.com/~dgarrett/stuff/0001-emc.in-eliminate-message-to-DEBUG_FILE-for-nonexiste.patch
hmph! .. I distinctly remember writing GetFromIniDefault and using it for [EMC]NML_FILE but I see that it's not on linuxcnc.org.
I wonder where I lost it
EMC: 03jepler 07v2.4_branch * r8db75d8ab739 10/scripts/emc.in: emc.in: eliminate message for nonexistent [EMC]NML_FILE
anyone else have a thought on putting integrator gain on v2.4_branch? It looks so safe..
the analog computers i remember always had a gain pot on the operational amplifier integrators:-D
I assume you have a use for it personally as well
EMC: 03jepler 07v2.4_branch * r427d780dd0f3 10/src/hal/components/integ.comp: integ: add gain pin
doesn't help on 10.04 rtai
micges: change hard to -
try running "ulimit -Sl 20480" in a terminal and you shouldn't have to reboot...
mozmck_work1: thanks I'll test it tomorrow
mozmck_work1: your packages works fine, no grub issues
mozmck_work1: one thing I've been meaning to talk to you about
I think we (as in you) should rename the kernel built to have a way bigger version number in the name
instead of 22.214.171.124-rtai make it 126.96.36.199-rtai or something like that
I think that will cause grub to always put it first in the list, even if the user upgrade the regular kernels
jepler: Just say how you REALLY feel =)
ok, should I or not then :)
jepler: I know.. but there were soo many people bitten by that with the 8.04 package
mozmck_work1: Unless jepler comes up with a better solution, I'd go with alex_joni's suggestion.
you even added an extra emc2 test for the running kernel vs. compiled
If you install startup-manager you can select the default kernel
yes, when a user encounters this problem just insult him until he leaves and uses different software instead.
Jymmm: you *said* to say how I really feel
jepler: Hey, isn't that the SOP for the last 5+ years?
heh. then there will be less users to have to support right? :)
mozmck_work1: Well, how's that for a, errr, um, "solution"?
more users who are worth supporting :P
I think there is an easy way to set the default kernel in some file. I'll check on that.
Not saying that I won't make the version number higher, just that there may be another option to consider...
mozmck_work1: independent on grub1/2/lilo/whatever ?
if there's another option to consider I'm all for it
uh, probably not. so dump my idea :)
the version number is really a hack, and I'm all for a better solution
just instruct the user to uninstall the other kernels
people who need both and want to switch between them can handle it
what if you have a link to latest -rtai kernel and put it permanently into grub.conf at first place?
that means messing with grub.conf which is yucky
memcheck does that as I understand...
add one more file into /etc/grub.d/ with 09_ prefix :)
if the grub2 "problem" is gone, then I have no problem with doing something that only works for the default bootloader
jepler, is it solved by removing plymouth altogether?
aystarik: mozmck told me that some update made grub2 start working reliably with rtai kernels on his systems
I haven't kept track of the details
I've tried server + gnome core, had not seen any issue too
plymouth is a dependency of mountall, which was updated recently. The computer here which had the worst booting problems seems to have been fixed. I need to test it on some other machines.
You can't uninstall plymouth without uninstalling just about everything else.
for example, removing it wants to remove telnet (!?)
so I dunno what plymouth is, but they've sure decided we WILL have it
Description: graphical boot animation and logger - main package
:) It wants to remove the whole gnome desktop, xorg server, etc etc...
it's the thing that makes it so you can't see the boot messages
actually, it does more than that apparently. can't remember what but it's part of the fast boot stuff.
ok, on a server I have 'plymouth-theme-ubuntu-text', which might make everyone happy...
does that make the boot process look like Linux circa 1995?
* jepler doesn't want people to think he's using a mac or something
no, it is a black screen for about 5 sec, then X starts.
it boots to full X under 13 sec..
BIOS screen stays longer :)
Plymouth isn't really designed to be built from source by end users.
... Plymouth isn't done yet. It's still under active development and isn't ready for distros to use as-is.
thank you mark shingleroof