ZeroMq IRC Log

Saturday April 23, 2011

[Time] Name	Message
[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 http://build.zero.mq/
[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: add.py, subtract.py, multiply.py, and divide.py. 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: http://zguide.zeromq.org/page:all#Service-Oriented-Reliable-Queuing-Majordomo-Pattern
[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	http://www.zeromq.org/bindings:d
[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	...by 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 http://www.zeromq.org/docs:3-0
[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