> For now OpenGL ES is not supported and then no 3D for Android?

What do you mean by that? Not yet supported in Julia? It's supported on 
Android, and Julia support could be achieved fairly quickly. 

I personally first tried to get 3D under control, as it has higher 
performance demands and therefore shapes the infrastructure more...But 
slowly the 2D support is dripping in.
And while we're dreaming, hopefully we will be able to create fairly nice 
native GUI's with Julia. We will see... 
I'm pretty sure, that we'll be able to nail high performance and 
cross-platform abilities, but I'm a little worried if the usability also 
works out. 
But looking at other tools, it seems that the bar is not set very high :D
QT seems to offer a huge ecosystem with a lot of convenient tools. I 
wonder, if people will always prefer QT, or if one would prefer a 
lightweight Julia solution in the end (If both are available).
My main reason against using QT is probably the complexity... 
A Julia wrapper for QT would probably be already more complex than my whole 
3D library :D 
And extending it can be done by Julia programmers easily, so we would have 
more freedom to evolve the GUI ecosystem in our way, specialized for Julia 
and scientific computing.

Am Donnerstag, 28. Mai 2015 16:17:08 UTC+2 schrieb Páll Haraldsson:
>
>
> I've noticed: "I guess we can announce alpha support for arm in 0.4 as 
> well." (and the other thread on Julia on ARM).
>
> Now, Android runs on x86 (already covered, then if you have that kind of 
> device, no need to wait for ARM support), ARM, and MIPS (actually do not 
> know of a single device that uses it..).
>
>
> I would like to know the most promising way to support Android and..
>
> A. For Firefox OS and the web in general, and hybrid apps, compiling to 
> JavaScript (or Dart and then to JavaScript) would be a possibility, with 
> asm.js/Emscripten.
>
> B. Just making native Android apps is probably easier. Assuming the ARM 
> CPU is solved, it seems easier. And iOS would be very similar.. But would 
> not work for Firefox OS - not a priority for now, but the web in general 
> would be nice..
>
>
> B. seems more promising except for the tiny/non-existent MIPS "problem".. 
> Also better long term, for full Android framework support and full Julia 
> support (concurrency/BLAS etc. that JavaScript would not handle).
>
>
> 1. Just getting Julia to work on Android is the first step. Just the REPL, 
> wouldn't have to be Juno IDE etc. or GUI stuff.
>
> 2. You could to a lot with just the REPL and a real keyboard or just an 
> alternative programmers virtual keyboard.. However, graphing would be nice, 
> and what would be needed? What are the most promising GUI libraries already 
> supported by Julia (or not..)? Say Qt, supported by Julia and Android. 
> Would it just work?
>
> 3. Long term, making apps, even standalone (Julia "supports" that) with 
> Julia. If GUIs work for graphing, is then really anything possible? I know 
> Android/Java has a huge framework. Google is already supporting Android 
> with Go (without any Java) as of version 1.4 and with Dart (for hybrid 
> apps). For Go they have a "framework problem" going to support games at 
> first. Some people are sceptical about Julia and games because of GC (I'm 
> not so much). I note Go also has GC..
>
> JavaCall.jl only works for JVM not Dalvik or ART. Would it be best to just 
> use the native C support on Android or somehow go through Go? Anyone 
> already tried to call Go from Julia? Rust is possible, but doesn't have GC. 
> Go should be possible, just as Java, but have similar problems..
>
> Do/could macros somehow help with supporting the full Android framework? 
> Julia already has "no overhead" calling, could you generate bindings from 
> automatically from some metadata and/or on the fly?
>
>
> This could be a cool pet project - anyone else working along these lines?
>
> Any reason plan B couldn't succeed relatively quickly? There are some ways 
> to make apps *on* Android already, I think all crappy, Julia wouldn't be..?
>
>
> Thanks in advance,
> -- 
> Palli.
>
>

Reply via email to