Making (useful subsets of) bytecode portable between targets
Manuel M T Chakravarty
chak at justtesting.org
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
More information about the ghc-devs
mailing list