World: r3wp

Interesting that it works under WINE but not Windows. :-) I did have 
to install some Visual C++ runtime from 2008, but the lack of that 
produced a fairly clear error pointing in that direction

Did you install libzmq.dll? It's a binding with a dynamic library

I suppose Gregg did, mentioning 2.0.10

regarding the: "... but implements decimal math, not floating point 
math." - sorry, that is false. Actually, I think, that it implements 
decimal floating point math. What it does not implement is binary 
floating point math.

Kaj: I've installed the Windows binary from this archive: http://mark.ossdl.de/2011/01/zmq-and-pyzmq-for-windows/

That 0MQ version works for me on WINE

Ok, got the Linux support working (except the DLL support part).
Simple hello word executable: 162 bytes
Hello.reds executable: 884 bytes
:-)

Pushing the new revision in a couple of minutes...

Very cool

So the 512 bytes binary pages (with seemingly 2048 bytes minimum) 
are a Windows thing?

Here's the library package I needed to install for 0MQ:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displaylang=en

There are newer versions. I don't know if they would work. Maybe 
they're needed if someone compiled 0MQ on them

ELF seems to be a bit smarter about page loading, it doesn't require 
explicit padding to page boundaries in the file itself, so can generate 
smaller exe. (It's possible with PE too with some hacking).

My client/server executables are 3 KB. That's two orders of magnitude 
smaller than REBOL. Who would have thought?

New revision pushed online.

:-) That's the good side of being closer to the metal.

Btw, the newer revision requires explicit calling convention to be 
added to imported DLL, see %red-system/runtime/win32.r

Windows DLL: stdcall
C DLL: cdecl (or stdcall if that's the required convention)

Yes, thanks

Btw, can't color the R letter in red in the Linux version, not sure 
it's possible at all to make ANSI sequences interpreted using only 
syscalls.

Probably depends on the terminal definition the system is running 
under (which can vary wildly)

Do you plan to implement #import for Linux soon?

Andreas is supposed to give it a try this week.

OMQ: still getting the same error message, got at least 3 versions 
of Visual C++ 2008 redistribuable package (added the one from your 
link too).

Odd; must be something else

very nice, doc. the ELF hello works like a charm here :)

Goog to know.

re the size of executables, for comparison: basic 0MQ examples ("hwserver/hwclient") 
written in C compiled & linked dynamically with GCC & gold on Linux 
are ~6KB in size.

The 0MQ error code function is called zmq_errno. If the error message 
is about zmq_err0 it seems the name is being truncated somewhere 
on Windows

This function differs in that it has no parameters, only a return 
value. Might have something to do with it

Actually, this name truncation is in the symbol table, so it's a 
bug in the Red code generator that doesn't disturb WINE if the function 
isn't called

Looking at the server.exe content, I see the zmq_err0 in the imported 
functions list. So it seems to be corrupted inside the executable.

The name is garbled from zmq_errno to zmq_err0

I'm looking into the linker to find the cause.

Found the issue: #define no 0 :-))

heh, good catch :)

The preprocessor is a bit too aggressive.

is it case-sensitive?

yes

yep

so sticking to the C convention of ALL_CAPS_DEFINES is probably a 
good idea (at least for now) :)

That would be safer, until we get a smarter one.

I thought about adding a full macros system, I think it will be useful 
until we can compose Red/System code from Red itself.

Right, I ran into the preprocessor zeal before, and replaced some 
other values with variables

Once that definition fixed in %ZeroMQ-binding.reds, I can compile 
working versions of client & server...testing...seems to work ok, 
the server is receiving a list of Hello messages from the client. 
:-)

Congrats!

Thanks :-)

Is the preprocessor necessary at all? It's usually much nicer to 
implement this functionality at a more integrated level in a language

I'm thinking about descending it one level below to process the script 
at block! level instead of string! level, after all, the compiler 
has the full power of REBOL.