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