World: r3wp

Apparently, the two bytes are combined into one 32 bits word. Shouldn't 
they both be aligned?

The new size? struct! and null function features seem to work

Bytes don't require alignment, 32-bit values do. In message!, vsm-data1 
is aligned on a 32-bit boundary, leaving a 2-bytes hole after vsm-size.

You could compensate for that by splitting vsm-data8 in 2 bytes values, 
so that the global size remains the same as the C struct. The cleaner 
solution should be to introduce an array! type, which we will do 
at some point.

OK, thanks

I like the enhanced type casting syntax

It solves the problem that you don't know how to write a cast because 
in for example

as [handle!] x

handle! is a #define

I'm getting this:

*** Compilation Error: more than one expression found in parentheses

That seriously limits the usefulness of ANY and ALL

How does that limit ANY and ALL?

unless all [
	(
		message: receive socket 0
		as-logic message
	)(

  prin "Received request: "  print as-c-string message-data message
		end-message message
	)(
		;wait 1
		send socket  as [byte-ptr!] reply  1 + length? text  0
	)
][
	print zmq-form-error system-error
]

That's how I always use them

You can't do such construction in Red/System.

Right, that's what I mean

Assignments can't be used inside an expression, nor can functions 
that don't have a return value.

Btw, allowed expressions are now documented: http://static.red-lang.org/red-system-specs.html#section-5.1

Any plans to support this?

Red/System is not meant to be a REBOL replacement, you will need 
to wait for Red.

But isn't that the point? :-) There are no replacements for REBOL 
at all, and we can't wait any longer

Red/System cannot be a REBOL replacement, it doesn't live at the 
same level of abstraction.

I know, but this one is very doable. I guess it would be a nice project 
for Brian

I could remove the compiler check, so that your code "might" compile, 
but that opens a hole for several others issues.

That compiler check has been added to solve the issues reported here: 
https://github.com/dockimbel/Red/issues/93

assignements don't return a value in Red ? 
It should be doable without pain.

Currently, no.

There is a possible evolution documented in the specification for 
that, allowing also multi-assignments as a side-effect.

a cool side effect

Yeah :-)

It sort of pulls the base out from under my efforts to wrap all external 
functions to return logic!

You could just write wrapper functions.

I did, but after that, I was expecting to plug them into ANY and 
ALL :-)

or use logic! as return value in the imported function definition?

(as return type)

No, we discussed that

I don't remember the conclusion?

Only possible when the #import returns 0 and 1 exactly

Ah right!

Anyway, returning 0 for succes is unnatural for humans, but very 
natural for C. If there is no REBOL like way to process the reverse 
logic! return, the C way becomes more attractive, and the code shifts 
towards C instead of REBOL

I still don't get why you can't solve that with wrapper functions?

How do you mean? Writing three extra functions just for that one 
ALL expression?

I mean writing wrappers for low-level ZMQ imported functions, so 
that they return consistent values. For example, RECEIVE should return 
a message! or null, but not a 0 that needs to be casted to logic!.

I did. NULL also needs to be cast to logic

Also, those wrappers could handle the low-level ZMQ errors, so that 
the user don't have to do it.

No, because there is no standard for error reporting, like in REBOL. 
You have to do error trapping the C way

I just mean findind a way to catch those 0 values transparently.

There is no 0, only NULL, and this is my attempt at implementing 
the error catching, transparent or not

I know you don't want more changes before implementing Red, and that's 
fair enough, but this is something we'll need eventually