Oh, nothing was seen as criticism or that you prefer approach A over B ;) I was just bubbling about the things I've been thinking about lately!
>probably a low bar to jump, unlike Vulkan? I think I'm not using many features which don't map to OpenGL ES easily. So yeah, should be quick to do. I hope IOS will go smoothly, as Apple is the company most involved with LLVM (SWIFT etc)... But who knows, probably that's exactly the reason to get stingy with any other LLVM project. If someone has a lot of time, we could write a Julia library, much like GLFW, which supports all sorts of events and context/window creation in a cross-platform way, including IOS and Android. So we could just abstract this away, preferably via Reactive.jl. So you could just have a GPS or Image (e.g. from the webcam) signal, regardless of the platform ;) >From what I know, there should be no problem to call the phones API, as it doesn't seem to be a problem to get them from C/C++. Oh yeah, Tango would make a lot of sense together with Julia ;) I can't really answer your other questions... But there are some tools on the way, which hopefully will make it easier to get dependency graphs and such from Julia packages. (e.g. https://github.com/IainNZ/MetadataTools.jl) 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. > >
