World: r4wp

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.

sur => such

However using JFrame you need to add the child to the JFrame's content 
pane instead: frame.getContentPane().add(child);


JFrame is part of Swing, Swing is not AWT. I can't find a getContentPane() 
method for java.awt.Frame class.

I know .... I just tried to point out example of kind of chaining 
method calls, which I expected not being covered by the bridge. But 
as you both stated, it migh work by separate calls ....

btw - two days ago I read about Google releasing new Android JAVA 
IDE, so Eclipse will get some competition ...

The new IDE, Android Studio, is based on JetBrains' IntelliJ IDEA. 
You can get more details in this blog post:

http://blogs.jetbrains.com/idea/2013/05/intellij-idea-and-android-studio-faq/

what kind of GUI is Android using? It surely is not AWK, nor Swing? 
Just trying to orientiate myself ....

I just looked up an example of how to e.g. obtain contact list, the 
official API way, not via some low level direct SQLite hacks. Found 
following link, since Android 2.0, there is ContactsContract class 
for that. But - those examples are more complex, e.g. obtaining cursor 
to DB and looping via returend list after sending a query.


As to understand our bridge - what we are allowed is mainly to wrap 
objects/classes and their methods. I mean - get them assigned to 
Red words. Then we have ability to invoke their methods. I wonder 
though, how one wraps such example as in the following link: 


http://www.higherpass.com/Android/Tutorials/Working-With-Android-Contacts/


Another question - would it be possible to create JAVA function on 
Red side, wrapping the sourcecode? Think inlining of ASM in C, or 
inlining of R/S code in Red?

uf, installed AndroidStudio and built first example for emulator. 
Pretty complex stuff, hidden under nice roof :-)

what kind of GUI is Android using?
 Its own one. See the Android.* classes in Android docs.

Contacts access: it's too early to write Android-specific code as 
long as we can't test it.

Another question - would it be possible to create JAVA function on 
Red side, wrapping the sourcecode? Think inlining of ASM in C, or 
inlining of R/S code in Red?


No, the Red/Java bridge has nothing in common with ASM/C or R/S in 
Red. The bridge does not compile to Java nor does it produce Java 
source code. It just manipulates the JVM content at runtime using 
Java reflection abilities through JNI.

yes, my question was rather naive, sorry. I realised later, that 
during the compile time, Red or R/S would have to understand JAVA 
code, so in order to support such feature, we would have to have 
java compiler available ....

Working in Android Studio a bit, looking into structures, what does 
it support, etc., I can't foresee, what our aproach is going to be, 
so lookinf forward to it. E.g. the IDE generates GUI definitions 
into XML files, ditto various configs, translations. So - what I 
expect is that you create basid .apk with certain featureset, and 
from that on, it will be manipulated from Red side. Justo wondering, 
if we will be able to dynamically generate UI elements, etc? Or will 
you suggest ppl to use your basic .apk, do certain work in Android 
Studio, and the supporting backend in Red? Or is your idea that ppl 
should not need to eventually touch sw like Android Studio?

sorry again, if questions are not much accurate ....

For what I plan, you will not need anything else than Red (and eventually 
Red IDE) in order to produce Android apps. You won't need to have 
JDK installed.

Dynamically generate UI elements: yes, of course.

Thanks for store-bodies?. :-)

Yep, that might close a security hole for your TryRed I guess. You 
can also now build true closed-source software using Red. ;-)

BTW, I have found an issue with global variables initialization in 
PIC mode. It works fine for PIC executables, but PIC library will 
crash. I'm working on fixing it...

There's a fundamental complaint among Android developers that you 
can't protect your apps against cracking, unlike on iOS, where Objective 
C apps are compiled. Petr showed how easy it is to decompile Android 
Java apps. With Red and the Java bridge, you can reach the same security 
on Android as native iOS apps. This could be an important marketing 
feature for Red

Interesting point!

I'm not sure how it has shifted by now, but a few years ago, when 
Android was already balancing the market share with iOS, Apple still 
had 99% share of all money collected from mobile apps, due to such 
issues

Until someone writes a decompiler for Red :)

Yep, that's far from impossible, but Java is much easier to decompile 
anyway. ;-P

That's going to be hard. A lot of information will be lost in compilation, 
especially for Red/System code and especially when the compilers 
will do optimisations

Eventually, it will be harder than it would be at the moment.

I've fixed several issues related to PIC mode for shared libraries, 
now the Red/Java bridge runs fine on Linux too.

Works fine on Mac OS X too (using `java -d32 bridge`).

Does anyone have an armhf (non-Raspbian) distro installed where we 
can do some Red binaries tests?

On my Raspbian distro, ldd on any Red binaries returns "not a dynamic 
executable" error. I suspect a local setup issue, but I would like 
to see if it works or not on different armhf installs.

I have Arch Linux on Raspberry.

Can you try a `ldd` on any Red[/System] binary?

I found the same problem, and several others, yesterday on BodhiLinux 
for Raspberry

My impression is that there are regressions

I'll try to remember when I get back home in front of one of my Raspberries.

I can't get OpenGL to work on it if you don't :-)

Oh, yeah.  I have my son's graduation ceremony tonight so I won't 
be able to look at it until tomorrow night.

Congratulations :-)