World: r3wp

It's nicely integrated with Lua. Doc has a similar plan for Red, 
and I'm also looking in that direction

I've published the map bindings here:

http://red.esperconsultancy.nl/Red-GTK-Champlain

http://red.esperconsultancy.nl/Red-OSM-GPS-Map

Hi, I am interested into building an maintaining documentation for 
those programming languages based on REBOL.
It would be nice to have a DOCBASE for them.
What I search is:
- Someone ABLE to SETUP the Linux and the Wiki Software
- Someone which would share with me the cost of hosting.
Do you like the idea ?
Write me at [giuseppe-:-chillemi-:-eu]

I want to help with that too, when time allows, but I think we need 
the authors of the languages to be part of the decision of how it's 
done. If they all want to do it different ways (and we want their 
input), that may be difficult.

Hosting should be very inexpensive, and I am willing to help with 
that.

Hope all of the authors see the advantage of having a common infrastructure 
for documentation.

There is advantage, but also cost. I know I don't want to add any 
more tools, formats, and logins than necessary to my workflow.

I think, it's a good initiative, but I can't judge, if it's a good 
idea, because I know too little about the different variants. How 
similar/different is Red, Topaz, Boron and World, and how are they 
compared to REBOL? Would the docs help a developer, or would they 
cause more confusion? It probably depends on the form of the docs 
too. Examples would help.


I plan to write a manual for World, something similar to "The C Programming 
Language" book. And that's not a dictionary, so there is good room 
for docs by others without overlap. And also docs, which are not 
just a dictionary, like extensive examples with explanations and 
probably other kinds.

See #Boron group please.

I am trying to import zlib and had some minor success with an example 
for adler32 function.  Next was compress and now stuck on how to 
align the compress function ZEXTERN int ZEXPORT compress OF((Bytef 
*dest, uLongf *destLen, const Bytef *source, uLong sourceLen));  
 from http://www.zlib.net/manual.html#Utilityis ByteF * 
dest and Btyef * source pointers to bytes  defined was destination 
[pointer! [byte!]]     ?

AFAICT, yes.

Thanks Doc.   It is enlightening to see what can be done with Red 
import and DLLs.

Doc, any news around? :-)

36 failing math tests to fix before finishing the ARM port.

I will write a new blog entry once that done.

Red/System ARM port now passes 100% of 8537 unit tests!

cool :-)

I have some polishing to do before making it official.

wow... (about ARM) !! does this mean it can run natively in something 
like android?

Yes, there's some screenshots in recent tweets on http://twitter.com/red_lang

But it only runs in command-line mode for now, a Java bridge will 
be required to produce GUI apps on Android.

So, what will be next?

that is awesome, making bindings to api-s is rewarding by itself 
(because you get to see results/apps) to those that need it so now 
that core runs on it I am sure rest will follow.

how is this java bridge made then? is it like some sort of native 
binding or some totally different concept?

Congratulations Doc!

Next for mobile ports:: add shared lib generation support to Red/System 
and Java/ObjC bridges.

In the next days, I will review all the priorities and I will publish 
the requirements for floating point support in Red/System. I will 
probably go back to Red runtime implementation next week until new 
year.

Congratulations Nenad. I hope you're going to take a few days off 
after such an intense effort.


Great timing too! Just in time for the launch of the Rasberry Pi!!!

Thanks Peter. New year is usually a very productive time for me, 
so don't count on me to rest now. ;-)

Doc - thanks for adding Twitter feed directly to RED website :-)

All my test scripts are now working correctly on Linux/ARM, including 
Red's memory allocator.

Cool, I might dig-up my Beagle Board :-)

You'll certainly have some fun. :-)

Is there possible something like CALL in Red/System? I expect currently 
"no", so what's the right aproach to it? Map system calls via wrapping 
an OS libary? Do you plan to have something like CALL to have easy 
interfacing along with PARSE in Red level? :-)

CALL support: sure, that's on the roadmap, but it's not a required 
feature in Red/System to implement Red, so not high-priority. I might 
add it if we really need it for a demo though. Anyway, it's pretty 
simple to implement, so I'm expecting some contribution there. ;-)

You can wrap the C system() function for a poor's man support.

is it possible to get guide for new bees and info on the IDE.... 
from reading it looks like the GUI will be gtk+

Sorry, no IDE available yet. For the GUI, gtk+ support is quite advanced, 
I might use it for the IDE if I run out of time to implement my own 
library.

My C library binding has a basic CALL using system()

It's effectively call/wait. It may help to remember that the binding 
is complete at the ANSI C level

http://www.red-lang.org/2011/12/arm-support-released.html

congrats :-)

WOW! Great!

I have just successfuly run Hello world example on my HTC Sensation 
:-)

What was the script called, which measured REBOL CPU power? It would 
be nice to have it, to measure performance of RED on various phones 
:-)

Perhaps, a line needs to be rephrased: "Such approach will allow 
us to build easily Android apps without having to write a single 
line of Java or Objective-C code" - AFAIK, Android apps are not written 
in Obj-C?

Obj-C stands for iOS imo ...

(people on OSNews will be all over it, if they see it)