Re: Making (useful subsets of) bytecode portable between targets

[Manuel M T Chakravarty]

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 :
> 
> 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  
>> 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 :
>>> 
>>> 
 On Nov 23, 2016, at 7:50 PM, Simon Marlow  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@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> 
> 

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Making (useful subsets of) bytecode portable between targets

[Moritz Angermann]

Hi,

just to also note: that this completely ignores any host / target IO actions 
that
TH might want to run.

cheers,
 moritz

> On Nov 24, 2016, at 12:51 PM, Moritz Angermann  wrote:
> 
> 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  
>> 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 :
>>> 
>>> 
 On Nov 23, 2016, at 7:50 PM, Simon Marlow  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@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> 
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Making (useful subsets of) bytecode portable between targets

[Moritz Angermann]

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  
> 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 :
>> 
>> 
>>> On Nov 23, 2016, at 7:50 PM, Simon Marlow  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@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Making (useful subsets of) bytecode portable between targets

[Manuel M T Chakravarty]

Sorry, but I don’t think running on the device is practical. How do you want to 
do CI, for example?

Manuel

> Moritz Angermann :
> 
> 
>> On Nov 23, 2016, at 7:50 PM, Simon Marlow  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@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: DWARF patches for 8.2

[Simon Marlow]

Awesome stuff Ben.  I'll try to find some time to review these.

On 22 November 2016 at 06:18, Ben Gamari  wrote:

> Hello fellow DWARF enthusiasts,
>
> Tonight I finally made something of a breakthrough on the DWARF front;
> after finding a small logic error in one of my patches I was able to get
> a full stack trace into and out of Haskell using the runtime system's
> native stack unwinder. This is quite exciting!
>
> Recall that up until now there have been a few issues which can lead to
> problems with unwinding,
>
>  * #11353: Unsafe foreign calls can require the NCG to make stack
>pointer adjustments to accomodate native calling conventions. These
>adjustments need to be taken into account when we generate unwinding
>information.
>
>  * #11337: Stack fixups produced by CmmStackLayout aren't reflected in
>unwinding information. Essentially this was a result of the fact that
>our current unwinding implementation assumes that stack layout is
>fixed over the course of a block.
>
>  * #11338: The region surrounding safe foreign calls doesn't get proper
>unwinding information.
>
> I've solved all three of these in my branch, which I've rebased, split
> up, and posted to Phabricator. The result is quite a stack of
> differentials,
>
>  * D2740: OrdList: Add Foldable, Traversable instances
>
>Some throat-clearing.
>
>  * D2735: Use newBlockId instead of newLabelC
>
>Just some refactoring.
>
>  * D2737: NCGMonad: Add MonadUnique NatM instance
>
>This will come in handy later.
>
>  * D2736: AsmCodeGen: Refactor worker in cmmNativeGens
>
>More refactoring I did while trying to understand the dataflow in the
>NCG.
>
>  * D2739: CmmCommonBlockElim: Ignore CmmUnwind nodes
>
>This is a fix to what I believe is a bug which I noticed while
>reading through the implementation.
>
>  * D2741: Generalize CmmUnwind and pass unwind information through NCG
>
>This is the bulk of the change. Here we refactor the treatment of
>unwinding information to provide the flexibility we will need to
>address the issues described above and fix #11353. Review is badly
>needed here.
>
>  * D2742: CmmLayoutStack: Add unwind information on stack fixups
>
>Here we use the infrastructure provided in D2741 to fix #11337.
>
>  * D2743: StgCmmForeign: Emit debug information for safe foreign calls
>
>Here we fix #11338 by adding unwind information to the safe foreign
>call prologue/epilogue code.
>
>  * D2738: Cmm: Add support for undefined unwinding statements
>
>Fix unwinding information for stg_stack_underflow_frames, which we
>have no means of unwinding out of. For this we need to add support
>for unwinding declarations which tell the underwinder to "forget"
>about the value of a register.
>
> Reviews would be greatly appreciated.
>
> Cheers,
>
>  - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Reading source annotations during type checking

[Alejandro Serrano Mena]

Dear GHC devs,
Is there a way to retrieve "source annotations" (as defined by
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#source-annotations)
during type checking. In particular, I am interested in reading them in
TcExpr and TcCanonical.

Regards,
Alejandro
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs