Running machinetalk-preview-2

[pascal...@gmail.com]

Hey Michael, all,

I built your 'machinetalk-preview-[2,3]' branchs today. But when I try to start afterwards, I get:

halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

does this sound familiar to anyone?

regards
pascal

[Michael Haberler]

yes, have a look at /var/log/linuxcnc.log - it will even tell you which command you skipped ;)

it's a missing 'sudo make setuid'

tongue out of cheek - I need to look into doing a better diagnostic message for this - it is simply rtapi_app failed to start for some reason

btw I suggest to pull machinetalk-preview-3 again in about an hour - I've been working lots on cleanups and the remote Web HAL UI demos which now actually do work - a remote HAL component, a HAL group demo, and a log reader test

this is now fully in sync with what Alex uses for development - for QtQuickVCP and the preview capablities he's working on since a while

shouldnt be far away from a merge now

- Michael


>
> regards
> pascal
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.

[Michael Haberler]

Am 07.08.2014 um 18:59 schrieb Michael Haberler <mai...@mah.priv.at>:

>
> Am 07.08.2014 um 18:22 schrieb pascal...@gmail.com:
>
>> Hey Michael, all,
>>
>> I built your 'machinetalk-preview-[2,3]' branchs today. But when I try to start afterwards, I get:
>>
>> halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout
>>
>> does this sound familiar to anyone?

> I need to look into doing a better diagnostic message for this - it is simply rtapi_app failed to start for some reason

the error message looks a tad less counterintuitive now (realtime not started):

mah@nwheezy:~/machinekit-tutorial/src$ halcmd -f -k

halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate /var/log/linuxcnc.log
halcmd: the msgd:0 logger demon is not running - please investigate /var/log/linuxcnc.log

-m

[Pascal Huerst]

Am 07.08.2014 um 18:59 schrieb Michael Haberler <mai...@mah.priv.at>:

>

> Am 07.08.2014 um 18:22 schrieb pascal...@gmail.com:
>
>> Hey Michael, all,
>>
>> I built your 'machinetalk-preview-[2,3]' branchs today. But when I try to start afterwards, I get:
>>
>> halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout
>>
>> does this sound familiar to anyone?
>
> yes, have a look at /var/log/linuxcnc.log - it will even tell you which command you skipped ;)
>
> it's a missing 'sudo make setuid'

Hmm, I'm pretty sure I did that call, but anyways I should have checked the logs.

> tongue out of cheek - I need to look into doing a better diagnostic message for this - it is simply rtapi_app failed to start for some reason
>
> btw I suggest to pull machinetalk-preview-3 again in about an hour - I've been working lots on cleanups and the remote Web HAL UI demos which now actually do work - a remote HAL component, a HAL group demo, and a log reader test

Nice, looking forward to test it.

[Dejay]

A probably stupid linux noob question: I did a git checkout of the machinetalk preview in a separate directory to be able to simply switch, and I think I build it correctly, but how do I start it? 

Or is this not advisable?

[pascal...@gmail.com]

Am Freitag, 8. August 2014 02:15:20 UTC+2 schrieb Dejay:

A probably stupid linux noob question: I did a git checkout of the machinetalk preview in a separate directory to be able to simply switch, and I think I build it correctly, but how do I start it? 

Usually, from your machinekit directory, you do:

. ./scripts/rip-environment
linuxcnc
 

Or is this not advisable?

I dont think its a problem as long as only one instance is running

[Pascal Huerst]

>> does this sound familiar to anyone?
>
> yes, have a look at /var/log/linuxcnc.log - it will even tell you which command you skipped ;)
>
> it's a missing 'sudo make setuid'

That seems not to be the problem. (see my attached log)

> tongue out of cheek - I need to look into doing a better diagnostic message for this - it is simply rtapi_app failed to start for some reason
>
> btw I suggest to pull machinetalk-preview-3 again in about an hour - I've been working lots on cleanups and the remote Web HAL UI demos which now actually do work - a remote HAL component, a HAL group demo, and a log reader test

