World: r4wp

well, you have Rebol installed and linked to .r ..... I am so much 
used to work with Total Commander, that I launch Rebol from icon 
sporadically. The trouble for me, is the path. So from time to time, 
I place kind of empty run.r script in some dir, which serves for 
nothing more, than just pressing enter upon it, and being run in 
particular directory, which means, in certain directory path

and I can find red.r in the main directory. Whne I hit enter, it 
just launches the console. But maybe I am missusing it :-)

that is why I thought that having red-system.r in the red-system 
subdir, would be handy. Than the examples in docs might be run without 
the proper path obstacles

I am not sure I am clear on my intentions :-)

or just bad habits ...

Also I would change version.r to either version.txt, or its content 
to:

REBOL []

print 0.3.2
halt


... so that by hitting enter or double clicks, it shows the version, 
not error ... well, just imo ... those are all absolutly minor concerns 
though, but would probably help to smooth the experience ....

But maybe you guys don't have .r associated with R2 interpreter?

I never use the association, I always start Rebol scripts from my 
code editor or from the console (I just have a couple of Rebol shortcuts 
to start them in console mode).

%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! :-)