Making (useful subsets of) bytecode portable between targets

Fri Nov 25 09:49:36 UTC 2016

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 <moritz at lichtzwerge.de>:
> 
> 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 <chak at justtesting.org> 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 <ezyang at MIT.EDU>:
>>> 
>>> 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 <moritz at lichtzwerge.de>:
>>>>> 
>>>>> 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 <chak at justtesting.org> 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 <moritz at lichtzwerge.de>:
>>>>>>> 
>>>>>>> 
>>>>>>>> On Nov 23, 2016, at 7:50 PM, Simon Marlow <marlowsd at gmail.com> 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
>>>>>>> ghc-devs at haskell.org
>>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>>> 
>>>>> 
>>>> 
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> 
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs