World: r3wp

I believe that the same "get-word" syntax will be used should  function 
pointers be  introduced at a later date

Though neither of these items are on the current to-do list.

Maxim, that's the get-word! type. The set-word! type is used for 
assignment (setting).

I have already added the support for getting function's address using 
get-word! syntax (it returns an integer! value). Structs, c-strings, 
pointer are already passed by reference.

thx guys.

I'm a hudge militant of both the typed variable way (easy to interface 
C libraries) and the untype variable ( code more readable less maintenance 
etc...) This paradoxe tends to push me to imagine a world where the 
software will know what I need what ever the real sturcture behind 
is lets call it predictable type variable. How we do that ? I don't 
know but it seems fun enough to spend some brain cells  thinking 
of that. the idea is realy that interfacing external c/c++ java what 
ever library and maping it to the language innher variable and code 
will be absolutly transparent. (something like the .NET librabry 
browser but easier... Or more easyly we can have both system cohabiting 
side by side on the language schemes

though in rebol not having type for vars and () for function arg 
submition, make difficult to identify var content  distinguish var 
from function ... Maybe then  a syntaxique item like th e $ in php 
for vars or the @ in ruby for tables would be an interesting point... 
Sorry I try to think about rebol syntaxe structure like someone seing 
it for the first time

Shad, typed variables with type inference handles the readability/maintenance 
problem pretty well, which is why several statically typed languages 
have been retrofiting type inference into them recently. Fortunately, 
Red is planned around that from the start.


Your "predictable type variable" proposal (I don't know the standard 
term either) sounds useful. Many languages do this through reflection 
facilities, but that kind of thing requires dynamically typed variables 
at least as an option if you are going to use the reflection facilities 
of the language you are interfacing with - this is necessary for 
C++ at least because there isn't a shared standard for encoding that 
information in a static way. It would be more useful for integrating 
with .NET or CORBA objects, since direct field access is prohibited 
anyways for those so there's no extra overhead in the field access 
itself, just in the runtime discovery, and ahead-of-time static compilation 
has shared rules that work on a binary standard.

Somebody created an open source .NET Micro Framework port to Arduino 
http://netduino.com/netduino/specs.htm. It's an ARM7 based microcontroller. 
Is it possible that someday Red would be available on this platform 
(Reduino sounds really good)? Just dreaming... How would I start, 
if I could help?

Awi, that would be great, I would love to see Red run on such platform 
but I'm afraid Red's memory footprint would be a bit too high for 
a 60KB of RAM (but this might be specific to the netduino platform?). 
OTOH, Red/System compiler should work nicely there. If you want to 
help for such port, we need two things:


- a target file format emitter (I guess it would be the firmware 
file format)
- a native ARM7 code emitter as Red/System back-end. 


Let me know if you want to start working on these parts, I would 
provide additional documentations.

I think Red/System is already much better than .Net or C. I will 
look into both things you mentioned, but to be honest I have zero 
experience on porting. But let me see what I can do.

I think I am going to port Red to this USB key size platform, once 
available: http://www.raspberrypi.org

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