I totally agree that GHC with TH is crippled and that this is a major restriction off the cross-compilation story. All I am saying is that I see a device runner (and to a degree a simulator runner) not as a solution to this *important* problem. Architecture independent interpretable byte code seems a much more attractive avenue for me. (Sorry if I didn’t make this clear.)
Manuel > Moritz Angermann <[email protected]>: > > Aren’t we taking this a bit too far off topic? I feared as much when I wrote > my > initial reply. Please excuse. > > I agree that ghc + runner is not an optimal, and maybe even for some tasks > (iOS) > a pretty convoluted solution. > > This is only if we follow the proven solution to TH that luite in ghcjs > pioneered, > and which later found it’s way into ghc through iserv. If someone proposes a > solution to TH that does not require a runner and allows the TH to be fully > evaluated on the host with no need to evaluate on the target for cross > compilation, > that would be great! > > If the runner would just require the same architecture, maybe qemu would be a > solution > that would not require a device running? Then again I’m not sure how that > would > work with TH that directly or indirectly accesses libraries only available on > iOS for > example. > > Please don’t get me wrong. IMO ghc without TH is quite crippled, and > therefore so is a > cross compiling ghc. From the solutions I saw to this problem (zeroth, > evil-splicer, and > the ghcjs runner approach), the ghcjs runner approach, seems to me at least > as the most > promising, that would work for the largest subset of TH. > > To get this back on topic, if we have a architecture independent > interpretable bytecode, > for ghc, could we sidestep the runner solution altogether and have TH for the > target > be evaluated on the host? Is this what Shea initially wanted to go after? > > cheers, > moritz > >> On Nov 25, 2016, at 2:38 PM, Manuel M T Chakravarty <[email protected]> >> wrote: >> >> Ok, I am not saying that it is technical impossible. I am saying that it is >> *impractical*. >> >> Imagine Travis CI needing to run stuff on my phone that is attached to my >> Mac (if we are lucky), which is behind NAT somewhere in Australia. >> >> Running stuff in the simulator during a build would be pretty awkward, but >> running it on the device is not practical. >> >> Manuel >> >> PS: BTW, shipping binary code to the device means it has to be code signed >> using a distribution profile of a registered developer. That is one thing if >> Xcode does all the magic behind the scenes, but do you really want to make >> that part of the GHC build process? >> >>> Edward Z. Yang <[email protected]>: >>> >>> At least for Travis, you can generate a private key that only Travis >>> has access to, and use this to authenticate access to the runner. >>> See https://docs.travis-ci.com/user/encryption-keys/ >>> >>> Edward >>> >>> Excerpts from Manuel M T Chakravarty's message of 2016-11-24 16:38:34 +1100: >>>> If you use Travis CI or such, do you really want to have a runner >>>> accessible from an arbitrary host on the Internet? >>>> >>>>> Moritz Angermann <[email protected]>: >>>>> >>>>> It's certainly far from ideal, but for CI, what obstacles are there >>>>> besides needing a runner accessible from cross compiling machine? >>>>> >>>>> E.g. Start the runner app on an iPhone plugged in into a USB power source >>>>> and leave it there? >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On 24 Nov 2016, at 12:42 PM, Manuel M T Chakravarty >>>>>> <[email protected]> wrote: >>>>>> >>>>>> Sorry, but I don’t think running on the device is practical. How do you >>>>>> want to do CI, for example? >>>>>> >>>>>> Manuel >>>>>> >>>>>>> Moritz Angermann <[email protected]>: >>>>>>> >>>>>>> >>>>>>>> On Nov 23, 2016, at 7:50 PM, Simon Marlow <[email protected]> wrote: >>>>>>>> >>>>>>>> […] >>>>>>>> >>>>>>>> My question would be: are you *sure* you can't run target code at >>>>>>>> compile time? Not even with an iphone simulator? >>>>>>> >>>>>>> This should be possible. However for proper development one would need >>>>>>> to run on the >>>>>>> device (iPhone, iPad, …) for armv7 or arm64, as the Simulator is i386 >>>>>>> or x86_64. >>>>>>> >>>>>>> There is a bit of additional engineering required here to get the >>>>>>> shipping of >>>>>>> code from ghc to the runner on the target required (e.g. via network). >>>>>>> As executing >>>>>>> and controlling applications on the actual hardware is limited, I guess >>>>>>> a custom >>>>>>> ghc-runner application would have to be manually started on the device, >>>>>>> which could >>>>>>> trivially be discovered using bonjour/zeroconf (or just giving ghc the >>>>>>> host:port information). >>>>>>> >>>>>>> In general though, the runner does not have to obey all the >>>>>>> restrictions apple puts >>>>>>> onto app-store distributed apps, as I expect that everyone could build >>>>>>> and install >>>>>>> the runner themselves when intending to do iOS development with ghc. >>>>>>> >>>>>>> cheers, >>>>>>> moritz >>>>>>> _______________________________________________ >>>>>>> ghc-devs mailing list >>>>>>> [email protected] >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>>> >>>>> >>>> >>> _______________________________________________ >>> ghc-devs mailing list >>> [email protected] >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> [email protected] >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
