World: r3wp

:-)

Rebpro binary provides the features I need without the View issues.

It's very debatable whether you would be exposing the REBOL API :-)

This is supposed to work, isn't it?

as-message: "zmq_msg_init_data" [  ; Convert to new message.
	message		[message!]
	data		[byte-ptr!]
	size		[size!]
	free		[function! [data [byte-ptr!] hint [handle!]]]
;	free		[handle!]
	hint		[handle!]
	return: 	[integer!]
]

Yes, it should work.

*** Compiler Internal Error: Script Error : compare-func-specs expected 
cb argument of type: get-word 
*** Where: check-expected-type 
*** Near:  [unless any [
all [
block? expr 
object? expr/1 
expr/1/action = 'null 
type: expected 
any-pointer? expected/1
] 
all [
type 
any [

How do you call AS-MESSAGE?

It's when passing it NULL:

either as-logic as-message message data size none none [

ah! :-)

Null is not a replacement for function!.

It does need to be in this function

That is to say; if a C function has a fixed parameter list, can it 
be called with fewer arguments?

I don't think so. The called function will try to get its missing 
arguments from stack anyway.

Then I need to pass NULL

You should make 2 bindings, one with function!, other with handle! 
(for passing Null). And a wrapper function for the latter one, to 
make it cleaner for the user.

I will look into the compiler internal error tomorrow, it needs a 
fix anyway.

OK

Will you implement it, or add a warning?

I need to see if extending Null to support function! pseudo-type 
is problematic or not.

Too late now, it will be on my todo list for tomorrow.

OK, I will also leave it 'til tomorrow

My radio just starts singing the same :-)

Doesn't it depend on the calling convention if you can leave off 
arguments?

Yes, it depends on the calling convention.

For example, if you encode the arguments number as the first value 
pushed on stack, you can pass a variable number of argument. The 
called function needs, of course,  to use the same convention.

freebsd with libc requires a bit more work

freebsd's libc expects two symbols already exported: environ and 
__progname

so for that we'll most likely require an "#export" directive or something

Bummer

Using Syllable as a development workstation for FreeBSD would be 
a cool feature :-)

well, i could hardcode a hack in the ELF emitter

If the hack doesn't disrupt too much the existing code, why not.

we'll probably want #export for shared libraries anyway

A Red-generated FreeBSD binary: http://bolka.at/2011/tmp/hello-fbsd.bin
:)

(And the hack that made it happen: http://pygments.org/demo/19023/.)

Cool :-)

size? struct! doesn't work yet:

#include %../ZeroMQ-binding.reds
print-integer size? message!
print-newline

*** Compilation Error: undefined symbol: message! 

*** in file: %/users/administrator/Red/Red-ZeroMQ-binding/examples/reply-server.reds 
*** at:  [message! 
    print-newline

message! is aliased in ZeroMQ-binding.reds, but it doesn't seem to 
carry over to the source file where it's included

The 0MQ binding should now be thread safe and release its allocated 
memory

Andreas: great!

Kaj: the compilation message there is wrong, the compiler wasn't 
expecting an alias name (but it should). I will fix that today.

Andreas: heelo-fbsd.bin works flawlessly on FreeBSD8.2!

Andreas: adding support for shared library is in my todo list for 
the next weeks.

Got my virtual struct! lib working ok. It is not perfect but should 
cover our needs for Red bootstrapping. Finally, we'll be able to 
get rid of /View.

Great!

Will merge it to main branch in a few minutes.