Saturday April 23, 2011

[Time] NameMessage
[00:19] ParadoxG Hi, is ZMQ_DELIMITER normally used as a char, or is it an int?
[06:52] rukubites How would I go about cross-compiling a 32 bit (linux) version of zeromq on 64 bit linux?
[06:53] rukubites The purpose is to interface with wine, to provide zeromq communication to an application run via wine.
[06:53] guido_g why?
[06:54] guido_g there is .net binding for the windows side
[06:54] guido_g just use the local network interface
[06:55] rukubites Well I am very unfamiliar with windows coding, and I don't know how to hook into .net from the target application - which has its own language.
[06:55] rukubites Essentially because this route taps into my knowledge base much easier.
[06:56] rukubites The target 'platform' is mt4, a trading platform.
[06:56] guido_g how would a 32 linux version help then?
[06:56] guido_g *32-bit
[06:57] rukubites Because wine requires an m32.
[06:57] guido_g and then?
[06:57] rukubites And so I can't link to 64bit libzmq.
[06:57] guido_g and?
[06:57] guido_g the app is still not useing it
[06:58] rukubites I have a bit of glue code between zeromq and the target app I am trying to build. There are instructions for wine, but it is failing on libzmq because I only have 64 bit libzmq as I am on 64 bit machine.
[06:59] guido_g this sounds very strange and fragile
[06:59] rukubites You are right, it is exotic. The target platform mt4 is known to make it very hard to communicate.
[07:00] rukubites I want to run on wine because having a virtual machine or dedicated box for one application is expensive in RAM, CPU and/or monetary cost.
[07:01] guido_g not as expensive as the time for development and maintenace
[07:01] guido_g and better hope speed is not an issue
[07:02] guido_g but i can't help you w/ the cross compiling thing
[07:02] rukubites Speed really isn't the issue. It is a pretty simple end-point.
[07:02] guido_g try a place where compiler geeks are
[07:02] rukubites e.g.?
[07:02] guido_g no clue, i don't do such things ,)
[07:03] rukubites Fair enough. Thanks for your time, anyway. :-)
[07:04] guido_g you might want to stay here and wait for mikko, is the build guy and might know a bit
[07:05] rukubites Okay I will lurk. And hopefully your message pinged him. :D
[07:08] pieterh rukubites: hi
[07:09] rukubites Hi pieterh.
[07:09] pieterh so, gcc lets you builds 32-bit on a 64-bit box
[07:09] pieterh pass -m32 option
[07:10] pieterh then, 'configure --help' to see what to do next
[07:10] pieterh set CFLAGS=-m32
[07:10] pieterh ./configure and make, and it should have worked
[07:11] rukubites I will try that next. I did a make just as normal because I need the 64-bit version for normal use. :-)
[07:11] rukubites Figured I would remove the ubuntu ppa version and compile it myself.
[07:12] pieterh sure, easy enough
[07:15] rukubites My first try I will do --build=i686-pc-linux-gnu
[07:34] rukubites I got through compilation by just compiling on a spare 32 bit instance I had around. I probably should have just downloaded the appropriate daily build from
[07:37] rukubites Using CFLAGS=-m32 did not work, I am sure mikko the build guy would know what I should have done. But that step seems solved, thank you for the help pieterh and guido_g.
[09:16] justinuza Hey all. I have a problem that I'm trying to solve, and I feel like zeromq can do it, but I just keep reading docs and examples and whatever else I can find and can't seem to visualize how it would work - and what sockets I would need. If anyone could provide some insight, I would greatly appreciate it...
[09:17] justinuza I would like to have a Job Manager that producers can submit jobs to, and then the producer should get a response when the job is complete. The jobs should be picked up by consumers (1 job --> 1 consumer) where the consumer processes the job, returns the result to the Job Manager, which then returns the result to the producer. For instance, lets say there are 4 types of tasks: Add, Subtract, Multiply, and Divide. The Job Manager sho
[09:17] justinuza I'm more interested in the Job Manager <--> Worker communication than the Producer <--> Job Manager. However, one caveat is that there should be able to be N types of tasks, and potentially new tasks added on the fly.
[09:17] justinuza Is something like what I'm describing possible to accomplish with zeromq?
[09:18] sustrik use REQ/REP with an interdediary device
[09:19] justinuza an intermediary device? that being the "job manager"?
[09:27] justinuza does that mean i would need to maintain a worker pool for each task type? when a 'multiply' job comes in, go to the 'multiply' pool and choose a REQ socket that isn't currently waiting for a REP from a worker, and send the job along?
[09:28] sustrik depends on who processes different job types
[09:28] sustrik same application doing all job types?
[09:28] sustrik or different applications doing different jobs?
[09:28] justinuza different applications doing different jobs
[09:28] sustrik then i would suggest using a different topology for each job type
[09:29] sustrik that way you have different functions clearly separated and manageable without affecting other functions in any way
[09:31] justinuza right, from my example lets say i have 4 python scripts:,,, and each worker would be an instance of one of the scripts running on a box (separate processes), but i want to route to all of them from a single job manager
[09:33] sustrik ok, you then need 4 XREX and XREP sockets in the job manager
[09:33] sustrik poll on all of them
[09:33] sustrik pass messages to the corresponsing socket
[09:33] sustrik that's it
[09:34] justinuza XREQ sockets in the job manager and XREP sockets in the workers? or vice versa?
[09:34] guido_g justinuza:
[09:35] guido_g lots of questions are answered in The Guide
[09:35] sustrik guido_g: thanks
[09:36] justinuza Thanks guido_g. I tried to read through it, but its a little bit gigantic :)
[09:36] guido_g sustrik: np, just a hot-key :)
[09:37] guido_g justinuza: what shall i say? i this this to much to read, how will you learn the principals of ØMQ and brokerless messaging in generall?
[09:39] justinuza guido: I certainly don't disagree... I hope that I do have enough time to get through all of it, and I thank you for your help.
[10:58] jsimmons Anybody worked on a D binding for zmq?
[10:59] guido_g
[11:00] jsimmons oh that's not a full list I see
[11:16] pieter_hintjens jsimmons: I
[11:16] pieter_hintjens I've added D to the main page
[11:16] jsimmons :D
[11:16] pieter_hintjens it's not always clear which bindings are actively maintained & used
[11:18] th so zmq_recv and zmq_send will be more POSIX in 3.0, how is that supposed to be regarding multiparts? will a recv go over part-boundaries?
[11:18] th or is it like EOF for every part?
[11:22] headzone what makes you think multipart handling would change
[11:22] th i dont
[11:22] th i had a look at the 3.0 roadmap
[11:23] th which is talking about making the 2 functions more coherent with POSIX send/recv
[11:23] headzone renaming them
[11:24] th the current ones will become sendmsg and recvmsg, as i read it
[11:24] th later on in the roadmap there is some code showing those zmq_recv/zmq_send functions
[11:25] th my interpretation was that current functions become "msg" suffixed and zmq_recv/zmq_send will behave more like POSIX send/recv
[11:25] th thus resulting in 2 sets of the two functions
[11:25] th am i wrong?
[11:26] th i'm referring to "Proposal for send/recv API based on POSIX socket API:"
[11:26] th at
[12:00] sustrik th: you are right
[12:00] sustrik the multipart will work in standard way
[12:01] sustrik actually, it already works in stadard way
[12:01] sustrik to check the new api give a try to libzmq master
[12:10] th sustrik: and with standard way you mean using the zmq_recvmsg?
[12:16] sustrik i mean using ZMQ_SNDMORE and ZMQ_RCVMORE
[12:16] sustrik it works with zmq_send, zmq_sendmsg, zmq_recv and zmq_recvmsg