World: r3wp

Yes, but it requires me to install a lot of stuff...The real issue 
is that /Core is built on obsolete libraries version.

I know, but all operating systems should deal with backwards compatibility, 
and the Unixes usually do it with optional packages that you need 
to install

hmm, /core 2.7.8 runs fine for me on freebsd 8.2

let's see where those ancient libm/libc versions come from :)

compat6x-amd64-6.4.604000.200810_3 :)

So the compatibilty base seems to be FreeBSD 6

I tried: pkg_add -r compat6x-amd64 from http://www.freshports.org/misc/compat6x, 
but keep getting "unable to fetch messages".

Did I miss something?

are you on an amd64 system?

Are you on AMD64?

:-)

on Vmware

I guess it emulates an Intel CPU

uname -m ?

i386

works

should be just `pkg_add -r compat6x` then

thanks!

(or -i386 :)

nope, add to append -i386 :)

add => had

solves REBOL issues

Let see now if the compiler is running

hm, automatic creation of the builds/ folder bugs

Can you push a fix for that? (I'm cooking at the same time)

yep, will do

# 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.