gabriel russell | 19 Nov 22:02 2013

subsubscribe


ismud | 13 May 14:07 2013
Picon

epgm example code

hi,

are there any working examples of using epgm transport with xs? I wrote an example program in C to use tcp, but
the same program doesn't work with epgm. I'm not sure what's wrong, cause both programs (publisher and
subscriber) seem to work fine, and I can also see packets on udp port using tcpdump, but messages aren't
getting through (to the subscriber). I'm using PUB/SUB pattern.

Or anyone has some suggestions on what to look for to make it work?
Jason Baker | 10 Apr 00:07 2013
Picon

Custom Transports

What's involved in creating a transport for Crossroads IO/ZeroMQ?  I'm
trying to see if there's anything I can hack together to make Crossroads
play well with my company's internal RPC protocol.

Dirkjan Ochtman | 6 Apr 13:35 2013
Picon

Re: To ZMQ or to XS: ArchLinux ARM

On Sat, Apr 6, 2013 at 1:21 PM, mwpowellhtx <mwpowellhtx@...> wrote:
> So... What's the story with the ZMQ / XS fork in the road? In either case, more work is involved, adapters are
required around or among the mix of comm "pipes", whether we're talking about a file transfer chunker (per
se), number crunching data factory producer/consumer, event brokering messaging system, what have you.

XS is mostly dead, further development is being done from the ground
up under the nanomsg project.

Cheers,

Dirkjan

Dirkjan Ochtman | 6 Apr 13:44 2013
Picon

Re: To ZMQ or to XS: ArchLinux ARM

On Sat, Apr 6, 2013 at 1:41 PM, mwpowellhtx <mwpowellhtx@...> wrote:
> So what does this mean? Keep on with ZMQ for the time being, if distributed architecture is what we're
aiming at accomplishing? Nanomsg is not yet released, so where does that leave us? Good to learn this
before spending a whole lot of time on the topic.

I would definitely go with ZMQ over Crossroads until nanomsg is further along.

Cheers,

Dirkjan

mwpowellhtx | 6 Apr 13:21 2013
Picon

To ZMQ or to XS: ArchLinux ARM

Hello,

See below: I'm less concerned the cross-language support is there, looks like enough work is put into C#
.NET, could be used there as well as C++. Our 64 million dollar question is: has anyone cross compiled into
ArchLinux ARM yet?

I am responsible for designing an embedded device which I believe will have embedded and non-embedded,
intra-process, and inter-process, messages passing between various architectural components, and
several potentially viable technologies have revealed themselves as candidates in this horse race.

While I don't consider myself a betting man, per se, I would like to leverage this technology for
infrastructure so that I can focus on solving present problems instead of bogging down in inter-thread
comm, event brokering, IPC, and a whole host of related issues.

Also, to give you an idea, CORBA and ZeroC Ice have also been considered. CORBA less attractive for bloat,
design-by-committee reasons, and ZeroC Ice has its own set of challenges: technically, is very fast,
extends directly into the object model allowing me to focus on the servant/client relationship, also
instead of infrastructure.

So... What's the story with the ZMQ / XS fork in the road? In either case, more work is involved, adapters are
required around or among the mix of comm "pipes", whether we're talking about a file transfer chunker (per
se), number crunching data factory producer/consumer, event brokering messaging system, what have you.

Serialization issues can be addressed. As can SOLID architectural decisions like extending into a
distributed event model, etc. The right kind of SOLID design can permit an extensible, maintainable
design around either technology. As regards ZMQ or XS, I'm more concerned with the fork and stability of
either or both infrastructures. I believe I've seen a post enumerating the ZMQ roadmap as well as XS. Along
these lines...

Also, are there any benchmark numbers comparing / contrasting latency and throughput outcomes?
(Continue reading)

mwpowellhtx | 6 Apr 13:28 2013
Picon

Re: To ZMQ or to XS: ArchLinux ARM

Looks like the libraries are at least there in some form.

http://archlinuxarm.org/packages?arch=&search=&order=pkgname&sort=desc

So I could possibly dynamically link with a shared library. Which answers one question, can build from
sources. I'd like to configure and build statically however. Possible?

Does anyone know who's pushing the ArchLinux ARM cross compile library into the mirrors? Simple to
./configure, make, make install to a local $WORKSPACE/tools/installed directory?

Thank you...
Gabriele Svelto | 12 Feb 16:49 2013
Picon

[PATCH 2/3] Reworked the rules to build the manpages and extra documentation

― Attachment links are at the end of this email ―
Crossroads Development now contains the following file

    http://groups.crossroads.io/r/file/wIRyuUxPOzbBBWrGGrOByQ1pIw5-12p-2owxBZ6
    Name: 
    Type: text/x-patch
    Size: 3KB

Gabriele Svelto | 12 Feb 16:47 2013
Picon

[PATCH 0/3] Streamline the build system and convert it to to non-recursive automake

  Hello all,
I've been sitting for a while on a bunch of patches I wanted to sumbit 
to complete the build system clean up I had been working on and I 
thought it would be high time to submit them.

I've cooked up a set of 3 patches that converts the build system to 
non-recursive automake. This essentially consolidates the build system 
in a single makefile speeding up builds and tests quite a bit as all 
independent targets can now be built/run in parallel even though they 
reside in different sub-directories. In addition to that, all targets 
now have explicit dependencies even across sub-directories so for 
example changing a header file will automatically cause tests using it 
to be rebuilt which was not the case before. The only downside of this 
is that the main Makefile is quite a bit larger than before (but 
organized on a per-subdirectory basis) and rules are longer. All targets 
however are built exactly as they were before; I've also tested the 
patches on multiple architectures to ensure they would work correctly.

In addition to this I've cleaned up the documentation building step:
- Man files are now automatically handled by automake
- I've fixed some issues that caused the XML/HTML documentation to be 
built when it didn't need to and often in an incomplete way
- I've added quiet rules when invoking asciidoc that make the make 
invocation output more consistent

As a final step I've fixed out-of-tree builds when using the included 
the openpgm library. Without these changes you would need to build libxs 
from within the source tree if you intended to use the included openpgm 
tarball as out-of-tree builds didn't work.

(Continue reading)

Gabriele Svelto | 12 Feb 16:49 2013
Picon

[PATCH 3/3] Fixed out-of-tree builds when using the included openpgm library

― Attachment links are at the end of this email ―
Crossroads Development now contains the following file

    http://groups.crossroads.io/r/file/3AG7G22bGRCpS6L3CfCyvDaKvvP-Hj-2owxdbs
    Name: 
    Type: text/x-patch
    Size: 2KB

Gabriele Svelto | 12 Feb 16:48 2013
Picon

[PATCH 1/3] Converted the build system to non-recursive automake

― Attachment links are at the end of this email ―
Crossroads Development now contains the following file

    http://groups.crossroads.io/r/file/c0kBkvizy6AJkXbXwFWp4Tyfrnv-7eR-2owxc6l
    Name: 
    Type: text/x-patch
    Size: 27KB


Gmane