World: r3wp

GTK's, and other IDEs', idea has always been that Glade, and now 
a newer interface builder, makes it easier, but combining a generated 
XML interface definition manually with some code language doesn't 
compare to Red/System

Kaj: you might want to add something to the comments here: https://gist.github.com/1326101#comments

Done, thanks

For the RED import, I am getting "Compilation Error: attempt to redefine 
existing function name: printf" when trying to compile the example 
for variadic  http://static.red-lang.org/red-system-specs-light.html
    Get same message for "free" when trying to compile example from 
9.1 #import.     What novice error am I  making?

You can't reuse a function name in Red/System. `printf`and `free` 
are already defined in the runtime source code (%red-system/runtime/). 
If you provide alternative names (not used by the runtime) for those 
imported functions, it will work correctly.

Doc has got Red/System running on Android

Great to hear! What kind of output is the app able to do?

Console output only for now.

Being able to make GUI apps on Android requires at least two more 
steps:
- have Red/System linker be able to generate shared libraries

- build a generic Java bridge to be able to instanciate java objects, 
invoke methods and receive events

A shorter, but less efficient path, could be to use TCP sockets (or 
a lib like ZeroMQ) to setup a communication channel with the generic 
Java bridge.

Also the NDK could have been an interesting option, but AFAIU, it 
compiles C/C++ sources to Dalvik bytecode, so natively interfacing 
with Red/System binaries might not be possible.

Are "native" Android GUI apps posible? I mean - e.g. GTK based ones. 
Or if View would be ported - it uses own methods to draw stuff, no? 
Although windowing is native, so probably some link to JAVA still 
required. Pity MeeGo did not become popular instead (pure Linux based 
IIRC)

I finally find some time to read Red/System doc, and I have a novice 
question - what is basically the difference of cdecl or stdcall? 
Respectively - when wrapping API stuff, how do I know which one to 
use? I expect this area is for more skilled C developers, than occassional 
interface users?

In 13.6.2: isn't there a typo?

show-args 123 -p hello

it would output:

count: 4
1: test-logic2
2: 123
3: -p
4: hello

I would expect 1: being a "show-args"

what is basically the difference of cdecl or stdcall?


See this wikipedia page for some basic info about calling conventions: 
http://en.wikipedia.org/wiki/X86_calling_conventions


Respectively - when wrapping API stuff, how do I know which one to 
use? 


When you're wrapping an API, you should find out how the library 
was compiled, and infer from that what calling convention is required. 
Most of C libs are using cdecl, while the Windows win32 API uses 
stdcall.

13.6.2: yes, it's a typo.

Typo fixed.

small typos:

Similary, it is also possible to modify the c-string's bytes
  .... "similarly"
alias names should end with a exclamation mark
  .....  "an exclamation"
The stdcall attribut is also accepted
  ....  "attribute"


But - those are really small typos, you can probably spend your valuable 
time elsewhere :-)

Thanks for reporting them. I will fix them now, that's just a couple 
minute work.

btw: why was 'declare word used instead of 'make? Will there be 'make 
in a RED level, so you wanted to keep the difference?

`make` implies a dynamic creation (at run-time), while these are 
static value declarations (at compile-time). There was a debate about 
that on the Red ML, see the thread for more info.

Right, `make` at Red level will have the same meaning as in REBOL.

BTW, there's no memory manager at Red/System level, so that you can't 
"make" a value, you can only declare it at compile-time. If you need 
dynamic values at run-time, you will need to use malloc/free wrappers 
provided by the Red/System runtime library.

The NDK compiles C/C++ to fat binaries native code, not Dalvik. The 
native code interfaces with Dlvik code through JNI standard ABI. 
If you make Red compile to the JNI calling conventions, to will be 
much easier than rigging up a TCP control interface.

The NDK supports compiling to 3 different native formats right now 
- two ARM platforms, and x86. You can create an APK that supports 
one or more of these platforms. The binaries are packaged into an 
archive, with the binaries of different platforms put into subdirectories 
in that archive. When an APK is installed, only the binaries for 
the supported platform(s) are loaded.

