World: r4wp

If you want to compile PicoGL, on Syllable Server or some other Linux 
system, you can use the Syllable build system. Here's the build recipe:


http://syllable.cvs.sourceforge.net/viewvc/syllable/syllable/system/apps/utils/Builder/packages/PicoGL/

Not sure if this is useful for Android, but the JVM JNI interface 
can be loaded as a library from a normal executable:


http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/invocation.html


I've added a static JVM binding to my JNI binding for Red/System, 
so Java can be loaded and controlled from regular Red executables:

http://red.esperconsultancy.nl/Red-Java/dir?ci=tip

I made an SDL backend for my Red/System OpenGL binding:

http://red.esperconsultancy.nl/Red-OpenGL/dir?ci=tip


SDL with OpenGL is available on most platforms, and depending on 
your system, it supports hardware acceleration. So you can now choose 
between software rendering with the TinyGL engine through PicoGL, 
and hardware acceleration or software rendering with the Mesa3D engine 
through SDL. The two example programs can be compiled with either 
backend.

I made an OS-Mesa backend on SDL for my Red/System OpenGL binding:

http://red.esperconsultancy.nl/Red-OpenGL/dir?ci=tip


This does off-screen rendering in a memory buffer using the Mesa3D 
engine and then displays the result using SDL. Somehow I can't get 
it to work on Linux, but it's the first time I can use Red/System 
for OpenGL on Syllable. It circumvents two problems: the PicoGL library 
expects application functions that Red doesn't export, and Syllable's 
SDL port doesn't support the official OpenGL backend, so those routes 
both don't work. For most other targets than Syllable, the official 
SDL backend can be used.


It's also the first time that I have used my Mesa3D port to Syllable. 
I couldn't display the output before, because there is no display 
driver for the current Mesa3D versions for Syllable, just the standard 
off-screen rendering. It works great, even though it does only software 
rendering. PicoGL is a bit faster, but Mesa3D is a much more modern 
and complete OpenGL implementation.

I've added binary downloads for all Red platforms to the test repository 
of the two OpenGL examples for the Red/System binding: GL-spin and 
GL-textures.

http://red.esperconsultancy.nl/Red-test/dir?ci=tip


Test reports welcome. All platforms should work in theory, but so 
far I have tested Syllable and Linux x86. You need to have SDL and 
OpenGL installed (in 32 bit versions). SDL is included in the repository 
for Windows, and OpenGL should be included in Windows.

If you use the download.r from the repository (with Fossil), you 
will now get the source code for the OpenGL and Java JNI bindings, 
together with all my other bindings

I added a similar workaround for ELF libraries as in Doc's JNI bridge 
to my R3 and JNI bindings:

http://red.esperconsultancy.nl/Red-REBOL-3/dir?ci=tip
http://red.esperconsultancy.nl/Red-Java/dir?ci=tip


R3 extensions written in Red/System and Red now work on ELF platforms 
such as Syllable and Linux. Should work on Android, too, at least 
when Doc has tested libraries there.

https://github.com/saphirion


We are going to push some of our stuff to Github. This is intended 
so that peple from the community can use and enhance our stuff and 
submit pull-requests to us. Those pull-requests will be reviewed 
by the Saphirion team, and if accepted, the changes are merged into 
our main line. So, it will be included in our next offical release 
and published via our web-site.

The first thing we start with will be a bunch of documentation files. 
All written in MDP format. These are the files, from which the documentations 
on our web-site are dynamically generated from.

The structure for documentation is:
documentation/ 	= stuff that works on R2 and R3
documentation/r2	= stuff for R2
documentation/r3	= stuff for R3

So, feel free to do whatevery you want with this stuff and help to 
improve it.

I fixed the calling convention for the OpenGL library that's included 
in Windows, so the Red/System binding works there now:

http://red.esperconsultancy.nl/Red-OpenGL/dir?ci=tip

