World: r3wp

# builds/hello 
ELF binary type "0" not known.
builds/hello: Exec format error. Binary file not executable.

Have you pushed your BSD-specific ELF fixes or does it require a 
proper target config?

I think FreeBSD's ID is somewhere around 5

nope, i didn't push the freebsd emitter hack mainline

that just hardcoded freebsd-specifics, so would have broke linux 
in that form. only a quick experiment to see what's really necessary

Could you parametrized those BSD-specific changes with a compiler 
option?

Kaj: SIZE? has been extended to work with datatypes and aliases.

Thanks! That will make my struct allocations less haphazard

Andreas, thanks for info.

Kaj: Null allowed as a function! argument. The changes was very trivial, 
but I tested only if it compiled.

Thanks again!

Test it first before thanking me. ;-)

Will do, but I'm batching the updates :-)

Well, I guess that we should start to do the same with Red/System 
very soon.

You mean releases?

Yes, I mean, splitting into two branches: one for current version 
(fixes only) and one for the next version.

And make versioned releases.

That would be good for the public. Myself, I would probably keep 
updating from trunk. I'm running a Git download through my Syllable 
build system to install a new version

Added a bunch of convenience wrappers to the 0MQ binding, to make 
functions more Red/REBOL like

SIZE? of this struct works, but it is given as 40:

message!: alias struct! [
	content		[handle!]
	flags		[byte!]  ; unsigned char
	vsm-size	[byte!]  ; unsigned char

 vsm-data1	[integer!]  ; unsigned char [ZMQ_MAX_VSM_SIZE] (default 
 30)
	vsm-data2	[integer!]
	vsm-data3	[integer!]
	vsm-data4	[integer!]
	vsm-data5	[integer!]
	vsm-data6	[integer!]
	vsm-data7	[integer!]
	vsm-data8	[integer!]
]

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.