I pulled, recompiled, and got nicer error messages, but the problem is
still there.

Any Ideas?

regards
pascal

[Michael Haberler]

did this machine even run machinetalk or linuxcnc before successfully? if not, have a look at, and run this:

../scripts/check-system-configuration.sh

because the following hints it might be a problem with the shared memory segment size, i.e. limits.conf:

Aug 8 12:34:15 thinkpad rtapi:0: rtapi_app:0: ERROR: global segment magic not changing to ready: magic=0xeadbeef
Aug 8 12:34:15 thinkpad rtapi:0: rtapi:0: FATAL - failed to attach to global segment

(background:


then run the following like so:

DEBUG=5 realtime start

this should give a much more detailed log

that one is a candidate for an improved error message as well; I'll fix it as soon as the cause is clear

thanks!

-Michael

[Pascal Huerst]

>> I pulled, recompiled, and got nicer error messages, but the problem is
>> still there.
>>
>> Any Ideas?
>
> did this machine even run machinetalk or linuxcnc before successfully? if not, have a look at, and run this:

No it did not.

But I built and successfully run machinekit (32f48ce46a) on the same
machine, with the same kernel.

Its a Debian (Sid) Machine, with a custom built Xenomai Kernel, which
works with machinekit (32f48ce46a)

uname -a:
Linux lenovo 3.8.13-xenomai-2.6.3+ #3 SMP Fri Jul 11 11:27:37 CEST 2014
x86_64 GNU/Linux

> ../scripts/check-system-configuration.sh

This call did not output anything (Which I would say is good, from a
quick look in the script)

> because the following hints it might be a problem with the shared memory segment size, i.e. limits.conf:
>
> Aug 8 12:34:15 thinkpad rtapi:0: rtapi_app:0: ERROR: global segment magic not changing to ready: magic=0xeadbeef
> Aug 8 12:34:15 thinkpad rtapi:0: rtapi:0: FATAL - failed to attach to global segment
>
> (background:
>
>
> then run the following like so:
>
> DEBUG=5 realtime start

~/buildscripts/machinekit$ DEBUG=5 realtime start
warning: removing unused global shm segment /linuxcnc-0-00154711
zsys.c:331: zsys_handler_set: Assertion `handler_fn' failed.

halcmd: cant connect to rtapi_app: -1 (uri=
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate
/var/log/linuxcnc.log
halcmd: the msgd:0 logger demon is not running - please investigate
/var/log/linuxcnc.log

> this should give a much more detailed log

Unfortunately it does not.

[Michael Haberler]

Am 08.08.2014 um 15:16 schrieb Pascal Huerst <pascal...@gmail.com>:

>>> I pulled, recompiled, and got nicer error messages, but the problem is
>>> still there.
>>>
>>> Any Ideas?
>>
>> did this machine even run machinetalk or linuxcnc before successfully? if not, have a look at, and run this:
>
> No it did not.
>
> But I built and successfully run machinekit (32f48ce46a) on the same
> machine, with the same kernel.
>
> Its a Debian (Sid) Machine, with a custom built Xenomai Kernel, which
> works with machinekit (32f48ce46a)
>
> uname -a:
> Linux lenovo 3.8.13-xenomai-2.6.3+ #3 SMP Fri Jul 11 11:27:37 CEST 2014
> x86_64 GNU/Linux
>
>> ../scripts/check-system-configuration.sh
>
> This call did not output anything (Which I would say is good, from a
> quick look in the script)

yes, that makes all sense

>
>> because the following hints it might be a problem with the shared memory segment size, i.e. limits.conf:
>>
>> Aug 8 12:34:15 thinkpad rtapi:0: rtapi_app:0: ERROR: global segment magic not changing to ready: magic=0xeadbeef
>> Aug 8 12:34:15 thinkpad rtapi:0: rtapi:0: FATAL - failed to attach to global segment
>>
>> (background:
>>
>>
>> then run the following like so:
>>
>> DEBUG=5 realtime start
>
> ~/buildscripts/machinekit$ DEBUG=5 realtime start
> warning: removing unused global shm segment /linuxcnc-0-00154711
> zsys.c:331: zsys_handler_set: Assertion `handler_fn' failed.
> halcmd: cant connect to rtapi_app: -1 (uri=
> uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout
>
> halcmd: the rtapi:0 RT demon is not running - please investigate
> /var/log/linuxcnc.log
> halcmd: the msgd:0 logger demon is not running - please investigate
> /var/log/linuxcnc.log
>
>> this should give a much more detailed log
>
> Unfortunately it does not.

well it does - a bit: zsys.c:331: zsys_handler_set: Assertion `handler_fn' failed.

this hints me at something wrong with the zeromq or czmq library - maybe version, which prevents rtapi_msgd from coming up even so far it can write a log entry

it definitely should write a log entry at startup, for example:

Jun 12 09:54:44 beaglebone msgd:0: startup instance=inst0 pid=5527 flavor=xenomai rtlevel=1 usrlevel=1 halsize=512000 shm=Posix gcc=4.6.3 version=v2.7.0~pre0~machinetalk-preview~608ad28
Jun 12 09:54:44 beaglebone msgd:0: ØMQ=4.0.4 czmq=2.2.0 protobuf=2.4.1

here's the interesting stuff -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

it's evident that rtapi_msgd (owner of the global shared memory segment) doesnt come up, and everything else is a consequence



so lets do this:

realtime stop, then run rtapi_msgd under gdb like so:

mah@nwheezy:~/machinekit-tutorial/src$ DEBUG=5 gdb ../libexec/rtapi_msgd

GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/mah/machinekit-tutorial/libexec/rtapi_msgd...done.

(gdb) r --foreground --stderr

Starting program: /home/mah/machinekit-tutorial/libexec/rtapi_msgd --foreground --stderr
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
Aug 8 16:21:44 msgd:0: startup instance=inst0 pid=26953 flavor=posix rtlevel=3 usrlevel=3 halsize=262000 shm=Posix gcc=4.7.2 version=v2.7.0~pre0~machinetalk-preview-3~9d073be
Aug 8 16:21:44 msgd:0: ØMQ=4.0.4 czmq=2.2.0 protobuf=2.4.1

------------------------^^^^^^^^^^^^^^ ---- what does this line say? do you get this far at all?

Aug 8 16:21:44 msgd:0: configured: Aug 7 2014 18:49:58 sha=9d073be
Aug 8 16:21:44 msgd:0: built: Aug 8 2014 10:15:00 sha=1b9b0b2
Aug 8 16:21:44 msgd:0: WARNING: git SHA's for configure and build do not match!
[New Thread 0xb7817b70 (LWP 26957)]
[New Thread 0xb7016b70 (LWP 26958)]
Aug 8 16:21:44 msgd:0: publishing ZMQ/protobuf log messages at ipc:///tmp/0.log.a42c8c6b-4025-4f83-ba28-dad21114744a

while msgd runs under gdb like above, do this in another window:

l$ ls -l /run/shm/
total 604
-rw-rw---- 1 mah mah 528416 Aug 8 16:24 linuxcnc-0-00154711 <------- the global shared memory segment, must exist



also, try this - this should give a hint which shared libraries are involved, because I'm pretty sure this is a shared library version snafu:

mah@nwheezy:~/machinekit-tutorial/src$ ldd ../libexec/rtapi_msgd

example output, please paste yours:

linux-gate.so.1 => (0xb7753000)
liblinuxcncshm.so.0 => /home/mah/machinekit-tutorial/lib/liblinuxcncshm.so.0 (0xb774d000)
liblinuxcncini.so.0 => /home/mah/machinekit-tutorial/lib/liblinuxcncini.so.0 (0xb7749000)
libmtalk.so.0 => /home/mah/machinekit-tutorial/lib/libmtalk.so.0 (0xb773b000)
liblinuxcnc-pb2++.so.0 => /home/mah/machinekit-tutorial/lib/liblinuxcnc-pb2++.so.0 (0xb75da000)
libprotobuf.so.7 => /usr/lib/libprotobuf.so.7 (0xb74c7000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb74ae000)
libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb7495000)
libczmq.so.1 => /usr/lib/i386-linux-gnu/libczmq.so.1 (0xb7448000)
libzmq.so.3 => /usr/lib/i386-linux-gnu/libzmq.so.3 (0xb739f000)
libavahi-common.so.3 => /usr/lib/i386-linux-gnu/libavahi-common.so.3 (0xb7391000)
libavahi-client.so.3 => /usr/lib/i386-linux-gnu/libavahi-client.so.3 (0xb737f000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7293000)
libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb728e000)
libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xb7288000)
librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xb727f000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7262000)
libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb70fe000)
libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb70d7000)
libjansson.so.4 => /usr/lib/i386-linux-gnu/libjansson.so.4 (0xb70ca000)
/lib/ld-linux.so.2 (0xb7754000)
libsodium.so.10 => /usr/lib/libsodium.so.10 (0xb705a000)
libdbus-1.so.3 => /lib/i386-linux-gnu/libdbus-1.so.3 (0xb700f000)


- Michael

[Pascal Huerst]

Yap, I got:

Aug 8 18:40:17 msgd:0: ØMQ=4.0.4 czmq=3.0.0 protobuf=2.5.0

Well, I think I will switch to czmq-2.2.0, as a first step and let you
know, if something changed...

> Aug 8 16:21:44 msgd:0: configured: Aug 7 2014 18:49:58 sha=9d073be
> Aug 8 16:21:44 msgd:0: built: Aug 8 2014 10:15:00 sha=1b9b0b2
> Aug 8 16:21:44 msgd:0: WARNING: git SHA's for configure and build do not match!
> [New Thread 0xb7817b70 (LWP 26957)]
> [New Thread 0xb7016b70 (LWP 26958)]
> Aug 8 16:21:44 msgd:0: publishing ZMQ/protobuf log messages at ipc:///tmp/0.log.a42c8c6b-4025-4f83-ba28-dad21114744a
>
> while msgd runs under gdb like above, do this in another window:
>
> l$ ls -l /run/shm/
> total 604
> -rw-rw---- 1 mah mah 528416 Aug 8 16:24 linuxcnc-0-00154711 <------- the global shared memory segment, must exist

I got a SIGABRT, right after run, but the share memory segment is still
there:

-rw-rw---- 1 paso paso 531824 Aug 8 19:16 linuxcnc-0-00154711

(removed the entry points to avoid line wrapping)

machinekit git:(machinetalk-preview-3) ldd libexec/rtapi_msgd

linux-vdso.so.1 (0x00007fff9ab74000)
liblinuxcncshm.so.0 => /home/paso/machinekit/lib/liblinuxcncshm.so.0
liblinuxcncini.so.0 => /home/paso/machinekit/lib/liblinuxcncini.so.0
libmtalk.so.0 => /home/paso/machinekit/lib/libmtalk.so.0
liblinuxcnc-pb2++.so.0 => /home/paso/machinekit/lib/liblinuxcnc-pb2++.so.0
libprotobuf.so.8 => /usr/local/lib/libprotobuf.so.8
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
libczmq.so.1 => /usr/local/lib/libczmq.so.1 (0x00007fd0500ac000)
libzmq.so.3 => /usr/lib/x86_64-linux-gnu/libzmq.so.3
libavahi-common.so.3 => /usr/lib/x86_64-linux-gnu/libavahi-common.so.3
libavahi-client.so.3 => /usr/lib/x86_64-linux-gnu/libavahi-client.so.3
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
libjansson.so.4 => /usr/local/lib/libjansson.so.4
/lib64/ld-linux-x86-64.so.2
libpgm-5.1.so.0 => /usr/lib/libpgm-5.1.so.0
libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3

[Michael Haberler]

Am 08.08.2014 um 17:25 schrieb Pascal Huerst <pascal...@gmail.com>:

>> Aug 8 16:21:44 msgd:0: ØMQ=4.0.4 czmq=2.2.0 protobuf=2.4.1
>>
>> ------------------------^^^^^^^^^^^^^^ ---- what does this line say? do you get this far at all?
>
> Yap, I got:
>
> Aug 8 18:40:17 msgd:0: ØMQ=4.0.4 czmq=3.0.0 protobuf=2.5.0
>
> Well, I think I will switch to czmq-2.2.0, as a first step and let you
> know, if something changed...

>
>> Aug 8 16:21:44 msgd:0: configured: Aug 7 2014 18:49:58 sha=9d073be
>> Aug 8 16:21:44 msgd:0: built: Aug 8 2014 10:15:00 sha=1b9b0b2
>> Aug 8 16:21:44 msgd:0: WARNING: git SHA's for configure and build do not match!
>> [New Thread 0xb7817b70 (LWP 26957)]
>> [New Thread 0xb7016b70 (LWP 26958)]
>> Aug 8 16:21:44 msgd:0: publishing ZMQ/protobuf log messages at ipc:///tmp/0.log.a42c8c6b-4025-4f83-ba28-dad21114744a
>>
>> while msgd runs under gdb like above, do this in another window:
>>
>> l$ ls -l /run/shm/
>> total 604
>> -rw-rw---- 1 mah mah 528416 Aug 8 16:24 linuxcnc-0-00154711 <------- the global shared memory segment, must exist
>
> I got a SIGABRT, right after run, but the share memory segment is still
> there:

It's this line: https://github.com/zeromq/czmq/blob/master/src/zsys.c#L331 - an API change, the folks over at zeromq have fiddled with signal handling in the bleeding edge code, and that bit you

I've filed a comment since their change doesnt make sense to me: https://github.com/zeromq/czmq/commit/ce664b95f5a7ded4e709f65930a0538ddf5a67b2

I have a workaround, but I rather convince the zeromq folk not driving over users's signal handling provisions like a truck ;)

until then, remaining with the 2.2.0 tag should be safe, that is what John is using for the packages: https://github.com/zultron/czmq-deb/blob/master/changelog

- Michael

[Pascal Huerst]

> It's this line: https://github.com/zeromq/czmq/blob/master/src/zsys.c#L331 - an API change, the folks over at zeromq have fiddled with signal handling in the bleeding edge code, and that bit you
>
> I've filed a comment since their change doesnt make sense to me: https://github.com/zeromq/czmq/commit/ce664b95f5a7ded4e709f65930a0538ddf5a67b2
>
> I have a workaround, but I rather convince the zeromq folk not driving over users's signal handling provisions like a truck ;)
>
> until then, remaining with the 2.2.0 tag should be safe, that is what John is using for the packages: https://github.com/zultron/czmq-deb/blob/master/changelog

Ok, I see, this makes sense. I rebuilt czmq, with a checkout of the
v2.2.0 tagged commit (which is: b0e9b7f144). Unfortunately it is still
not working. The log says now:


Aug 8 20:13:27 lenovo msgd:0: startup instance=inst0 pid=2759
flavor=xenomai rtlevel=1 usrlevel=1 halsize=512000 shm=Posix gcc=4.9.0
version=v2.7.0~pre0~machinetalk-preview-3~fa94b5f

Aug 8 20:13:27 lenovo msgd:0: ØMQ=4.0.4 czmq=2.2.1 protobuf=2.5.0
Aug 8 20:13:27 lenovo msgd:0: configured: Aug 8 2014 19:58:42 sha=fa94b5f

---> czmq=2.2.1, don't know why its not 2.2.0, the problematic
assert(handler_fn), however was added later, so this seems ok

Aug 8 20:13:27 lenovo msgd:0: built: Aug 8 2014 19:59:24 sha=fa94b5f

Aug 8 20:13:27 lenovo msgd:0: publishing ZMQ/protobuf log messages at
ipc:///tmp/0.log.a42c8c6b-4025-4f83-ba28-dad21114744a

Aug 8 20:13:28 lenovo msgd:0: rtapi_app:2765:user accepting commands at
ipc:///tmp/0.rtapi.a42c8c6b-4025-4f83-ba28-dad21114744a

Aug 8 20:14:58 lenovo msgd:0: msgd:0: got signal 15 - sending SIGTERM
to rtapi (pid 2765)

Aug 8 20:14:58 lenovo msgd:0: msgd:0: Terminated - shutting down
Aug 8 20:14:58 lenovo msgd:0: sent SIGTERM to rtapi (pid 2765)
Aug 8 20:14:58 lenovo msgd:0: normal shutdown - global segment detached

[Michael Haberler]

I dont see the 'not working' yet here - looks like a normal startup sequence, what was the command?

is this the same machine as before? thinkpad changed to lenovo?

anyway:

msgd starts, rtapi starts
msgd receives a SIGTERM (from where?)
normal shutdown sequence - msgd sends a signal to rtapi to exit

if you just try

DEBUG=5 realtime start
halcmd -f -k

can you load HAL modules?

if this isnt it yet: you can run both key demons, msgd and rtapi, under gdb standalone - without any script

gdb ../libexec/rtapi_msgd
r --foreground --stderr

and in another window

gdb ../libexec/rtapi_app_xenomai
r --foreground -d -d

both should happily stay alive and you should be able to run halcmd from some other window as above
if halcmd causes an issue, it should be reflected in one of the gdb windows

rtapi might need some determination to kill when running from gdb - intentionally.


- Michael

ps: likely unrelated, but better to stay away from gcc 4.9 for now: https://lkml.org/lkml/2014/7/24/584

[Pascal Huerst]

FYI, it compiled and it runs. Thanks a lot for your help so far!

[Michael Haberler]

Am 14.08.2014 um 14:56 schrieb Pascal Huerst <pascal...@gmail.com>:

> FYI, it compiled and it runs. Thanks a lot for your help so far!

excellent, thanks for the report!

curious.. did you wind up using czmq master post Pieter's fix, or the version from John's packages? just trying to gauge if there's any API breakage in the pipe which might need attention

since you're a daring devil ;) can I ask you this:

- run the src/machinetalk/tutorials/motorctrl demo
- extra bonus points ;) try to run it with Alex's QtQuickVCP on a Android platform
- try to make sense of it how things fit together (worth reading: lib/python/hal_glib.py the GRemoteComponent, GRemotePin and possibly GServiceResolver classes)
- sketch which parts dont make sense yet without further detail

I'm trying to figure what needs to go into the manual, and at what level of detail; I wrote the code so it helps against my tunnel vision

thanks!

- Michael

[Pascal Huerst]

On 14.08.2014 21:30, Michael Haberler wrote:
>
> Am 14.08.2014 um 14:56 schrieb Pascal Huerst <pascal...@gmail.com>:
>

>> FYI, it compiled and it runs. Thanks a lot for your help so far!
>

> excellent, thanks for the report!
>
> curious.. did you wind up using czmq master post Pieter's fix, or the version from John's packages? just trying to gauge if there's any API breakage in the pipe which might need attention

I built using the master branch this time (and gcc4.6). It seems to be
working...

> since you're a daring devil ;) can I ask you this:
>
> - run the src/machinetalk/tutorials/motorctrl demo
> - extra bonus points ;) try to run it with Alex's QtQuickVCP on a Android platform
> - try to make sense of it how things fit together (worth reading: lib/python/hal_glib.py the GRemoteComponent, GRemotePin and possibly GServiceResolver classes)
> - sketch which parts dont make sense yet without further detail

I'll give it try after lunch and let you know...

> I'm trying to figure what needs to go into the manual, and at what level of detail; I wrote the code so it helps against my tunnel vision
>
> thanks!

Sure :-)

[Pascal Huerst]

> - run the src/machinetalk/tutorials/motorctrl demo

Problem so far: (For every GUI once I think)

Traceback (most recent call last):
2 File "/home/paso/buildscripts/machinekit/bin/configserver", line
272, in <module>
3 main()
4 File "/home/paso/buildscripts/machinekit/bin/configserver", line
269, in main
5 debug = debug)
6 File "/home/paso/buildscripts/machinekit/bin/configserver", line
95, in __init__
7 self.dsname = self.socket.get_string(zmq.LAST_ENDPOINT,
encoding='utf-8')
8 File "socket.pyx", line 414, in zmq.core.socket.Socket.__getattr__
(zmq/core/socket.c:4091)
9 AttributeError: Socket has no such option: GET_STRING

This might be related to the version of zeromq again, or does it look
familiar to you?

I also had to install:

python-gtkglext1
python-gtksourceview2

in order to get the second ui started.

[Michael Haberler]

Pascal,

Am 15.08.2014 um 17:31 schrieb Pascal Huerst <pascal...@gmail.com>:

>> - run the src/machinetalk/tutorials/motorctrl demo
>
> Problem so far: (For every GUI once I think)
>
> Traceback (most recent call last):
> 2 File "/home/paso/buildscripts/machinekit/bin/configserver", line
> 272, in <module>
> 3 main()
> 4 File "/home/paso/buildscripts/machinekit/bin/configserver", line
> 269, in main
> 5 debug = debug)
> 6 File "/home/paso/buildscripts/machinekit/bin/configserver", line
> 95, in __init__
> 7 self.dsname = self.socket.get_string(zmq.LAST_ENDPOINT,
> encoding='utf-8')
> 8 File "socket.pyx", line 414, in zmq.core.socket.Socket.__getattr__
> (zmq/core/socket.c:4091)
> 9 AttributeError: Socket has no such option: GET_STRING
>
> This might be related to the version of zeromq again, or does it look
> familiar to you?

yes, and it points to the Python bindings afaict; from a quick scan of czmq and libzmq it seems that code (get last endpoint) hasnt been touched in a while so I dont think that's it - rather the pyzmq version, the ones in the debian stream are pretty old:

what does 'apt-cache policy python-zmq' say on your box?

here it's this output, indicating it pulled in John's wheezy package

mah@nwheezy:~/src/pyzmq$ apt-cache policy python-zmq
python-zmq:
Installed: 14.3.0-2~1mk~wheezy1
Candidate: 14.3.0-2~1mk~wheezy1
Version table:
*** 14.3.0-2~1mk~wheezy1 0
500 http://deb.dovetail-automata.com/ wheezy/main i386 Packages
100 /var/lib/dpkg/status
13.1.0-1~bpo70+1 0
100 http://ftp.at.debian.org/debian/ wheezy-backports/main i386 Packages
100 http://ftp.us.debian.org/debian/ wheezy-backports/main i386 Packages
2.2.0-1 0
500 http://ftp.at.debian.org/debian/ wheezy/main i386 Packages


in case you're so patient to finish the experiment - to isolate, a brute-force method of updating pyzmq would be

apt-get remove --purge python-zmq
apt-get install python-pip
pip install pyzmq

that should positively exclude pyzmq from the breakage candidates list

> I also had to install:
>
> python-gtkglext1
> python-gtksourceview2
>
> in order to get the second ui started.

yes, that is the unfortunate difference between build prerequisites and runtime prerequisites which arent identical. In a package install these would be pulled in properly.

thanks for the patience!

- Michael

>
>> - extra bonus points ;) try to run it with Alex's QtQuickVCP on a Android platform
>> - try to make sense of it how things fit together (worth reading: lib/python/hal_glib.py the GRemoteComponent, GRemotePin and possibly GServiceResolver classes)
>> - sketch which parts dont make sense yet without further detail
>

[Pascal Huerst]

On 15.08.2014 18:09, Michael Haberler wrote:
> Pascal,
>
> Am 15.08.2014 um 17:31 schrieb Pascal Huerst <pascal...@gmail.com>:
>
>>> - run the src/machinetalk/tutorials/motorctrl demo
>>
>> Problem so far: (For every GUI once I think)
>>
>> Traceback (most recent call last):
>> 2 File "/home/paso/buildscripts/machinekit/bin/configserver", line
>> 272, in <module>
>> 3 main()
>> 4 File "/home/paso/buildscripts/machinekit/bin/configserver", line
>> 269, in main
>> 5 debug = debug)
>> 6 File "/home/paso/buildscripts/machinekit/bin/configserver", line
>> 95, in __init__
>> 7 self.dsname = self.socket.get_string(zmq.LAST_ENDPOINT,
>> encoding='utf-8')
>> 8 File "socket.pyx", line 414, in zmq.core.socket.Socket.__getattr__
>> (zmq/core/socket.c:4091)
>> 9 AttributeError: Socket has no such option: GET_STRING
>>
>> This might be related to the version of zeromq again, or does it look
>> familiar to you?
>
> yes, and it points to the Python bindings afaict; from a quick scan of czmq and libzmq it seems that code (get last endpoint) hasnt been touched in a while so I dont think that's it - rather the pyzmq version, the ones in the debian stream are pretty old:
>
> what does 'apt-cache policy python-zmq' say on your box?

it was 2.2.0.

> here it's this output, indicating it pulled in John's wheezy package
>
> mah@nwheezy:~/src/pyzmq$ apt-cache policy python-zmq
> python-zmq:
> Installed: 14.3.0-2~1mk~wheezy1
> Candidate: 14.3.0-2~1mk~wheezy1
> Version table:
> *** 14.3.0-2~1mk~wheezy1 0
> 500 http://deb.dovetail-automata.com/ wheezy/main i386 Packages
> 100 /var/lib/dpkg/status
> 13.1.0-1~bpo70+1 0
> 100 http://ftp.at.debian.org/debian/ wheezy-backports/main i386 Packages
> 100 http://ftp.us.debian.org/debian/ wheezy-backports/main i386 Packages
> 2.2.0-1 0
> 500 http://ftp.at.debian.org/debian/ wheezy/main i386 Packages
>
>
> in case you're so patient to finish the experiment - to isolate, a brute-force method of updating pyzmq would be
>
> apt-get remove --purge python-zmq
> apt-get install python-pip
> pip install pyzmq

Did so and its working now. I can set Positions and see the values
change. Can not test on the real system, however, since we are running
tests right now.

> that should positively exclude pyzmq from the breakage candidates list
>
>> I also had to install:
>>
>> python-gtkglext1
>> python-gtksourceview2
>>
>> in order to get the second ui started.
>
> yes, that is the unfortunate difference between build prerequisites and runtime prerequisites which arent identical. In a package install these would be pulled in properly.
>
> thanks for the patience!
>
> - Michael
>
>>
>>> - extra bonus points ;) try to run it with Alex's QtQuickVCP on a Android platform
>>> - try to make sense of it how things fit together (worth reading: lib/python/hal_glib.py the GRemoteComponent, GRemotePin and possibly GServiceResolver classes)
>>> - sketch which parts dont make sense yet without further detail

I'll give these things a try, but I wont be arround for a week or so.
I'll let you know, when I have something to report.

cheers
pascal

[Michael Haberler]

Pascal,

thanks a lot!

Am 15.08.2014 um 19:26 schrieb Pascal Huerst <pascal...@gmail.com>:


>> what does 'apt-cache policy python-zmq' say on your box?
>
> it was 2.2.0.

ah, once more. This is the problem with the usually dated package streams and certain faster moving spaces like Python, cython, or node for that matter - you want an 'easy' install, you go for packages; you want a working recent install - you need to install via the subculture-specific command like pip, npm etc, which creates a bit of an install mess.

My hopeful speculation is the package streams improve while machinekit matures; by the time jessie becomes stable it should be next to no extras needed.

>> pip install pyzmq
>
> Did so and its working now. I can set Positions and see the values
> change. Can not test on the real system, however, since we are running
> tests right now.

excellent - you have a basic machinetalk application running ;)

- Michael