I have a patch for the Makefile which puts emc.so in the correct directory when doing "make install"
it also does setuid on pci_write and pci_read from "make install"
where should I send it?
patches are always welcome on the devel list - then whoever knows that area of the code can handle it.
ok. I'm not used to making patches, but I think it's correct. I'll send it in.
pretty much, "cvs diff -u" is all you need to know
but I also like to look through it and make sure there isn't something included that I didn't intend
didn't know that! I made a copy of Makefile and did a diff -c Makefile.orig Makefile
that works too, but cvs makes it easier
so does it compare to cvs on the web? or do I have to make a working copy of the code?
yes it compares online to the original version you got from cvs
so you don't have to keep track of original copies manually
ok, I'll try and remember that.
does git do something similar?
yes, and it's even smarter
also, with git can you download the latest code like you do with cvs and start developing from there, or do you have to get the whole history?
btw, here are a few instructions about patch submission: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CVS#Patch_Submission
mozmck: you can get either the whole history or you can get just recent history if you want that
there's a git web interface too, and you can get it that way, like now with cvsweb
ok. I don't know what I'd want the whole thing for.
it's not much bigger and is nice to have...
but either way you can get what you want.
I thought it would be quite a bit larger. If it's not then it doesn't much matter...
I think it's less than twice as large
here's a link to my patch: http://www.pastebin.ca/1450326
I can send it to the dev list as well.
I have emc running now on 9.04 with linux 18.104.22.168 and rtai 3.7. I'm learning stuff...
studying your patch...
I think your patch is right, but in investigating it, I notice that we now have an emc.so for python and an emc.so for tcl. It's technically OK because they are always in different directories, but I wonder whether that's what jepler really meant to do.
I don't know...
should I send the patch to the dev list or is that good enough?
I am working on committing it now, so don't bother sending it
do you want your real name in the commit message? We like to give credit.
that's fine, I don't care either way
sorry, I forget your last name...?
EMC: 03cradek 07TRUNK * 10emc2/src/Makefile: This fixes a few make-install problems. Thanks to Moses McKnight for the patch.
thanks! Another thing that I might work on is making it install the menu items. Shouldn't be too hard..
hm, I'm not sure that belongs. Those are "extras" that are added to the package. It seems best to keep OS-specific stuff out of make-install and in the particular OS-specific package.
or at least that's the idea behind the current setup.
makes sense for those not running axis
you mean the gnome menu stuff right?
maybe a separate "make install-menus"?
it's still problematic because the system may have something very different from gnome
or like my machine in the shop I'm running xubuntu with xfce because it's a much smaller footprint
in many cases you have to do something machine-specific about menus or startup icons
I think gnome/kde are getting better at sharing their schemes, but those are the only two
yeah. I was just thinking about ways to make it easier for someone to install everything from source
if it's a "supported" (I hate that term) OS/version, it's very easy to make a deb package and install that
you get the benefit of easy uninstall/updating too
it's not bad as it is.
I need to learn to make debs
it doesn't look too hard, I've just never had to do it.
it's not hard if the package has it set up right
with emc2 it's two commands: ./configure in the debian directory, then back up at the top level, debuild
I'm getting the following error trying to run stepconf:
File "/usr/local/bin/stepconf", line 2154, in <module>
app = App()
File "/usr/local/bin/stepconf", line 1141, in __init__
self.watermark = gtk.gdk.pixbuf_new_from_file(wizard)
GError: Failed to open file '/usr/local/bin/../emc2-wizard.gif': No such file or directory
yuck, that doesn't look like a correct path to find the image
(thanks for finding all the make-install problems for us...)
no, but the code looks like it should be pointing to /usr/local/share/emc
looks like it tries several paths
I think I agree the first one will be /usr/local/bin/../share/emc/emc2-wizard.gif
yes, and defaults to ../emc2-wizard.gif
second one is completely bogus - we never install there now
so does /usr/local/bin/../share/emc/emc2-wizard.gif exist?
no. maybe another install problem...
I should get to bed - thanks again for your work
me too. I think I can fix this pretty easily as well.
alex_joni: any comments for doing this?
when something is DEPRECATED when will it actually be removed?
skunkworks: like what?
[15:37:21] <skunkworks> http://linuxcnc.org/docs/2.3/html/man/man9/counter.9.html
EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: Make signal name combobox display with three rows instead of one. Looks way better. Hope nobody minds
skunkworks: IIRC this is deprecated in 2.3 and will be removed in 2.4, not earlier
if something is deprecated in all 2.x versions then it may be removed in 2.(x+1). often it's not re\moved until it's a problem for some other reason.
and we've violated that rule a few times -- for instance with some of the transitional hostmot2-related drivers that I don't think were ever really used
jepler: counter is replaced by encoder ?
so counter is still in 2.3?
(I assume so if it is still in the 2.3 docs)
will be in 2.3
you can probably check as easily as me
there will be a short cvs downtime later today for a required reboot.
jepler: in the early days emc had axes XYZRPW ?
micges: I think that change is not that bad
common coding practice says to use functions when things get longer than 2 screens or so
but I also notice you rewrote it somehow, maybe doing it in 2 steps is even better
cvs will be back in a few minutes
.. cvs should be back
alex_joni: in the early days emc had axes XYZRPW ?
XYZABC and UVW were in the language spec
EMC: 03micges 07TRUNK * 10emc2/src/emc/task/emctaskmain.cc: extract readahead code from emcTaskPlan() into sepearate functions
micges: I saw references to RPW in the ini's only
I don't think that the interpreter ever read RPW, and it never did UVW, we added that for emc2 only
alex_joni: I also saw that references
can't be g-code words though
P is used for G04 for example
R is radius for G02/03
a very old (emc1) checkin says this:
* trivkins maps A to joint 3, b to joint 4, c to joint 5, genhexkins
maps A to roll, B to pitch and C to Yaw, and modifies all the joint angles, strut/cable lengths accordingly.
so there is bogus code iniTraj.cc with R P W references
surely bogus ;)
you mean initraj.cc?
HOME <float> ... world coords of home, in X Y Z R P W
yes, I think HOME is in X Y Z A B C U V W
oh, I see that it's not as I suggested
though neither am I confident what that code is doing
* alex_joni already rewrote 90% of that part
its setup world home used in KINEMATICS_BOTH , but thats all I've traced
micges: I'm not sure it's worth cleaning this one thing up
it's probably more important to rethink/write the whole init process
I'm not saing that this must be cleaned
it's surely a bug/bogus thing to have RPW there
alex_joni: and I remember that ini whole thing must be rewrite
just pointing this out
cradek: a minor note: I notice some changes which are on branch "joints_axes" aren't on "joints_axes2"
[19:44:31] <alex_joni> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/ini/?only_with_tag=joints_axes
hopefully this will get lots better with git
alex_joni: that url doesn't tell me anything
alex_joni: (those old branches make me sad)
cradek: there are some files added only on that branch
but it's not that important
jepler: even if Q=0 in G64 mode , while executing gcode line are sometimes buffered in chained_points
(so Naivecam is still working in some way)
do they ever buffer more than one deep?
EMC: 03micges 07TRUNK * 10emc2/src/emc/task/emctaskmain.cc: cleanup interpreter readahead functions
good night all
yes; "no naive cam" mode is simply a mode where no segments are suitable to combine. that means that one move will still go in the buffer.
EMC: 03cmorley 07TRUNK * 10emc2/tcl/bin/halshow.tcl:
EMC: Fix the watch display - scientific notation
EMC: over wrote the signal name - as noted by John T