World: r3wp

nice machine... i would love to try

Neat gadget, but Ubuntu is going to bog it down

I would install a Damn Small distro instead.

doc: khm, u wanted to say syllable, right? ;)

Sure! =)

We'd have to port to ARM first

i was thinking about syllable server. what has to be ported on it 
to arm? if u ubuntu runs on this thing, then the kernel and c compiler 
shouldnt be an issue

no altme though... i can't use it as my development machine then 
;D

We've had a pattern of people who came to our mailing list shouting 
enthusiastically that they had found out that the "GNU C compiler" 
would compile to PowerPC or something, that they would compile Syllable 
to it over the weekend and report afterwards

We never heard from such people again

Sure most parts of Syllable Server have been ported to ARM in other 
projects, but porting the system will be many man months of work 
at best

thats why i was asking which parts are the problematic. i was just 
wondering if there is already an ubuntu running on that thing, then 
probably most of the build tools for syllable server are ready

It's not that any of the parts is particularly problematic, it's 
that it's an awful lot of work with today's software bloat

And if you don't know all the parts intimately, they can easily pose 
a big problem to a particular developer

ok, got it. i was building lfs back then , so i know what u r talking 
about

Then you know that the ports of LFS to various architectures are 
separate projects, that are partly rearchitected

i was just trying the x86 version, but i can imagine

It can easily take me half a year to create a next version of Syllable 
Server, and that's on the same architecture

Doc - there is many such small platforms, even x86 based IIRC. Gumstix 
is e.g. for real, a bit pricey, but definitely not vapor - http://www.gumstix.com/store/catalog/product_info.php?products_id=256

Right, but not at $25 (the one you posted is sold $229).

Right, but is sold right now, without the "we plan to develop" attitude 
:-)

I personally bought Beagleboard. Pandora Board might be even better 
....

Small enough for us.

I think we can have faith in David Braben

I have updated the 0MQ binding to the latest Red version, and moved 
it to a Fossil repository:

http://rebol.esperconsultancy.nl/Red-ZeroMQ-binding

Thanks, will test is tomorrow.

From sources: "libzmq.dll" cdecl [  ; stdcall for Windows? => should 
be cdecl, stdcall is used in Windows DLL (and rarely by C libs).

vsm-data1	[integer!]  ; unsigned char [ZMQ_MAX_VSM_SIZE] (default 
30)

 => we will need a better way to handle such arrays when interfacing 
 with third-party libs...

Yes

I found the same info that Windows system libraries use stdcall, 
but that MSVC defaults to cdecl. I had been compiling the binding 
with stdcall, and both work. I standardised on cdecl and retained 
the comment for the moment being

I'm getting this:

Compiling /users/administrator/Red/Red-ZeroMQ-binding/examples/reply-server.reds 
...
*** Compilation Error: invalid struct syntax: [pointer!]

*** in: %/users/administrator/Red/Red-ZeroMQ-binding/examples/../ZeroMQ-binding.reds
*** at:  [struct [
        content [pointer!]
        flags [byte!]

What's the new syntax for a pointer field in a struct?

pointer! [integer!]

Actually it isn't a new syntax, it's just that the compiler wasn't 
checking it deep enough until now.

Shouldn't an actual pointer! type be possible?

What you're saying, that's a pointer to an integer, right? But I 
need a pointer to a bigger memory area here

Pointer! alone is equivalent to an integer, it just represent an 
address, but can't be dereferenced.

If you are just passing the pointer! reference but never dereferencing 
it, you could just use integer! instead (or c-string!).

Yes, it's just to reserve the space for a pointer that's used by 
0MQ, but not by Red

I'm trying to use pointer! as much as possible instead of integer! 
because it makes clear that we're talking about an address size, 
not what happens to be the compiler's integer size

Agreed. You could also use aliased types for that: 
    handle!: alias integer!
or
    void-ptr!: alias integer!


Aliased typed are not yet fully supported nor tested, but it should 
work fine in your case.

Sorry, I meant:
    handle!: alias pointer! [integer!]
or
    void-ptr!: alias pointer! [integer!]

You might want to avoid using handle! for these, as it is the best 
candidate for the opaque-pointer-sized-value type in Red proper, 
that all of Red/System's pointer! types would appear to be when they 
leak into Red code.

Well, isn't that exactly the reason to use it?

I mean, don't use the word 'handle! as an alias because it will likely 
be a built-in datatype in Red, and in all Red/System functions and 
datatypes exported to Red.

But it would be exactly what you want, wouldn't it?

handle!: alias integer!

would override the built-in meaning of handle!. All code that uses 
that word would need to be changed when Red comes out.

Keep in mind that there is no bounds-checking for Red/System's pointer 
type, and Red/System has typecasting (rather than conversion). Neither 
of those would be allowed in Red itself because of typesafety issues. 
Red/System will be like the unsafe code of C#.