Hello John, I tried to install the Haskell demo Cube on my Nexus 7 and got: Error: package file was not signed correctly. D
On Thu, Jul 3, 2014 at 4:47 PM, John Meacham <[email protected]> wrote: > In case anyone wanted to start writing haskell android code now, jhc > fully supports android as a target. here is an app made with it > > https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube > > this was made with Kiwamu's ajhc branch but code has been merged back > into the main tree. > > On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald > <[email protected]> wrote: >> This would probably be a great boon for those trying to use haskell for >> Android and IOS right? how might the emulation setup work for those? >> >> >> >> >> On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald >> <[email protected]> wrote: >>> >>> wow, this is great work! >>> >>> If theres a clear path to getting the generic tooling into 7.10, i'm all >>> for it :) (and willing to help on concrete mechanical subtasks) >>> >>> >>> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman <[email protected]> >>> wrote: >>>> >>>> hi all, >>>> >>>> I've added some code [1] [2] to GHCJS to make it run Template Haskell >>>> code on node.js, rather than using the GHC linker. GHCJS has supported TH >>>> for a long time now, but so far always relied on native (host) code for it. >>>> This is the main reason that GHCJS always builds native and JavaScript code >>>> for everything (another is that Cabal Setup.hs scripts need to be compiled >>>> to some host-runnable form, but that can also be JavaScript if you have >>>> node.js) >>>> >>>> Now besides the compiler having to do twice the work, this has some other >>>> disadvantages: >>>> >>>> - Our JavaScript code has the same dependencies (packages) as native >>>> code, which means packages like unix or Win32 show up somewhere, depending >>>> on the host environment. This also limits our options in choosing >>>> JS-specific packages. >>>> - The Template Haskell code runs on the host environment, which might be >>>> slightly different from the target, for example in integer size or >>>> operating >>>> system specific constants. >>>> >>>> Moreover, building native code made the GHCJS installation procedure more >>>> tricky, making end users think about libgmp or libiconv locations, since it >>>> basically required the same preparation as building GHC from source. This >>>> change will make installing much easier and more reliable (we still have to >>>> update the build scripts). >>>> >>>> How it works is pretty simple: >>>> >>>> - When any code needs to be run on the target (hscCompileCoreExpr, >>>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with >>>> the thrunner.js [3] script, >>>> - GHCJS sends its RTS and the Template Haskell server code [1] to >>>> node.js, the script starts a Haskell thread running the server, >>>> - for every splice, GHCJS compiles it to JavaScript and links it using >>>> its incremental linking functionality. The code for the splice, including >>>> dependencies that have not yet been sent to the runner (for earlier >>>> splices), is then sent in a RunTH [4] message, >>>> - the runner loads and runs the code in the Q monad, can send queries to >>>> GHCJS for reification, >>>> - the runner sends back the result as a serialized Template Haskell AST >>>> (using GHC.Generics for the Binary instances). >>>> >>>> All Template Haskell functionality is supported, including recent >>>> additions for reifying modules and annotations. I still need to clean up >>>> and >>>> push the patches for the directory and process packages, but after that, >>>> the >>>> TH code can read/write files, run processes and interact with them and make >>>> network connections, all through node.js. >>>> >>>> Now since this approach is in no way specific to JavaScript, I was >>>> wondering if there's any interest in getting this functionality into GHC >>>> 7.10 for general cross compilation. The runner would be a native (target) >>>> program with dynamic libraries (or object files) being sent over to the >>>> target machine (or emulator) for the splices. >>>> >>>> Thanks to Andras Slemmer from Prezi who helped build the initial proof of >>>> concept (without reification) at BudHac. >>>> >>>> cheers, >>>> >>>> Luite >>>> >>>> [1] >>>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs >>>> [2] >>>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs >>>> [3] >>>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js >>>> [4] >>>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 >>>> >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> [email protected] >>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>>> >>> >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> [email protected] >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > > > > -- > John Meacham - http://notanumber.net/ > _______________________________________________ > Glasgow-haskell-users mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
