World: r4wp

%version.r is a data file used by Red compiler, it's not for decoration. 
;-)

You should start Red and Red/System compilers from the console as 
explained in the docs, paths are sensible as long as you start it 
from "sources". Once we get it encapped, it will be much simpler.

btw - -= Red Compiler =-
Compiling /C/!rebol/!red/red/red/tests/hello.red ...

*** Compilation Error: comp-literal: unsupported type 14-May-2013/13:24:25+2:00
*** in file: %/C/!rebol/!red/red/red/tests/hello.red
*** near: [14-May-2013/13:24:25+2:00]

There's no date! type in Red yet.

well, I just tried to run hello.red, nothing more :-)

So demo.red and hello.red are not supposed to work yet? Or am I doing 
anything wrong?

OK, deleted the repo, resync, now it compiles ....

I don't know where you got those dates from, but certainly not from 
Red github's repo.

Are you using a tool that messes up Red file headers?

I still don't know, how to properly work with Git. I use Windows 
Git, nice looking app. But when I switch between the branches, I 
fear it mixes the files? It syncs various branches into the same 
dir .... not sure that was the problem, though ....

I have no such issues with TortoiseGit.

Switching to any branch from same folder.

The only time when the switching fails is when a versioned file is 
locked by an app (like a code editor sometimes).

I used tortoise git on my old notebook, now I am using Windows Git. 
There was simply something messed with my files, could not even compile 
Java bridge example. Now everything works again ....

Red/Java bridge prototype released: 

https://github.com/dockimbel/Red/tree/dyn-lib-emitter/red/bridges/java

This is a higher-level API for controlling Java from Red. Please 
read the commit log:

https://github.com/dockimbel/Red/commit/5d43ad443a0524f91418fe62c0f5e90e3d143f75

I've ported the JNI low-level hello example to Red, see how it looks 
now:

https://github.com/dockimbel/Red/blob/dyn-lib-emitter/red/bridges/java/hello.red

Though, this is not the final API I have in mind for Android, as 
I want a cross-platform API.

The API will probably slightly change in the next days as I refine 
and improve it.

(Constructive) feedback is welcome.

This bridge will be the foundation of Red complete port to Android 
even if most of Red developers on mobile devices will probably never 
have to go down to this platform-specific API.

Is the Android GUI AWT?

Nope, AWT is an old GUI built-in Java, so it's handy for doing simple 
GUI demo.

I thought so

I will do a prototype wrapping of the Android GUI API in a few days, 
so you'll be able to put your VID-like dialect on top of it. ;-)

Nice

Yes, very cool.

Would it be possible to have #export work not only on libraries, 
but also executables?

PicoGL is a library that defines four or so functions in which an 
OpenGL program should be defined. Although PicoGL is a dynamic library 
loaded by the program, it expects the program to provide those functions

#export adds a few bytes to a program not compiled as a library, 
but it doesn't export the specified symbols

I've already reimplemented the main event loop inside PicoGL that 
wraps the user functions. This makes it work on Linux, where the 
loader doesn't seem to mind that the library can't resolve the user 
functions. On Syllable Desktop, the program still won't start on 
account of the missing symbols. I don't know about other platforms

I have some issues understanding Git again. There is apparently new 
help file for java bridge, as shown in above linke commit, but I 
can't see the changes reflected, when looking into file via files 
section, nor does it sync to my desktop ...

Hmm, new commits are in different tree, not merged into dyn-lib branch 
yet?

#export for executables: I guess we could support it.

Pekr, everything is fine on github repo, new commits are in dyn-lib-emitter 
branch.

How is that I can't see e.g. bridge.java in here? https://github.com/dockimbel/Red/tree/dyn-lib-emitter/red-system/bridges/java

I can get to it only via your second posted link, which instead of 
dyn-lib, shows "tree: 5d43ad443a" ....

one is red and one is red/system

OK, now I can see that. So we will have two bridge directories? I 
thought red-system one is going to disappear, but maybe it make sense 
the way it is, as users might want to work with red-system only?

For now I will keep those different layers in different folders.

ok, ran the example, making screenshot, posting to FB group :-)

Great! :-)

Doc, tried to clone your examples, so that I could do some first 
tests by trying to adapt your code, I got into strange problem. I 
copied your hello.red into pekr.red and generated the pekr-lib.dll. 
Changed bridge.java to load pekr-lib.dll. And - it works. However 
- when I tried to clone bridge.java into pekr.java, or simply change 
"class bridge {" to e.g. "class fridge {", to generate differently 
named java app (fridge.class), it does not work. Is bridge class 
somehow hardcoded somewhere in the API?

btw - I was able to add the button:

        button: java-new [
                java.awt.Button
                "Test"
        ]
        java-do [frame/add button]


.... but then label does not display :-) The layout manager probably 
needs different technique to work with. Btw isn't AWT really old, 
something like 1995? :-)

Now question to API. On SO I found comparisong of AWT vs Swing:

... to add a child to an AWT frame you'd write:

   frame.add(child);   


However using JFrame you need to add the child to the JFrame's content 
pane instead:

   frame.getContentPane().add(child);  


How the above function could be invoked via API? Would java-do [frame/getContentPane/Add 
...] work?

I think you'd have to split it. Get the content pane object first 
with java-new

Or perhaps two java-do's in a row should do it. I'm not sure how 
to pass the child object, though

Is bridge class somehow hardcoded somewhere in the API?


Yes, that's a Java/JNI requirement. The name of exported symbols 
from the shared lib have to include full Java class names. Do not 
change the name of Java classes in bridge.java.

Btw isn't AWT really old, something like 1995? :-)

 It came with the first versions of Java, when the technology was 
 meant for Applets only.

Would java-do [frame/getContentPane/Add ...] work?


No, as Kaj said, you need to split it in two parts. However we could 
extend the API to handle sur syntax, but at this point, it would 
be overkill.