I would like to thank again people that donated to cover the costs of my trip, Brian "HostileFork" Dickens and Coginov in the first place, and all the others that have contributed. I have spent a great time in Montréal and met with lot of Red and Rebol coders, it was great to meet you IRL and spend a few days with you guys!
What's new in 0.3.3?
Java bridge
Since this version, Red is now able to interface with a 32-bit Java Virtual Machine through JNI, using a dedicated bridge written in Red, including a very small part in Java. This bridge allows Red programs to instantiate Java objects and call their methods from Red directly at run-time.
Instructions for using this bridge and compiling the hello example are given on this page.
Here are some screenshots of the resulting AWT hello app done with the Red/Java bridge:
Windows / x86
Linux / ARM
Android support
Red/System runs on Android since more than a year, but we were unable to access the Android API....until now. Thanks to the Red/Java bridge, an Android specific bridge has been made, in order to allow Red to call the whole Android API in Java. This is still alpha stuff, but it works really well, allowing you to build true native Android app in Red, without having to touch any Java code!
This is the hello Red/Android app screenshot, called eval, which simply shows a multiline input field where you can type any Red valid code and run it with the [Do] button. The last expression value gets printed below the button.
You can download the APK file (116KB) with the QR code on the right.
This is a proof of concept. Now that we know that this way works fine, we will continue to improve the bridge and add new layers of abstraction, in order to keep the low-level Java objects hidden as much as possible for the Red coders and replace them with DSLs and Red ports.
In order to build the eval demo app from the sources, just run the build script from a Rebol2 console.
Since a year, we were working on bringing shared library generation, now it is available in the main branch. New features were added to support library generation like a way to declare the exported symbols and special callback functions when loading and freeing the library. Here is a simple example of a Red/System library:
Red/System [
File: %testlib.reds
]
inc: func [n [integer!] return: [integer!]][n + 1]
#export [inc]
You compile such shared library using the new -dlib command-line option:
>> do/args %rsc.r "-dlib testlib.reds"
The output binary name will have a platform-specifc suffix (.dll, .so or .dylib).You can then load this shared library from Red or any other programming language having a good enough FFI. For example, from Red/System, it could be done as simply as:
Red/System [
File: %loadlib.reds
]
#import [
"testlib.dll" stdcall [
inc: "inc" [n [integer!] return: [integer!]]
]
]
print inc 123
This will print 124 when run.
Other Red language changes
- new action: insert
- new native: bind
- new mezzanines: system, any-series?, replace, zero?
- new bindings: Curses, ZLib, JNI, R3-extension
- finished interpreter by adding exit and return support.
- Function keyword now collects counter words from: repeat, foreach, forall.
- new #call compilation directive to enable calling Red functions from Red/System.
- paths now support get-words fully
- PIC support for both x86 and ARM backends
- Kernel driver compilation support (Windows only for now)
- improved function! pointer support, now they can be used as struct members.
- added new function attribute for dynamic calls: custom
- new compiler directive for exporting symbols: #export
- a way to manually align the native stack before making system calls: system/stack/align
What's next?
Android is becoming the dominant OS, so we need to have Red support it as best and as soon as possible. This remains a priority, so improved Android bridge and new sample apps will be available in the next releases. At the same time, we still miss some core features in Red, so these are the new features that you can expect in the next releases of Red:
- object support
- simple I/O support
- whole toolchain released as a single binary (encapped)
- PARSE support
- VID-like cross-platform dialect binding to native widgets.
- mezzanines function additions
We are now heading towards the end of the alpha tunnel, if you look well enough, you'll see the light already. ;-)
Enjoy!
Do you have an estimated time frame for the next release of Red?
ReplyDeleteProbably a month, I would like to move to binary releases, so as soon as that is ready, a new release will be out and it will probably be a 0.4.0 then.
ReplyDeleteThis is wonderful! ... Does "simple IO" include both File and Networking? or just File?
ReplyDeleteBoth file and networking I/O.
DeleteGreat work Nenad!
ReplyDeleteQuestion, if you go to binary distributions, that means Red will be out of the bootstrap phase?
Thanks iArnold. No, the binary distribution is just a way to have the Rebol2 interpreter + Red compilers sources distributed and used as a single binary, instead of downloading them separately and using front-end scripts for compilers. It is just a much more convenient way to use the current bootstrapped codebase. The selfhosting phase will be reached when both Red and Red/System compilers will be rewritten in Red itself.
DeleteNow the Red distribution is the same for any platform, with the selection of platform dependent part from the REBOL site. When you shift this to Red distribution you need to support these yourself. On the other side this would make Red look more independent from REBOL.
DeleteWe'll provide binary builds for each supported platform where the Rebol/Encap is available.
DeleteCongratulations Nenad - it's great to see your continued success!
ReplyDeleteGreat job Team!
ReplyDeletePaul T.
Great work Doc!
ReplyDeleteGreat! Nenad, expecting the 0.4.0 release!
ReplyDelete