World: r3wp

Here a code example of how you could solve that:
	msg: receive ....
  	if zmq-error? [...process error...]


zmq-error? could just check a flag set by last zmq low-level calls.

Such constructs would make the binding a lot more high level and 
would require a lot more code. I'm trying to keep complexity down 
for simplicity and performance

calls => call

The added code won't make any significant overhead in performances 
for a network communication library, the slow parts are the network 
exchanges.

What bothers me most is the added complexity that doesn't really 
solve the problem. Error handling is often something that needs to 
be done locally, because that's where the knowledge is to handle 
the problem most gracefully

We don't have goto and longjumps, either, so there's little leeway 
for implementing a transparent error trapping framework

Btw, your code snippet could be rewritten as:

message: receive socket 0
unless all [
	as-logic message
	end-message message
	;wait 1
	send socket  as [byte-ptr!] reply  1 + length? text  0
][

 prin "Received request: "  print as-c-string message-data message
	print zmq-form-error system-error
]

Huh, I guess I have been too aggressive with the prin "..." line 
:)

If you want the function to return a logic! status and a result to 
be able to handle it locally, the result needs to fetched through 
a pointer, which also raises complexity. We can't handle addresses 
very well yet, either, because get-words only work for native functions

My point was: don't return a logic! statut from functions like RECEIVE, 
rather set a flag and check it after RECEIVE call.

statut => status

RECEIVE doesn't return logic?

That rewrite doesn't work. It mixes up successful and unsuccessful 
receiving

Yeah right, I was confused by your will to return a logic!.

I'm flexible. :-) Not everything returns logic, only the cases that 
can

I'll just rewrite it in EITHERs for now. I'm just noting that it 
can be made very nicely REBOL like to distinguish Red/System from 
C

By the way, 0MQ is not a network communication library per se. It 
can do messaging equally well between processes and even threads, 
so wrapper performance is significant

x: does []
either true [x] [x]

*** Compiler Internal Error: Script Error : equal-types? expected 
type1 argument of type: word
*** Where: comp-either 
*** Near:  [last-type: either equal-types? t-true t-false]

Regression from a recent change, you should get a compilation error 
saying that x is missing a return value.

In this case, I don't need EITHER to return a value

The crash is on the EITHER not on the DOES

Ok, so sounds like a check that shouldn't happen in such case.

Could you post this error (and future others) to github's tracker 
please? It is easier for me to manage them there.

I won't like loosing the comfort of AltME, but I'll try

Thanks.

I've put it in there, but I won't be able to follow the discussion 
much

It is more a matter of tracking than discussing.

It is also easier for others to follow current issues publicly.

I understand; it's just a rotten situation that the communication 
isn't integrated

We have #red-lang on Freenode for that. ;-)

I don't do IRC, either. It's not integrated, just more fragmentation

What is AltME integrated with?

The REBOL community?

Boron is using all the right open source buzz words, except AltME, 
and look what traction it got

I'm not sure that you can associate Boron's lack of popularity with 
the fact that Karl does not use AltME.

Maybe, but I can associate my misgivings with communication systems 
that make you jump through hoops

Do you mean the Boron mailing list?

Mailing lists are among the worst, yes

Ah, the unintegratedness begins. When I type >> in GitHub to denote 
a REBOL result prompt, it interprets it as indent markup

If you had told me twenty years ago that I would be writing prose 
such as "Local logic! in prin-int leaks as global function!", I would 
have seen it as a sure sign of dementia

I implemented error checking in the 0MQ examples. It has revealed 
three bugs in Red

It has exploded the code, though. It's quite ugly and inefficient

Keep up the good work Kaj!

Thanks, I intend to

Karl has failed to engage with the Rebol community as far as I can 
see.

Kaj: thanks for the reports. I was aware of NOT issue and already 
encountered the local name clash, but never got the time to isolate 
it. Fixing them now, before going beta, is a good timing.

So we are going beta soon? :-)

Red/System will go beta as soon as I:
- fix the remaining bugs from the tracker,

- decide on 2 last syntax issues discussed on the ML (concerning 
struct/pointer literal syntax and aliases)
- make a pass on the specification to fix/update/complete it.

It could happen today, but I will be probably too busy with other 
non-Red tasks.