I also fixed the binary downloads GL-spin and GL-textures:

http://red.esperconsultancy.nl/Red-test/dir?ci=tip

Another "batch" of doc files committed. See e.g.:


https://github.com/saphirion/documentation/blob/master/r3/whatsnew.mdp

, which tries to compare R2 and R3, which was a popular request.

New World alpha at
https://github.com/Geomol/World

Let me know in #World group or private, if there are problems.

Carl's REBOL blok - Roku - http://www.rebol.com/article/0529.html

I dropped the cURL dependency from my red-base distribution. This 
means that it now only depends on a few libraries that can be expected 
to be included in all platforms. This version of the Red interpreter 
can now be used on Windows as a single executable, without any extra 
libraries. The Windows version red-base.exe is here:

http://red.esperconsultancy.nl/Red-test/dir?ci=tip&name=MSDOS/Red


It has versions of READ and WRITE for local file I/O, but no network 
I/O. It also has the other functionality from the C library, such 
as INPUT, ASK, GET-ENV, CALL, NOW and RANDOM, but for more functionality 
you still have to use red-core and red, and download the extra libraries 
for Windows.

Ok, Carl is now on Stackoverflow chat .. just need to upvote him 
somehow so he can actually talk!
http://chat.stackoverflow.com/rooms/291/rebol-and-red

I'm happy to announce that we reached a major milestone and can release 
a bunch of new things. All the different versions have been merged 
into one code base which makes things easier for us. This was possible 
because the new 'retargetable' graphics subsystem was finished. This 
allows us to port R3 to other platforms much easier. Next target 
Linux. The release in detail:


R3-GUI: Quite a lot of fixes and enhancements. Thanks for all the 
feedback. The main milestone we achieved was to switch to a resolution 
independent sizing system. This will scale your app widgets to look 
the same on different display densities. It's a must have for mobile 
apps. Next for R3-GUI is to create a simple mobile style set. Fruther, 
we are going to push the source code to GitHub. We need to setup 
a bridge to our internal SVN repository, so expect some back and 
forth on Github before we are stable.	Anway feel free to help making 
R3-GUI better and better.


Android: This release is now mostly the same as the windows release. 
So, yes, it's now possible to do R3-GUI apps on Android. I'm going 
to try to run Treemapper on it. Type DEMO to see the new R3-GUI version 
and widget scaling feature. Post as much screenshots / pictures of 
your phone as you can :-)


R3/Saphir: New version for windows with bug-fixes are released as 
well. Please see the change-log on our web-site for details.


Thanks to all the team for the great work! I really think we are 
close to have a very good and stable base with R3 and R3-GUI. Looking 
forward to see more and more people joining and becoming part of 
it.

Links:
http://development.saphirion.com			(Change Logs, Downloads, etc.)
http://development.saphirion.com/experimental	(Android)
https://github.com/organizations/saphirion		(Documentations)

Hi,

 I paste the link: https://github.com/organizations/saphirionin Firefox 
 and the main page of GitHub open. I see no Saphirion repository.

Correct Link:
https://github.com/saphirion

R3/Saphir: Core now builds again on OSX.

You can find it at: http://development.saphirion.com/experimental

R3/Saphir OSX Version updated, should now work on OSX from 10.4 on.

R3/Saphir OSX Version updated, should now have working HTTPS scheme.

Announcing changes to Saphirion doc:


Function arity documentation and Argument passing styles documentation 
now adjusted to document both R2 and R3 versions. See

https://github.com/saphirion/documentation

I set up a Youtube account under the name of REBOL Coder using the 
gmail account [RedREBOLs-:-gmail-:-com]. I added a small number of youtube 
Red presentations. http://www.youtube.com/channel/UC4UikCida6olTyowsi5JyyA

As it is an extra channel I think about sharing this account with 
interested from the community.

