hm there are still things in configure that use 'uname -r'
so you get a non-working build because realtime.conf did not find adeos.ko
more CVS weirdness
the farm checkouts are confused again, this time by .pot files
cradek you there?
notes for jepler tomorrow, regarding the farm slots that fail
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
(see the last command in the build log for the actual xgettext invocation)
two older slots running xgettext versions 0.10.35 and 0.10.38 both process the file, but emit a lot of warnings
and ubuntu running xgettext version 0.14.5 processed it with no warnings and no lockup
I'm gonna consult google about xgettext, but I really have no idea what it does
well, I understand the CVS problem now
make is modifying the .pot files
that confuses CVS
if the makefile considers the .pot files to be targets, then I don't think they should be in CVS
whats the official language of this channel? english or german?
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
I bet none of us knows the whole world but we'll try to advise you anyway
do you know something like a CNC remote box, which is connected to the EMC PC via USB
In this box there are some switches an one encoder with which you could control e.g the axis
there could be a display showing the XYZ coordinates... stuff like this
yes something like a Jogwheel
as far as I know, there are no USB "pendants" for EMC
a jogwheel is already easy to hook up to any digital IO that emc supports (such as two parallel port pins)
a display readout has not been done as far as I know
for the input side, EMC can use keypads and joysticks connected via USB. I don't know of any USB displays yet
the jogwheel is actually read in realtime so putting it on the other end of USB might make it not work as nicely
is there already a implementation of a jogwheel connected to parport in EMC?
it works very well
and how could one select the axis he tries to manipulate?
in the AXIS gui there is support for that (the jogwheel controls the axis selected onscreen)
do I have to push the y x or z button on the keyboard an then turn the wheel?
mkeller: yes, or you could use hard buttons on the parallel port too.
ok, I see
a rotary switch for x/y/z would be a nice interface
it just takes some more inputs
you can configure it however you like
now let me tell you what I thought about
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
I think the keyboard interface to jogging isn't sufficient for good control like a jogwheel can give
so you think this would be too slow
do you really think inputs have to happen in realtime?
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
yes, I wrote the jogwheel support outside realtime first, and it worked badly
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.
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
so it's "bypassing" the gui?
mkeller: you can't jog to a certain position with the cursor keys.
yes it's separate from the gui, the gui simply tracks the position
the code you wrote for the jogwheel is somewhere in the src of emc2?
I didn't have a look at it yet.
yes actually there are two ways to hook up a jogwheel - in halui (nonrealtime) and directly to the motion controller (realtime)
the realtime method works much better
your usb device could in theory hook to the halui jogwheel inputs
okay. I will have a look at the code this night
SWPadnos mentioned there are already USB devices. Where can I find information about these?
they're just hoysticks and keypads - nothing special for EMC or machining
mkeller: I'm not sure what he meant. The existing "hal_joystick" can talk to joysticks including USB joysticks
that's what I meant
okay thank you
now, completely disaffected and disappointed of my great new invention I will leave this room... ;-)
jepler: you around?
should the makefile be modifying the .pot files?
and if so, should the .pot files be in CVS?
I'm not entirely sure what the right answer is
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.
I made a (somewhat arbitrary) decision when I wrote the compile farm scripts that if the local repository was modified, something must be fscked
so now the farm won't run
I suppose I can just make the scripts ignore the modified files
the reality is that the files are perfectly up to date, but make doesn't know that since the timestamps are set by 'co'
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
besides removing the files or changing the scripts, making a special 'potfiles' rule might be another alternative
the generated .pot files are still in CVS, but only updated on request, not by any 'make' when the timestamps don't match
I see that its not just a case of datestamps
the .pot files present after a build are _very_ different from those in CVS
usually running xgettext twice is idempotent, but that may not be true when they're different *versions* of gettext
the easiest thing to do is a 'potfiles' target
well, I dunno what's easiest. what's your gut tell you is the best option?
I don't no nuttin about potfiles
how likely are people _not_ to have the tools?
well, in the 'farm, I think only the ubuntu system has a working version of xgettext
john@ke-main-ubuntu:~/emcdev/farm/emc2head$ cvs -q diff -u | grep ^+ | wc
105 233 2946
john@ke-main-ubuntu:~/emcdev/farm/emc2head$ cvs -q diff -u | grep ^- | wc
936 2852 23288
thats on my breezy box
so even between what you committed (dapper?) and my breezy, running make changes the files a lot
in the real world, anybody can install a working package on their breezy or dapper system quickly
that would point towards not including the files
that bug report you pointed at (xgettext), seemed to have a workaround (not just "don't use that version")
lemme go look again
> The tab before the 'z' seems to be relevant, without it xgettext completes
> in a timely fashion.
the i18n process is: source files -> pot files -> msgmerge -> po files (also human-edited) -> mo files (or .msg files in the case of tcl)
the .pot files are never used by another rule, only by a human who runs msgmerge
so removing the .pot files also won't "break" the build if a system doesn't have xgettext
so .. remove 'em (at least for now)?
remove from CVS? or the makefile?
you only need the .pot files if you're doing translations, and then you need a working xgettext and msgmerge to work on it
so check for xgettext (already done) and take pot files out of CVS
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
once is no problem
I've done about 10 cleanups so far, trying to troubleshoot the problem
(at first I thought it was one of those screwy "foo is in the way, move it" problems
what about .msg files, any problems there?
not that I've seen
john@ke-main-ubuntu:~/emcdev/farm/emc2head$ cat cvs_log
thats why the farm cvs update returns
(the SUCCESS tag is something the script throws in)
the files are now removed in CVS
the script then greps looking for SUCCESS and "U" or "P" to decide if a build is needed
"M" or "C" make it complain
cvs update: conflict: src/po/axis.pot is modified but no longer in the repository
yep, manual cleanup needed
I hope all the slots compile now
if not, let me know
and I will
* jepler gets back to adding entry cuts to image-to-gcode