World: r4wp

I created an account on the red.esperconsultancy site hoping it would 
bring a little more possibilities in browsing up the tree. This was 
not the case. I am sure that it must be there somewhere but you have 
to know or have a link or own the server ;)

(@Peter, your last question is to Bo about his print-line statements 
I presume.)

@action 42 I think I was not returning the return value and violating 
various other things at the same time

Bo, it seems you're starting Red/System programs by clicking on them? 
If that's the case, it's not the best way to debug such programs. 
You need to open a DOS window and launch the programs from there. 
The window will never close, so you'll be able to see all the messages 
and avoid doing infinite loops at the end of your code.

Click <start> and type cmd.exe another hint is to have a textfile 
at hand with a suitable cd command.

I stumbled upon a possible bug with local variables.
flexfun-s: function [s [string!] return: [string!]][return s]
flexfun-i: function [i [integer!] return: [integer!] ][return i]

flexfun: function [n [integer! float! string!] return: [string! integer! 
logic!] /local rv uitstr uitint][
    rv: type? n

    either "string" = rv [uitstr: flexfun-s n][uitint: flexfun-i n]
]

When I do not declare the uitstr and uitint local variables, the 
compiler makes a ~local extra and notices double declaration:
Compiling to native code... 

Script: "Red/System IA-32 code emitter" (none)

*** Compilation Error: duplicate variable definition in function 
exec/f_flexfun  

*** in file: %/Users/Arnold/data/develop/red/testscripts/flextst1.red 
*** at line: 126 
*** near: [func [/local ~n ~local ~rv ~local ~uitstr ~uitint] [
        push ctx194/values

When I declare both everything is ok.

Arnold, good catch, pleas add it to the bugtracker.

@james_nak, thanks for testing. Your issue is probably related to 
the fact that the output area in this demo has a fixed height, so 
it probably is a bit out of screen on your device, that's why you 
can't see the first output value.

ha, demo pushed :-)

Yes, but you'll need to put all the pieces together in a single folder 
to be able to build it with Eclipse...I'm working on automating the 
APK building process, if I can't finish on time, I'll just provide 
a link with an archive of the eval demo project suitable for Eclipse, 
so you can at least have a chance to mess things around in the meantime. 
;-)

Well, actually, I've just packaged it so here's the link: 
static.red-lang.org/eval-droid.zip

You just need to unzip it in a dedicated folder, install ADT (Android 
Development Tools) which contains both the SDK and Eclipse, install 
a JDK, open the project in Eclipse and compile it. For the Red part, 
there's a precompiled eval.red version in libs/armeabi/libRed.so. 
You can recompile it with the following command-line options: "-t 
Android -dlib". Ensure that you replace it with exactly the same 
name at the same place, then recompile the whole project.

If the automation script I'm working on work, you'll be able to generate 
an APK without download the SDK and JDK! ;-)

I don't want to use Eclipse, nor any other SDK :-( Willing to use 
command-line tools as javac etc. Btw - I use Android Studio, so actually 
wonder, if I would be able to do it using it instead of Eclipse ...

Just wait an hour more to see if I can finish the automatic building 
toolchain...

Believe me, Eclipse is actually much easier to compile/build/test 
an android app than manually calling the command-line tools.

I know, it is just that I am multiplexing between work, red, creating 
ads for my led screen, photo shooting, photo editing, video editing. 
So basically I just jump here or there, and right after I was suggested 
to use Android Studio last month, because - it comes from Google, 
I am now supposed to install yet another toolchain. Last month I 
also installed my Visual Studio 2013 and got really scared by the 
complexity of all that stuff, that comes with it ....

So - I can wait, but maybe not, I am fast at trying new stuff and 
making my Window8 installation even more messy with constantly trying 
new SWs :-)

Hmm, can't avoid Java dependency...maybe I should be able to use 
the preinstalled JRE on Windows platforms, but not sure...

Nevermind, in any case, some description of how to proceed, is going 
to be needed. But it is a pity, as it pushes us to the different 
land, where no more the claim of sel-contained dev environment is 
true. Now we are in a lend of - do regular Android JAVA development 
and use Red DLL, when handy ...

issue #492 added on https://github.com/dockimbel/Red/issues?state=open

Ok build script pushed. You need to have JDK (correctly) installed 
currently for the script to work.

The jarsigner tool needs to access the Java runtime...we'll remove 
that dependency partially or fully in the future.

Holly crap! That works!

Haha :)

Just generated APK, it downloaded some tools (not sure it is cross-platform, 
but on Windows it works), then I thought it hanged, but there was 
a dialog requesting ability to write to dics, then lots of output 
in console, now uploaded apk to my server, and tried on my HTC Sensation! 
Nice dark theme!

Just wrote it in a hurry, I need to take a bus in about an hour...

Will work on the slides from this afternoon until Sunday.

That has to be facebooked!

Yeah, see the commit log, only Windows for now. Will add other platforms 
support tonight.

Outputs in console: you can disable it by setting verbose to false 
in the build script. I've left the verbose mode to make it easier 
for first testers to report errors.

Go facebook it, it should already be PRISM-ed anyway. ;-)

what was the site for the emulators online?

The first time the scripts runs, it download copies of binaries from 
the Android SDK, so it can take some seconds depending on your connection.

https://www.manymo.com

But that won't work with the apk you've buit, that online emulator 
requires x86 code.

btw - observed some delay, when app starts. dunno if for the first 
time, but few secs before prompt and button appears ...

You need to change a few things in the build script to generate x86 
apk.

ah, ok ...

Delay: yes, I need to optimize the starting process, it can be a 
bit slow on older devices.

For building an x86 system compatible apk, the following changes 
are required in the build script:


make-dir/deep bin-dir/lib/armeabi => make-dir/deep bin-dir/lib/x86
-t Android
 => "-t Android-x86"
/libRed
 => "Red"

Erratum: this change is not required: "/libRed" => "Red"

HTC Sensation is not a slow device, everything runs fast :-)

I have a Cortex A9 device (USB stick form factor) where the starting 
delay is not noticeable. Anyway, I just need to rearrange the bridge 
low-level code to make it much faster, not a problem.

hm, thought that app is going to be named after the apk name, but 
apparently not - eval.apk -> Red on Android

I uninstalled older coppies, now it seems to start in cca 1 sec. 
Good enough ...

OK, you made my day, so - donated 50EUR ;-)

Ah thanks! Good initiative! :-)

No, naming happens at several levels...Also Window title <> app name. 
:-)

We'll step by step abstract all those little details, so you'll be 
able to specify your whole app parameters from Red only without having 
to touch any Android XML file.