Robert, thank you for the improvements and progress with Android 
(sorry, I've been away from AltMe for a while)

@Arnold What about  http://www.youtube.com/playlist?list=PL595BBBBC4CD91581
?

What a bad choice of color for your name - I just can't read it ... 
is it from Aries ?

I'm happy to announce that we made good progress regarding the Android 
R3 encapper.


A major breakthru in the multiple-app generation has been made (thanks 
to Andreas for ELF format hints). Now it is possible to create encapped 
apps with unique app-id. Such apps can be recognized properly by 
the Android OS and also accepted on the Google Play market.


The cool thing with this approach is one really don't need anything 
more than the Android encapper to produce the apk file. No need for 
android NDK, SDK or even JAVA to be installed ;-)


There are some glitches we are going to fix and than the encapper 
is ready for production.

For an example see http://development.saphirion.com/experimental/encap-demo.apk

Makedoc for Rebol3 from Chris http://chat.stackoverflow.com/transcript/message/10001554#10001554

My Redis scheme was updated heavily and I hope it's ready for use 
by others. You can find it here: https://github.com/rebolek/prot-redis

I wrote a quick & minimal example illustrating how to use R3-GUI 
together with R3's async HTTP:

https://gist.github.com/earl/447e4e9510a68c308f6b

I changed the Red 0MQ interface to optimise the memory use during 
receiving of messages:

http://red.esperconsultancy.nl/Red-ZeroMQ-binding/info/2a1541af57


SEND and RECEIVE have been renamed to send-string and receive-string, 
because they currently handle messages as UTF-8 text. When Red gets 
a binary! type, versions for binary messages will be added, and there 
will probably be type agnostic SEND and RECEIVE wrappers again. Previously, 
you used

message: receive socket


to receive a string message. Now you pass a premade string! (similar 
to call/output in R2):

message: ""
receive-string socket message


This means that you can choose between creating new strings for each 
message (with COPY) or reusing the same string. In the latter case, 
some Red/System code in receive-string makes sure that no extra Red 
memory is used, and that all used system and 0MQ memory is freed 
again. By optimising memory use, this also improves performance of 
message throughput.

This work will be paid for by Respectech as part of an assignment 
I'm doing for them. As far as we know, this is the first commercial 
assignment done with Red.


I'm implementing a network server that needs to run for long periods 
and handle relatively large numbers of requests. This is tricky because 
Red has no garbage collector yet, and the memory allocator doesn't 
handle large series yet. We have been testing the memory system to 
scale it, and Doc has fixed an allocator bug so that series can now 
be twice as large. I've also found and reported seven other bugs 
so far.


The results are very encouraging. The memory system is reliable in 
my stress testing. It can use all the memory available in a machine 
for the contents of series. In the default configuration, one series 
can have a maximum content of 2 MB, or 131070 values for a block!. 
This can be enlarged, basically at will, by compiling your program 
with customised allocator settings.


To reduce the amount of memory that currently cannot be reclaimed 
by garbage collection, I am reducing the number of series generated 
during the handling of each server request. This can be done within 
the same Red program, because low level optimised Red/System code 
can be inserted anywhere. I am down to only a few hundred bytes per 
handled request, and the memory budget of the server is a GB, so 
the Red 0MQ server will be able to handle several million requests.

For relevant platforms, I added extra versions of my Red interpreter 
console distributions to my downloads:

http://red.esperconsultancy.nl/Red-test/dir?ci=tip


They provide versions that include my 0MQ binding for messaging. 
Previous interpreter distributions didn't include it, because on 
most platforms, you have to install the 0MQ library as an extra. 
Further, people may need 0MQ with the GTK+ GUI binding, or without 
it on servers and embedded systems. So there are two new distributions 
in each platform folder:

*/Red/red-core-message
*/Red/red-message


