info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Tcl 8.5 & RabbitMQ
90 views
Skip to first unread message
George Bassis
Mar 24, 2019, 10:17:52 AM3/24/19
to
Hello all!
I have a system written in Tcl 8.5 from which I need to send monitoring data to a RabbitMQ. Enabling plugins (like Stomp) on the RabbitMQ in order to be able to use libs like tStomp is not an option. The only options I see in order to send the messages to the queue are either use https://github.com/dereckson/rabbitmq-tcl (but the shared object created will not be portable and will have to be built on each machine separately or call a Python script to do the sending in which case I will need to have a Python script create the connection to the queue and provide handles to be called from the tcl script in order to trigger the creation of the channel to the queue and the sending of the actual message (although I am not sure whether there is a Python library that could accomodate such a scenario). Has anyone faced a similar situation? Any suggestion would be more than welcome.
B.R.,
George
I have a system written in Tcl 8.5 from which I need to send monitoring data to a RabbitMQ. Enabling plugins (like Stomp) on the RabbitMQ in order to be able to use libs like tStomp is not an option. The only options I see in order to send the messages to the queue are either use https://github.com/dereckson/rabbitmq-tcl (but the shared object created will not be portable and will have to be built on each machine separately or call a Python script to do the sending in which case I will need to have a Python script create the connection to the queue and provide handles to be called from the tcl script in order to trigger the creation of the channel to the queue and the sending of the actual message (although I am not sure whether there is a Python library that could accomodate such a scenario). Has anyone faced a similar situation? Any suggestion would be more than welcome.
B.R.,
George
two...@gmail.com
Mar 24, 2019, 12:26:05 PM3/24/19
to
On Sunday, March 24, 2019 at 7:17:52 AM UTC-7, George Bassis wrote:
> Hello all!
and python code in separate processes and pipe them together. Then I
would create a "little language" where I could send simple text strings
from tcl to the python process. I would first just use a shell command line
to pipe
tclsh mytcl.tcl | python mypython.py
I would then send line oriented text strings, i.e. a stream with \n
separating commands.
I would then have the mypython.py read stdin a line at a time and
interpret commands of my devising.
For example, a simple little language might include such things as
connection localhost
queue hello
publish "" hello "hello world!"
close
So, whatever is easy for you to parse in the python program. The above
would be interpreted by the python script into the hello world example
on the RabbitMQ site's tutorial page for using python.
By doing it in 2 processes, you can test your output from tcl and
the input to python separately. For example, just place the above
lines in a text file and then
python mypython.py <file
would test the connection to RabbitMQ independent of tcl. Then just
have the tcl code output those text strings to stdout and test it
without the pipeline.
Then use a shell command to test the pipeline, and finally you could
use the pipeline options in the tcl [exec] command of tcl to finalize
the result so your tcl program would do the equivalent of the shell
pipeline.
Just my 3 cents :)
Hope this is of some use.
> Hello all!
>
> I will need to have a Python script create the connection to the queue and provide handles to be called from the tcl script
>
When I've needed to do something like this, I would keep my tcl code
> I will need to have a Python script create the connection to the queue and provide handles to be called from the tcl script
>
and python code in separate processes and pipe them together. Then I
would create a "little language" where I could send simple text strings
from tcl to the python process. I would first just use a shell command line
to pipe
tclsh mytcl.tcl | python mypython.py
I would then send line oriented text strings, i.e. a stream with \n
separating commands.
I would then have the mypython.py read stdin a line at a time and
interpret commands of my devising.
For example, a simple little language might include such things as
connection localhost
queue hello
publish "" hello "hello world!"
close
So, whatever is easy for you to parse in the python program. The above
would be interpreted by the python script into the hello world example
on the RabbitMQ site's tutorial page for using python.
By doing it in 2 processes, you can test your output from tcl and
the input to python separately. For example, just place the above
lines in a text file and then
python mypython.py <file
would test the connection to RabbitMQ independent of tcl. Then just
have the tcl code output those text strings to stdout and test it
without the pipeline.
Then use a shell command to test the pipeline, and finally you could
use the pipeline options in the tcl [exec] command of tcl to finalize
the result so your tcl program would do the equivalent of the shell
pipeline.
Just my 3 cents :)
Hope this is of some use.
Christian Gollwitzer
Mar 24, 2019, 4:11:51 PM3/24/19
to
Am 24.03.19 um 16:17 schrieb George Bassis:
> I have a system written in Tcl 8.5 from which I need to send monitoring data to a RabbitMQ. Enabling plugins (like Stomp) on the RabbitMQ in order to be able to use libs like tStomp is not an option. The only options I see in order to send the messages to the queue are either use https://github.com/dereckson/rabbitmq-tcl (but the shared object created will not be portable and will have to be built on each machine separately
I had a short look into the rabbitMQ-Tcl Makefile, and indeed, it does
not build with stubs. If you would update the Makefile and build with
stubs, I see no reason why you need to recompile for each machine unless
you have many different OSes - by different I mean not just different
flavours of Linux, but 32/64 bit, Windows, FreeBSD, ...
I usually build stuff like that with stubs and link statically to the
corresponding C library, then the resulting Tcl library is fairly portable.
Christian
> I have a system written in Tcl 8.5 from which I need to send monitoring data to a RabbitMQ. Enabling plugins (like Stomp) on the RabbitMQ in order to be able to use libs like tStomp is not an option. The only options I see in order to send the messages to the queue are either use https://github.com/dereckson/rabbitmq-tcl (but the shared object created will not be portable and will have to be built on each machine separately
not build with stubs. If you would update the Makefile and build with
stubs, I see no reason why you need to recompile for each machine unless
you have many different OSes - by different I mean not just different
flavours of Linux, but 32/64 bit, Windows, FreeBSD, ...
I usually build stuff like that with stubs and link statically to the
corresponding C library, then the resulting Tcl library is fairly portable.
Christian
mango
Mar 24, 2019, 7:22:39 PM3/24/19
to
On Sunday, March 24, 2019 at 7:17:52 AM UTC-7, George Bassis wrote:
> Hello all!
>
> I have a system written in Tcl 8.5 from which I need to send monitoring data [snip]
>
> B.R.,
> George
There is a pure-Tcl implementation of RabbitMQ done by FlightAware. Check out
http://github.com/flightaware/tclrmq
I've never used it, but it might help in this situation.
Christian Gollwitzer
Mar 25, 2019, 2:55:39 PM3/25/19
to
Am 24.03.19 um 16:17 schrieb George Bassis:
> Hello all!
>
> I have a system written in Tcl 8.5 from which I need to send monitoring data to a RabbitMQ.
Please do not respond off-group, unless you want to discuss private
>
> I have a system written in Tcl 8.5 from which I need to send monitoring data to a RabbitMQ.
matter. I'll quote your reply to me here:
> @ChristianGollwitzer: I decided to follow your suggestion. I compiled
> with clang, enabling tcl stubs and got the respective object files. I
> am now trying to statically link the resulting files with ld but
> continuously stumble upon undefined symbols in the resulting so.
> Could you please share the flags you have passed to ld in some
> project where you have managed to create a portable so?
1) Unless you tell your flags and your error message, it is hard to
understand the problem
2) Do not link using ld, link using the compiler.
3) I assume you compiled the C library as a static library, as this is
obviously the precondition. Best would be to compile it without shared
libraries, otherwise for some odd reason, gcc prefers the dynamic
library during the link
So I suggest, to first compile rabbitmq-c with BUILD_SHARED_LIBS=OFF and
BUILD_STATIC_LIBS=ON and with -fPIC. How to get this into the options
with cmake, I don't know. You'll have to figure it out, I'm not good at
cmake. In autoconf, if there is no option for it, you would set
CFLAGS="-fPIC"
Then compile the Tcl interface like this:
gcc -shared -fPIC -I/path/to/C/lib -L/path/to/C/libfile -DUSE_TCL_STUBS
rabbitmq-tcl.c -lrabbit -static-libgcc -ltclstub8.6 -o rabbitmq-tcl.so
Then you should be able to load that into any interpreter, including
tclkits. The -static-libgcc is a gcc specialty, not sure if it is needed
in clang or what the equivalent would be.
Hope this helps,
Christian
Christian Gollwitzer
Mar 26, 2019, 12:59:38 AM3/26/19
to
Am 25.03.19 um 20:55 schrieb Christian Gollwitzer:
tested with stubs.
https://github.com/dereckson/rabbitmq-tcl/blob/master/src/rabbitmq-tcl.c#L722
The call to Tcl_InitStubs() must be te first of all, but before he calls
Tcl_PkgRequire(). Without testing I believe this will not work. Move the
#ifdef USE_TCL_STUBS" block to the beginning of the function.
Christian
> So I suggest, to first compile rabbitmq-c with BUILD_SHARED_LIBS=OFF and
> BUILD_STATIC_LIBS=ON and with -fPIC. How to get this into the options
> with cmake, I don't know. You'll have to figure it out, I'm not good at
> cmake. In autoconf, if there is no option for it, you would set
> CFLAGS="-fPIC"
>
> Then compile the Tcl interface like this:
>
> gcc -shared -fPIC -I/path/to/C/lib -L/path/to/C/libfile -DUSE_TCL_STUBS
> rabbitmq-tcl.c -lrabbit -static-libgcc -ltclstub8.6 -o rabbitmq-tcl.so
I had a quick look into the source code, and it seems that it was never
> BUILD_STATIC_LIBS=ON and with -fPIC. How to get this into the options
> with cmake, I don't know. You'll have to figure it out, I'm not good at
> cmake. In autoconf, if there is no option for it, you would set
> CFLAGS="-fPIC"
>
> Then compile the Tcl interface like this:
>
> gcc -shared -fPIC -I/path/to/C/lib -L/path/to/C/libfile -DUSE_TCL_STUBS
> rabbitmq-tcl.c -lrabbit -static-libgcc -ltclstub8.6 -o rabbitmq-tcl.so
tested with stubs.
https://github.com/dereckson/rabbitmq-tcl/blob/master/src/rabbitmq-tcl.c#L722
The call to Tcl_InitStubs() must be te first of all, but before he calls
Tcl_PkgRequire(). Without testing I believe this will not work. Move the
#ifdef USE_TCL_STUBS" block to the beginning of the function.
Christian
0 new messages