World: r3wp

LOL

Crashes for me here Kaj. Looking for zmq_err0 in the dll (using 2.0.10).

Very cool though, assuming it works for you.

Gregg you have to run it under wine!

Wow Kaj, I'm impressed!! Didn't think that someone could push Red/System 
so far already! Great work!

while [yes = yes] 

 => this cries for a better logic values support ;-) I was working 
 on a TRUE/FALSE support in the train when coming to ReBorCon 2011, 
 but never finished it. I need to get back on it.

I can compile it with the last Red/System version (adding calling 
converbut I get a "zmq_err0 entry point not found". I guess, there's 
a regression in the compiler or an incompatible change. I'll check 
that after publising the new revision with extended Linux support.

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.