red-core-message is meant for servers and includes bindings for the 
C library, cURL, SQLite and 0MQ. In addition, red-message also includes 
the GTK binding and is meant for GUI programs. For Windows, most 
of these interpreters are in the MSDOS/Red/ folder, but I also added 
a version that is meant to start scripts for GUI programs, so it 
doesn't open an extra console window:

Windows/Red/red-message.exe

As an example, the interpreter to run messaging scripts on a Raspberry 
Pi without GUI is here:

Linux-ARM/Red/red-core-message


The interpreter to develop GUI scripts on x86 Linux to communicate 
with a Raspberry Pi is here:

Linux/Red/red-message


A similar interpreter to develop GUI scripts on Windows to communicate 
with a Raspberry Pi is here:

MSDOS/Red/red-message.exe


As always, for Windows you also have to download the libraries that 
are included in the repository, according to the instructions here:


http://web.syllable.org/news/2012-11-18-20-47-Red-high-level-programming-language-first-alpha.html

In addition to these added programs, the existing interpreters and 
other programs have been rebuilt with the latest Red enhancements, 
including the doubled maximum size for series.


These new Red interpreters are candidates to be used in filming and 
streaming the presentations on the DevCon in Montreal.

https://github.com/saphirion/includerepository created, containing 
the %include.r and %include.mdp files

Ladislav, couldn't you convert the docs to markdown into a file called 
readme.md so that they are visible by default?

Added 2 more video's to the RedRebols channel http://www.youtube.com/channel/UC4UikCida6olTyowsi5JyyA

I forgot to tell about not requiring a specific return, not needed 
to declare types and use of normal naming is encouraged and the automatic 
casting of the return value. Need to make a [3.5] too someday..

Video number 5 posted. This one uses routine to call a Red/System 
function from a Red script.

I'm happy to announce that Doc and I got the first Red/System kernel 
driver working, for Windows. This is Doc's second kernel driver, 
and my first, and also my first real Windows program, so it took 
a few weeks to figure it out. This new ability of Red is sponsored 
by Respectech. Our test driver just loads and prints a Hello World 
style message that a kernel debugger can view, but I will be developing 
the driver into the functionality we need for our Respectech project. 
I will post the code of the test driver in the Red group.

This replaces the Windows Driver Development Kit (WDK) that you normally 
have to install on Windows to compile drivers. The WDK is a full 
CD download, 650MB. You don't need the WDK, but currently, you do 
still need to run the Red/System compiler on Windows (or WINE on 
Linux) to compile Windows drivers. This limitation will be removed 
later, so you will be able to cross-compile Windows drivers from 
all other Red platforms, like you can with other Red programs.

You should be able to compile the test driver with the latest Red/System 
development version, following the normal build procedure but adding 
the following parameter to the Red/System compiler command line:

rsc.r -t WinDRV driver.reds


This effectively replaces a makefile build script that the WDK uses 
that is almost 12,000 lines.


By the way, the WDK is unable to work in a path that contains spaces, 
so for example on older Windows versions such as XP, you can't develop 
drivers in your home directory, because your home path always contains 
spaces. I think Red will now allow you to do that.

You will get a driver.sys file that you can install, start, query 
and remove like this, from a Windows account with administrative 
rights:


sc create hello-Red type= kernel binPath= C:\full\path\to\driver.sys
sc qc hello-Red
sc start hello-Red
sc query hello-Red
sc delete hello-Red

To view the debug message generated by sc start, you need to install 
a (kernel) debug tool such as DebugView, and enable kernel debugging 
in the Windows boot options.


Other than that, you should see sc query showing the driver as running.

Red has a new platform, Android for x86 processors, so I added it 
to the downloads of example programs:

http://red.esperconsultancy.nl/Red-test/dir?ci=tip


The Android programs for both ARM and x86 include the recent fixes 
to the Red Android port, so they have a better chance of working 
now. I would still like someone to test them.


All example programs for other platforms have also been rebuilt with 
the latest Red enhancements and fixes.

Remember Doc's instructions for running command line programs on 
Android:

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