Back
[01:14:24] <jepler> hm there are still things in configure that use 'uname -r'
[01:15:05] <jepler> so you get a non-working build because realtime.conf did not find adeos.ko
[02:40:09] <jmkasunich> more CVS weirdness
[02:40:28] <jmkasunich> the farm checkouts are confused again, this time by .pot files
[03:01:06] <jmkasunich> cradek you there?
[04:03:04] <jmkasunich> notes for jepler tomorrow, regarding the farm slots that fail
[04:03:57] <jmkasunich> the failing slots are running xgettext version 0.14.1, which locks up (sits there using 99% of the CPU forever) while processing tcl.pot
[04:04:15] <jmkasunich> (see the last command in the build log for the actual xgettext invocation)
[04:04:50] <jmkasunich> two older slots running xgettext versions 0.10.35 and 0.10.38 both process the file, but emit a lot of warnings
[04:05:28] <jmkasunich> and ubuntu running xgettext version 0.14.5 processed it with no warnings and no lockup
[04:06:01] <jmkasunich> I'm gonna consult google about xgettext, but I really have no idea what it does
[04:18:02] <jmkasunich> well, I understand the CVS problem now
[04:18:12] <jmkasunich> make is modifying the .pot files
[04:18:21] <jmkasunich> that confuses CVS
[04:19:30] <jmkasunich> if the makefile considers the .pot files to be targets, then I don't think they should be in CVS
[19:09:57] <mkeller> hello guys
[19:10:09] <cradek> hi
[19:10:22] <SWPadnos> hi
[19:10:36] <mkeller> whats the official language of this channel? english or german?
[19:10:57] <cradek> english
[19:11:06] <mkeller> okay, thx.
[19:12:11] <mkeller> There's a little idea in my head, which I would like to ask you if the world really needs this or perhaps there's already some implementation of it somewhere out there which I don't know
[19:12:47] <cradek> I bet none of us knows the whole world but we'll try to advise you anyway
[19:12:59] <mkeller> do you know something like a CNC remote box, which is connected to the EMC PC via USB
[19:13:37] <mkeller> In this box there are some switches an one encoder with which you could control e.g the axis
[19:13:53] <cradek> a jogwheel?
[19:14:02] <mkeller> there could be a display showing the XYZ coordinates... stuff like this
[19:14:14] <mkeller> yes something like a Jogwheel
[19:14:29] <SWPadnos> as far as I know, there are no USB "pendants" for EMC
[19:14:45] <cradek> a jogwheel is already easy to hook up to any digital IO that emc supports (such as two parallel port pins)
[19:14:51] <cradek> a display readout has not been done as far as I know
[19:15:07] <SWPadnos> for the input side, EMC can use keypads and joysticks connected via USB. I don't know of any USB displays yet
[19:15:36] <mkeller> Okay
[19:15:40] <cradek> the jogwheel is actually read in realtime so putting it on the other end of USB might make it not work as nicely
[19:16:21] <mkeller> is there already a implementation of a jogwheel connected to parport in EMC?
[19:16:29] <cradek> emc2, yes
[19:16:36] <cradek> it works very well
[19:16:52] <mkeller> and how could one select the axis he tries to manipulate?
[19:17:15] <cradek> in the AXIS gui there is support for that (the jogwheel controls the axis selected onscreen)
[19:17:26] <mkeller> do I have to push the y x or z button on the keyboard an then turn the wheel?
[19:17:40] <cradek> mkeller: yes, or you could use hard buttons on the parallel port too.
[19:17:46] <cradek> err, instead
[19:17:59] <mkeller> ok, I see
[19:18:07] <cradek> a rotary switch for x/y/z would be a nice interface
[19:18:18] <cradek> it just takes some more inputs
[19:18:23] <cradek> you can configure it however you like
[19:18:25] <mkeller> now let me tell you what I thought about
[19:19:43] <mkeller> I thought about building a Box with three buttons X, Y and Z and one jogwheel. Iside of this box there would be a atmel microcontroller with USB stack. It connects to the PC as HID so it behaves like a simple Keyboard
[19:20:41] <cradek> I think the keyboard interface to jogging isn't sufficient for good control like a jogwheel can give
[19:20:48] <mkeller> hm
[19:21:35] <mkeller> so you think this would be too slow
[19:22:09] <mkeller> do you really think inputs have to happen in realtime?
[19:22:23] <cradek> well, it won't be very responsive, but the bigger problem is that the GUIs only let you jog continuously, or in a few increments
[19:22:45] <mkeller> which means?
[19:22:52] <cradek> yes, I wrote the jogwheel support outside realtime first, and it worked badly
[19:24:08] <mkeller> But how many people are happy with the cursor keys of their keyboard? I mean the USB HID Keyboard thing could be as responsive as a normal keyboard.
[19:24:14] <cradek> the way jogwheels work now is by updating in realtime the machine's "goal" position, and letting the motion controller get it to "goal" as fast as the machine constraints allow
[19:24:41] <mkeller> so it's "bypassing" the gui?
[19:24:48] <cradek> mkeller: you can't jog to a certain position with the cursor keys.
[19:25:30] <cradek> yes it's separate from the gui, the gui simply tracks the position
[19:26:15] <mkeller> the code you wrote for the jogwheel is somewhere in the src of emc2?
[19:26:24] <mkeller> I didn't have a look at it yet.
[19:26:38] <cradek> yes actually there are two ways to hook up a jogwheel - in halui (nonrealtime) and directly to the motion controller (realtime)
[19:26:49] <cradek> the realtime method works much better
[19:27:06] <mkeller> Okay.
[19:27:16] <cradek> your usb device could in theory hook to the halui jogwheel inputs
[19:28:04] <mkeller> okay. I will have a look at the code this night
[19:29:29] <mkeller> SWPadnos mentioned there are already USB devices. Where can I find information about these?
[19:30:07] <SWPadnos> they're just hoysticks and keypads - nothing special for EMC or machining
[19:30:17] <SWPadnos> s/hoysticks/joysticks/
[19:30:18] <jepler> mkeller: I'm not sure what he meant. The existing "hal_joystick" can talk to joysticks including USB joysticks
[19:30:26] <SWPadnos> that's what I meant
[19:31:36] <mkeller> okay thank you
[19:33:26] <mkeller> now, completely disaffected and disappointed of my great new invention I will leave this room... ;-)
[19:34:33] <mkeller> see you!
[23:13:00] <jmkasunich> jepler: you around?
[23:13:53] <jepler> jmkasunich: yes
[23:15:45] <jmkasunich> should the makefile be modifying the .pot files?
[23:15:58] <jmkasunich> and if so, should the .pot files be in CVS?
[23:16:15] <jepler> I'm not entirely sure what the right answer is
[23:16:44] <jepler> I took the view that like configure vs configure.in, .pot and .mo files are generated, but many people may not have the tools to generate them.
[23:16:50] <jmkasunich> I made a (somewhat arbitrary) decision when I wrote the compile farm scripts that if the local repository was modified, something must be fscked
[23:16:56] <jmkasunich> so now the farm won't run
[23:17:00] <jepler> hm
[23:17:21] <jmkasunich> I suppose I can just make the scripts ignore the modified files
[23:17:46] <jepler> the reality is that the files are perfectly up to date, but make doesn't know that since the timestamps are set by 'co'
[23:17:49] <jepler> or 'update'
[23:17:50] <jmkasunich> but every developer who goes to checkin something completely unrelated is gonna wind up checking in his very own version of the .pot files too
[23:18:38] <jepler> besides removing the files or changing the scripts, making a special 'potfiles' rule might be another alternative
[23:18:59] <jepler> the generated .pot files are still in CVS, but only updated on request, not by any 'make' when the timestamps don't match
[23:19:16] <jmkasunich> perhaps
[23:19:28] <jmkasunich> I see that its not just a case of datestamps
[23:19:42] <jmkasunich> the .pot files present after a build are _very_ different from those in CVS
[23:20:06] <jepler> usually running xgettext twice is idempotent, but that may not be true when they're different *versions* of gettext
[23:20:29] <jepler> the easiest thing to do is a 'potfiles' target
[23:21:07] <jepler> well, I dunno what's easiest. what's your gut tell you is the best option?
[23:21:29] <jmkasunich> I don't no nuttin about potfiles
[23:21:37] <jmkasunich> how likely are people _not_ to have the tools?
[23:22:06] <jepler> well, in the 'farm, I think only the ubuntu system has a working version of xgettext
[23:22:33] <jmkasunich> john@ke-main-ubuntu:~/emcdev/farm/emc2head$ cvs -q diff -u | grep ^+ | wc
[23:22:33] <jmkasunich> 105 233 2946
[23:22:33] <jmkasunich> john@ke-main-ubuntu:~/emcdev/farm/emc2head$ cvs -q diff -u | grep ^- | wc
[23:22:33] <jmkasunich> 936 2852 23288
[23:22:40] <jmkasunich> thats on my breezy box
[23:23:05] <jmkasunich> so even between what you committed (dapper?) and my breezy, running make changes the files a lot
[23:23:07] <jepler> in the real world, anybody can install a working package on their breezy or dapper system quickly
[23:23:28] <jepler> that would point towards not including the files
[23:24:40] <jmkasunich> that bug report you pointed at (xgettext), seemed to have a workaround (not just "don't use that version")
[23:24:44] <jmkasunich> lemme go look again
[23:25:14] <jmkasunich> > The tab before the 'z' seems to be relevant, without it xgettext completes
[23:25:14] <jmkasunich> > in a timely fashion.
[23:25:32] <jepler> the i18n process is: source files -> pot files -> msgmerge -> po files (also human-edited) -> mo files (or .msg files in the case of tcl)
[23:25:44] <jepler> the .pot files are never used by another rule, only by a human who runs msgmerge
[23:26:17] <jepler> so removing the .pot files also won't "break" the build if a system doesn't have xgettext
[23:26:25] <jepler> so .. remove 'em (at least for now)?
[23:26:35] <jmkasunich> remove from CVS? or the makefile?
[23:26:45] <jepler> from CVS
[23:27:03] <jepler> you only need the .pot files if you're doing translations, and then you need a working xgettext and msgmerge to work on it
[23:27:14] <jmkasunich> ok
[23:27:14] <jepler> so check for xgettext (already done) and take pot files out of CVS
[23:28:26] <jepler> what does CVS do if you have a modified file in your tree, and it's deleted on the server? This may still require manual cleanup (once) on the 'farm
[23:28:35] <jmkasunich> once is no problem
[23:28:49] <jmkasunich> I've done about 10 cleanups so far, trying to troubleshoot the problem
[23:29:07] <jmkasunich> (at first I thought it was one of those screwy "foo is in the way, move it" problems
[23:29:10] <jepler> what about .msg files, any problems there?
[23:29:20] <jmkasunich> not that I've seen
[23:29:38] <jmkasunich> john@ke-main-ubuntu:~/emcdev/farm/emc2head$ cat cvs_log
[23:29:38] <jmkasunich> ? build_log
[23:29:38] <jmkasunich> ? cvs_log
[23:29:38] <jmkasunich> ? farm_build
[23:29:38] <jmkasunich> ? history.log
[23:29:39] <jmkasunich> ? history_log
[23:29:41] <jmkasunich> P src/emc/usr_intf/axis/scripts/image-to-gcode.py
[23:29:43] <jmkasunich> M src/po/axis.pot
[23:29:45] <jmkasunich> M src/po/rs274_err.pot
[23:29:47] <jmkasunich> M src/po/tcl.pot
[23:29:49] <jmkasunich> CVS_SUCCESS
[23:29:51] <jmkasunich> thats why the farm cvs update returns
[23:30:03] <jmkasunich> (the SUCCESS tag is something the script throws in)
[23:30:20] <jepler> the files are now removed in CVS
[23:30:33] <jmkasunich> the script then greps looking for SUCCESS and "U" or "P" to decide if a build is needed
[23:30:46] <jmkasunich> "M" or "C" make it complain
[23:31:27] <jmkasunich> cvs update: conflict: src/po/axis.pot is modified but no longer in the repository
[23:31:27] <jmkasunich> C src/po/axis.pot
[23:31:34] <jmkasunich> yep, manual cleanup needed
[23:31:35] <jmkasunich> but easy
[23:31:40] <jmkasunich> thanks
[23:31:59] <jepler> I hope all the slots compile now
[23:32:01] <jepler> if not, let me know
[23:32:58] <jmkasunich> they should
[23:33:06] <jmkasunich> and I will
[23:37:03] <jepler> * jepler gets back to adding entry cuts to image-to-gcode