<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 25 November 2016 at 07:23, Moritz Angermann <span dir="ltr"><<a href="mailto:moritz@lichtzwerge.de" target="_blank">moritz@lichtzwerge.de</a>></span> wrote:</div><div class="gmail_quote"><br></div><div class="gmail_quote">[snip]<br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To get this back on topic, if we have a architecture independent interpretable bytecode,<br>
for ghc, could we sidestep the runner solution altogether and have TH for the target<br>
be evaluated on the host?  Is this what Shea initially wanted to go after?<br></blockquote><div><br></div><div>Yes, but architecture-independent bytecode is the least of the problems.  Doing this properly is a really big change.</div><div><br></div><div>We basically have two worlds: first, the compile-time world. In this world, we need all the packages and modules of the current package built for the host platform. Secondly, we need the runtime world, with all the packages and modules of the current package cross-compiled for the target platform.</div><div><br></div><div>When compiling a module that uses TH, we need to </div><div>- compile it as if we were compiling for the host platform, reading .hi files from the host world</div><div>- run the TH code in the host world</div><div>- restart the compilation, using the .hi files from the target world, and the results of running the splices<br></div><div><br></div><div>But even this isn't going to be enough.  What if your code imports some modules that are only available on the runtime platform? iOS APIs, for example.  The right thing is to have a clean separation between runtime imports and compile-time imports.  Perhaps we just annotate some imports to say they aren't needed at compile-time for running the TH code.  but then we also need compile-time vs. runtime build-depends in our .cabal files, and so on.</div><div><br></div><div>This is just off the top of my head, I'm sure there are more complexities I haven't thought about. </div><div><br></div><div>Its a big project, but ultimately we do have to tackle it, because it's the right thing to do.  Anyone interested in working on this?  Maybe start a new proposal to flesh out the details.</div><div><br></div><div>Cheers</div><div>Simon</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
cheers,<br>
 moritz<br>
<div class="HOEnZb"><div class="h5"><br>
> On Nov 25, 2016, at 2:38 PM, Manuel M T Chakravarty <<a href="mailto:chak@justtesting.org">chak@justtesting.org</a>> wrote:<br>
><br>
> Ok, I am not saying that it is technical impossible. I am saying that it is *impractical*.<br>
><br>
> 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.<br>
><br>
> Running stuff in the simulator during a build would be pretty awkward, but running it on the device is not practical.<br>
><br>
> Manuel<br>
><br>
> 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?<br>
><br>
>> Edward Z. Yang <<a href="mailto:ezyang@MIT.EDU">ezyang@MIT.EDU</a>>:<br>
>><br>
>> At least for Travis, you can generate a private key that only Travis<br>
>> has access to, and use this to authenticate access to the runner.<br>
>> See <a href="https://docs.travis-ci.com/user/encryption-keys/" rel="noreferrer" target="_blank">https://docs.travis-ci.com/<wbr>user/encryption-keys/</a><br>
>><br>
>> Edward<br>
>><br>
>> Excerpts from Manuel M T Chakravarty's message of 2016-11-24 16:38:34 +1100:<br>
>>> If you use Travis CI or such, do you really want to have a runner accessible from an arbitrary host on the Internet?<br>
>>><br>
>>>> Moritz Angermann <<a href="mailto:moritz@lichtzwerge.de">moritz@lichtzwerge.de</a>>:<br>
>>>><br>
>>>> It's certainly far from ideal, but for CI, what obstacles are there besides needing a runner accessible from cross compiling machine?<br>
>>>><br>
>>>> E.g. Start the runner app on an iPhone plugged in into a USB power source and leave it there?<br>
>>>><br>
>>>> Sent from my iPhone<br>
>>>><br>
>>>>> On 24 Nov 2016, at 12:42 PM, Manuel M T Chakravarty <<a href="mailto:chak@justtesting.org">chak@justtesting.org</a>> wrote:<br>
>>>>><br>
>>>>> Sorry, but I don’t think running on the device is practical. How do you want to do CI, for example?<br>
>>>>><br>
>>>>> Manuel<br>
>>>>><br>
>>>>>> Moritz Angermann <<a href="mailto:moritz@lichtzwerge.de">moritz@lichtzwerge.de</a>>:<br>
>>>>>><br>
>>>>>><br>
>>>>>>> On Nov 23, 2016, at 7:50 PM, Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<br>
>>>>>>><br>
>>>>>>> […]<br>
>>>>>>><br>
>>>>>>> My question would be: are you *sure* you can't run target code at compile time?  Not even with an iphone simulator?<br>
>>>>>><br>
>>>>>> This should be possible. However for proper development one would need to run on the<br>
>>>>>> device (iPhone, iPad, …) for armv7 or arm64, as the Simulator is i386 or x86_64.<br>
>>>>>><br>
>>>>>> There is a bit of additional engineering required here to get the shipping of<br>
>>>>>> code from ghc to the runner on the target required (e.g. via network).  As executing<br>
>>>>>> and controlling applications on the actual hardware is limited, I guess a custom<br>
>>>>>> ghc-runner application would have to be manually started on the device, which could<br>
>>>>>> trivially be discovered using bonjour/zeroconf (or just giving ghc the host:port information).<br>
>>>>>><br>
>>>>>> In general though, the runner does not have to obey all the restrictions apple puts<br>
>>>>>> onto app-store distributed apps, as I expect that everyone could build and install<br>
>>>>>> the runner themselves when intending to do iOS development with ghc.<br>
>>>>>><br>
>>>>>> cheers,<br>
>>>>>> moritz<br>
>>>>>> ______________________________<wbr>_________________<br>
>>>>>> ghc-devs mailing list<br>
>>>>>> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
>>>>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
>>>>><br>
>>>><br>
>>><br>
>> ______________________________<wbr>_________________<br>
>> ghc-devs mailing list<br>
>> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
><br>
> ______________________________<wbr>_________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div></div>