Using a JNI interface is my plan, but it requires to be able to generate 
Red/System shared libraries. I was mentioning the TCP option, as 
it could be done right now.

If you are making a native compiler for Android, integrating with 
the NDK is the best way to go. Unless what you are making is a compiler 
that runs *on* Android devices, which would be great; then you would 
make the libraries for that compiler integrate with the NDK.

Does the NDK provide access to all the GUI framework?

Yes. Though some levels of access require more recent versions of 
Android. Fully native apps require 2.3 or above.

That's very good news.

Most Android phones run 2.2 or below, so that good is a bit limited.

I would personally appreciate it if you supported 2.2, as that is 
the last version that my phone model currently has been upgraded 
to. It would be a good idea to look up the stats for which percentages 
of Android phones are running which versions. I haven't seen a 1.5 
phone in over a year, but my gf's phone won't be upgraded past 1.6 
(I need to get her a new phone).

We did a lot of research into the NDK for the R3 project. I was really 
interested in how an Android host program would be structured, how 
the Android application model would map to the R3 model. Hint: Android 
doesn't really have applications at all.

In a lot of ways, Android reminds me of the Oberon System. You don't 
install apps, you install system services, that for some of the types 
of services provide a UI, and for other types of services provide 
an API or task execution model.

I will probably go for 2.1 or 2.2 as minimal system requirement.

Go for 2.0, and you'll cover almost everything. Certain Red facilities 
could require more recent versions, but between 2.0 and 2.2 there 
were mostly just features added, as far as native code is concerned. 
If you support pre-2.3, you might as well set the baseline as far 
back as 2.0.

There are a lot of people still waiting for their manufacturers to 
provide upgrades from 2.1 to 2.2, so 2.1 support is a good idea. 
The main thing added in 2.2 was the Dalvik JIT compiler, and that 
doesn't really affect native code that much. The NDK docs have a 
pretty good changelog that tells you what was added in each version.

Yeah, I know the issue, I own an HTC Bravo stuck at 2.2.

I could go 2.3 with a custom ROM but I would loose HTC Sense UI.

The new x86 support is pretty interesting. I have an old netbook 
I barely use now, which I could install Android on for experimentation. 
Don't forget x86 with your Android support :)

Well, Android x86 is basically Linux x86, so you should be able to 
already run Red/System binaries on it.

Never mind about the 2.0, even the NDK site lists it an an "other 
platform". I can't remember the last time I saw someone still stuck 
on 2.0.

Integrating with the Android non-application model is the most interesting 
point of running Android on that machine. If I wanted to run Linux 
binaries on it, I could keep Ubuntu on it.

Are you sticking to the ARM5 stuff, or integrating the ARM7 extensions

Having fully access to the whole Android framework from Red is the 
goal. Running Linux binaries is the just the first experimental step.

I will stick with ARMv5 until we rewritte Red/System in Red and add 
a code optimizer. Such optimizer will be able to generate v6 and 
v7 specific code when required.

Android lets you bundle seperate binaries for ARM5 and ARM7 support 
in the same APK. Which binaries get loaded depends on which level 
the phone supports, though if there's no ARM7 binary the ARM7 phone 
can run an ARM5 binary. If you want to do the progressive use of 
ARM7 features if ARM7 is available, it's best to let the APK do it 
for you. I don't think that there are any ARM6 devices for Android, 
especially since the NDK doesn't support them, but if you want to 
add ARM6 support for other platforms then cool.

Well, I am not doing the ARM port only for Android, I target also 
iOS and some embedded boards (like e.g. the Raspberry Pi).

Never mind about what I said about ARM6. Apparently some devices 
were ARM6 but claiming to be ARM7. Progressive support for ARM6 and 
maybe even ARM7 might be a good idea to add to the ARM5 binaries.

BrianH: forget the phones of the past. Noone should care about "most 
phones running 2.2 or below". The release cycle is really fast. I 
would not care for pre 2.3 devices at all, just believe me ....