Re: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM

[Karel Gardas]

Your libncurses is for host so your cross-compiler can't use it. See 
http://ghcarm.wordpress.com/2014/01/18/unregisterised-ghc-head-build-for-arm64-platform/ 
-- especially bits about sysroot.


Karel

On 04/ 3/14 09:04 PM, eng. Vassil Ognyanov Keremidchiev wrote:

Okay, I got that LLVM is used here to build part of the GHC compiler for
x86 and not for ARM directly.
I have installed llvm-3.3 and build processed much longer until this error:

configure: error: in `/home/varosi/haskell/ghc/libraries/terminfo':
configure: error: curses library not found, so this package cannot be built
See `config.log' for more details
make[1]: *** [libraries/terminfo/dist-install/package-data.mk
] Error 1
make: *** [all] Error 2

I didn't found curses library at apt-get or cabal.


2014-04-03 21:13 GMT+03:00 eng. Vassil Ognyanov Keremidchiev
mailto:var...@gmail.com>>:

I would like to build GHC as a cross-compiler. So it can still run
on x86 Ubuntu, but producing code for ARM v7.
What should I do?


2014-04-03 21:05 GMT+03:00 Karel Gardas mailto:karel.gar...@centrum.cz>>:


I don't understand why you are trying to cross-compile LLVM?
I've though you'd like to cross-compile GHC itself...

Karel


On 04/ 3/14 08:00 PM, eng. Vassil Ognyanov Keremidchiev wrote:

May be the problem is:
arm-linux-gnueabi-gcc --version
gives me 4.6.3 ?

Is it possible to install earlier LLVM version?

2014-04-03 20:47 GMT+03:00 eng. Vassil Ognyanov Keremidchiev
mailto:var...@gmail.com>
>>:


 I'm trying to compile LLVM as is described in:
http://bgamari.github.io/__posts/cross-compiling_llvm.__html

 without success. This is the error:

 llvm[1]: Compiling StringMatcher.cpp for Debug+Asserts
build
 llvm[1]: Compiling TGLexer.cpp for Debug+Asserts build
 llvm[1]: Compiling TGParser.cpp for Debug+Asserts build
 llvm[1]: Compiling TableGenBackend.cpp for
Debug+Asserts build
 llvm[1]: Building Debug+Asserts Archive Library
libLLVMTableGen.a
 make[1]: Leaving directory
 `/home/varosi/haskell/llvm/__build/lib/TableGen'
 make[1]: Entering directory
`/home/varosi/haskell/llvm/__build/utils'
 make[2]: Entering directory
 `/home/varosi/haskell/llvm/__build/utils/FileCheck'
 llvm[2]: Compiling FileCheck.cpp for Debug+Asserts build
 llvm[2]: Linking Debug+Asserts executable FileCheck


/home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o:
 In function
`llvm::cl::Option::Option(__llvm::cl::NumOccurrencesFlag,
 llvm::cl::OptionHidden)':


/home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:242:
 undefined reference to `vtable for llvm::cl::Option'


/home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:242:
 undefined reference to `llvm::cl::GeneralCategory'


/home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o:
 In function `llvm::cl::Option::~Option()':


/home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:281:
 undefined reference to `vtable for llvm::cl::Option'


/home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o:
 In function
`llvm::cl::GenericOptionValue:__:~GenericOptionValue()':


/home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:356:
 undefined reference to `vtable for
llvm::cl::GenericOptionValue'


/home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o:
 In function
`llvm::cl::OptionValue::OptionValue()':


/home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:461:
 undefined reference to `vtable for
llvm::cl::OptionValue'


/home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o:
 In function
`llvm::cl::basic_parser_impl::__~basic_parser_impl()':


/home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:702:
 undefined reference to `vtable for
llvm::cl::basic_parser_impl'


/home/varosi/haskell/llvm/__build/utils/FileCheck/Debug+__Asserts/FileCheck.o:
 In function

`llvm::__PrettyStackTraceProgram::__PrettyStackTraceProgram(int,
char
 cons

Re: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-citeproc / highlighting-kate

[Sergei Trofimovich]

On Sat, 22 Mar 2014 22:21:42 +0300
Sergei Trofimovich  wrote:

> Hello!
> 
> I have noticed the problem in ghc-7.6.3 first
> when tried to build all haskell userland with -O2 opt level.
> 
> It led to amazing bugs!
> 
> Here is one of those (highlighting-kate hackage package):
> > [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( 
> > highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, 
> > highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o )
> > stack overflow: use +RTS -K to increase it
> 
> How to reproduce it:
> 1. Download a bundled file (6.6MB):
> http://code.haskell.org/~slyfox/selfcontained-eater-ghc-7.8-rc2.tar.gz
> 2. Unpack and run there:
>   ./mk.sh
> 
> The script is designed to plug any built ghc version w/o external depends.
> 
> Command will fail as:
> $ ./mk.sh
> ...
> [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( 
> highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, 
> highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o )
> stack overflow: use +RTS -K to increase it
> 
> On ghc-7.6.3 it will progress a bit more: down to 452 file and will crash 
> there
> similar way.
> 
> I've 'cabal unpack'-ed all sources and configured/de-.hsc-ed them
> manually/added needed -DWhatever / added {-# LANGUAGE CPP #-}
> around. Nothing else.
> 
> It's very hard to shrink such large thing manually down to 2-3 files.
> Would be cool if ghc (and cabal) would be able to spit something
> self-sufficient (like 'gcc -i' does) for devs to reproduce.
> 
> Adding '-v' shows such log:
> ...
> *** Simplifier:
> Result size of Simplifier iteration=1
>   = {terms: 21,973, types: 21,838, coercions: 1,842}
> Result size of Simplifier iteration=2
>   = {terms: 21,952, types: 21,819, coercions: 1,842}
> Result size of Simplifier
>   = {terms: 21,950, types: 21,817, coercions: 1,842}
> *** SpecConstr:
> Result size of SpecConstr***

Nobody interested? Is it too scary?

Such inliner blowups are hard to shrink down from real
examples down to toy ones. I could try to but I need
a bit of guidance.

Maybe you need only an intermediate core step right
before an OOM, whatever?

Thanks!

-- 

  Sergei


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: 7.8.1 plan

[Mateusz Kowalczyk]

On 25/03/14 06:01, kyra wrote:
> Will it include the latest commit to haddock? It solves this: 
> http://trac.haskell.org/haddock/ticket/292. This can greatly improve 
> performance of haddock in some situations (when a project is built with 
> --split-obj flag).
> 
> Cheers,
> Kyra

Just as a follow up, as we had some more time, this is actually going
into 7.8.1.

Thanks

-- 
Mateusz K.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Haskell Support on Windows (Simon Peyton Jones)

[eng. Vassil Ognyanov Keremidchiev]

I could try with building GHC on Windows as a cross-compiler for ARM if
there is someone to help with building GHC.


2014-04-01 16:45 GMT+03:00 Carter Schonwald :

> Hey roman!
> If you get stuck getting ghc to build on windows, please ask for help on
> the ghc mailing lists and/or on the #ghc channel on freenode.
> Just having more folks that regularly try to build and use ghc on windows
> would be huge.
> There's also countless ways to contrib To ghc too.
>
> On Tuesday, April 1, 2014, Roman Kuznetsov  wrote:
>
>> Hello,
>>
>> -- sorry for incomplete email - typing from mobile is not easy :)
>>
>> I would like to participate in GHC on Windows. But I am a normal windows
>> developer and don't know much of that rather weird (to me) tool chain used
>> in this case. I frankly tried a few times before - every time with the same
>> result - I never get to the point, but trying to understand just how to
>> build it. I know there is a wiki, etc.
>>
>> But my question (and the reason I write here): is it possible to have
>> some kind of mini-course, a crush-course on developing GHC on Windows (as
>> well as on other platforms) - video course ... this is what comes to mind
>> after all these Coursera, Pluralsight, etc.
>>
>> You could say - there is a wiki. But that's not enough. Maybe it's just
>> me... I will take another analogy. Even though I'm coding for Windows
>> primarily, I am a linux user. So, I switched from Ubuntu to Arch Linux
>> recently which was possible due to the quality of their wiki documentation
>> (Arch is known to not be as user friendly as *buntu like systems).
>>
>> Sorry for not referring to any concrete problems, I just tried stating
>> what I think didn't let me start working with that.
>>
>> /Roman
>>
>> On 01 апр. 2014 г., at 15:26, "Carter Schonwald" <
>> carter.schonw...@gmail.com> wrote:
>>
>> Kyle, we need you to help us with windows support! :-)
>>
>> On Tuesday, April 1, 2014, Simon Peyton Jones 
>> wrote:
>>
>>  A couple of poor assumptions are made here.
>>
>>
>>
>> I’m not sure where “here” is.   In my email I specifically said exactly
>> what you are saying (only I was not as eloquent as you).
>>
>>
>>
>> What we need is some developers who are willing to give some love and
>> support to the Windows version of GHC.  And *they* really are thin on
>> the ground, unfortunately.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Kyle
>> Van Berendonck
>> *Sent:* 01 April 2014 13:54
>> *To:* ghc-devs@haskell.org
>> *Subject:* Re: Haskell Support on Windows (Simon Peyton Jones)
>>
>>
>>
>> A couple of poor assumptions are made here.
>>
>> The first is that the userbase of GHC on Windows is poor. This is false.
>> In fact, the poor state of Windows is mentioned on #haskell more frequently
>> as of late. In the last week I've talked almost every day to (different)
>> people who have had Windows woes with using GHC. The hacker-base isn't here
>> at the moment - I agree, but the user-base most certainly is. Could this be
>> a problem with the demographic, or could it just be that Windows
>> development isn't inviting? The build system and default test failures
>> in-particular are a source of discouragement.
>>
>> The second assumption is that GHC/Haskell will be worth a dime in the
>> RealWorld without Windows as a primary tier platform. I'm going to put a
>> crude guess that given the overwhelming magnitude of C#/F# coming up on my
>> local careers portal that there's far more industry on Windows than on OSX
>> or Linux. Those are all the businesses where the probability that they will
>> ever touch Haskell goes from `probably not right now` to `impossible`. Let
>> me also remind you that Windows still holds 89.2% of operating system
>> market share ie the people that hackers and developers actually have to
>> deploy their applications to.
>>
>> Sorry to sound fumey, but there's all this suggesting that everyone would
>> have a better day if we dropped Windows (let's be honest, if it wasn't a
>> primary tier platform nobody would have fixed it for 7.8), but I doubt few
>> of the people who think it's a "great idea" or sslt have actually thought
>> through whether it's the best thing for Haskell or just the best thing to
>> get 7.8 into their hands a couple weeks sooner.
>>
>> Regards.
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>> ___ ghc-devs mailing list
>> ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM

[Karel Gardas]

I don't understand why you are trying to cross-compile LLVM? I've though 
you'd like to cross-compile GHC itself...


Karel

On 04/ 3/14 08:00 PM, eng. Vassil Ognyanov Keremidchiev wrote:

May be the problem is:
arm-linux-gnueabi-gcc --version
gives me 4.6.3 ?

Is it possible to install earlier LLVM version?

2014-04-03 20:47 GMT+03:00 eng. Vassil Ognyanov Keremidchiev
mailto:var...@gmail.com>>:

I'm trying to compile LLVM as is described in:
http://bgamari.github.io/posts/cross-compiling_llvm.html
without success. This is the error:

llvm[1]: Compiling StringMatcher.cpp for Debug+Asserts build
llvm[1]: Compiling TGLexer.cpp for Debug+Asserts build
llvm[1]: Compiling TGParser.cpp for Debug+Asserts build
llvm[1]: Compiling TableGenBackend.cpp for Debug+Asserts build
llvm[1]: Building Debug+Asserts Archive Library libLLVMTableGen.a
make[1]: Leaving directory
`/home/varosi/haskell/llvm/build/lib/TableGen'
make[1]: Entering directory `/home/varosi/haskell/llvm/build/utils'
make[2]: Entering directory
`/home/varosi/haskell/llvm/build/utils/FileCheck'
llvm[2]: Compiling FileCheck.cpp for Debug+Asserts build
llvm[2]: Linking Debug+Asserts executable FileCheck
/home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:
In function `llvm::cl::Option::Option(llvm::cl::NumOccurrencesFlag,
llvm::cl::OptionHidden)':
/home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:242:
undefined reference to `vtable for llvm::cl::Option'
/home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:242:
undefined reference to `llvm::cl::GeneralCategory'
/home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:
In function `llvm::cl::Option::~Option()':
/home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:281:
undefined reference to `vtable for llvm::cl::Option'
/home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:
In function `llvm::cl::GenericOptionValue::~GenericOptionValue()':
/home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:356:
undefined reference to `vtable for llvm::cl::GenericOptionValue'
/home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:
In function `llvm::cl::OptionValue::OptionValue()':
/home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:461:
undefined reference to `vtable for llvm::cl::OptionValue'
/home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:
In function `llvm::cl::basic_parser_impl::~basic_parser_impl()':
/home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:702:
undefined reference to `vtable for llvm::cl::basic_parser_impl'
/home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:
In function
`llvm::PrettyStackTraceProgram::PrettyStackTraceProgram(int, char
const* const*)':
/home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:63: 
undefined
reference to `llvm::PrettyStackTraceEntry::PrettyStackTraceEntry()'
/home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:63: 
undefined
reference to `vtable for llvm::PrettyStackTraceProgram'
/home/varosi/haskell/llvm/include/llvm/Support/PrettyStackTrace.h:64: 
undefined
reference to `llvm::EnablePrettyStackTrace()'
/home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:
In function `llvm::raw_ostream::operator<<(char)':
/home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:136:
undefined reference to `llvm::raw_ostream::write(unsigned char)'
/home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:
In function `llvm::raw_ostream::operator<<(llvm::StringRef)':
/home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:161:
undefined reference to `llvm::raw_ostream::write(char const*,
unsigned long)'
/home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:
In function `llvm::raw_ostream::operator<<(std::string const&)':
/home/varosi/haskell/llvm/include/llvm/Support/raw_ostream.h:177:
undefined reference to `llvm::raw_ostream::write(char const*,
unsigned long)'
/home/varosi/haskell/llvm/build/utils/FileCheck/Debug+Asserts/FileCheck.o:
In function `Pattern::ParsePattern(llvm::StringRef, llvm::StringRef,
llvm::SourceMgr&, unsigned int)':
/home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:176:
undefined reference to `llvm::SourceMgr::PrintMessage(llvm::SMLoc,
llvm::SourceMgr::DiagKind, llvm::Twine const&,
llvm::ArrayRef, llvm::ArrayRef, bool)
const'
/home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:182:
undefined reference to `llvm::StringRef::find(llvm::StringRef,
unsigned long) const'
/home/varosi/haskell/llvm/utils/FileCheck/FileCheck.cpp:183:
undefined reference to `llvm::StringRef::find(llvm::StringRef,
unsigned long

Re: Newcomer Contribution

[Alain O'Dea]

> On Apr 3, 2014, at 13:34, Jim Perry  wrote:
> 
> Hello,
> 
> I am wanting to get involved in GHC development and I thought I'd help out 
> with one of the noob tickets to get more experience. I though I would tackle 
> #2258/#4114. I would be grateful for any advice/guidance for a kick-start.
> 
> Cheers,
> Jim

Hi Jim:

Thank you for joining in :)

Have you downloaded and built GHC?

What kinds of bugs are you looking to fix (build, compiler, library)?

Best,
Alain
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: 7.8.1 plan

[Kyra]

Ah, sorry. Now the policy is to set it to 2mb then.

Cheers,
Kyra

On 03.04.2014 18:50, Austin Seipp wrote:

Actually, the 0x20 for the reserve was just the default in the
executable - I just set it out based on what peflags told me
initially.

Thank you again Kyrill!

On Thu, Apr 3, 2014 at 9:32 AM, kyra  wrote:

Btw,  it is committed size which is important here. I proposed to increase
both only to follow Linux/OSX linker policy which sets stack size to be 8mb
by default, otherwise we could stay at 1mb for both reserved (windows'
default value) and committed values.

Regards,
Kyra


On 03.04.2014 18:00, Austin Seipp wrote:

Kyrill, you are fantastic! I confirmed this incantation seems to have
fixed the problem on my build:

$ peflags --stack-reserve=0x20 --stack-commit=0x20 ghc.exe

with the RC2 build, and not my own. Hooray!

I will work up something soon. Thanks so much again!

On Thu, Apr 3, 2014 at 8:50 AM, Austin Seipp 
wrote:

Oh excellent, thank you for the tip Kyrill, I had no idea about this!
My build is on the way, so I will try this and report back soon.

On Thu, Apr 3, 2014 at 8:34 AM, kyra  wrote:

On 4/3/2014 17:15, Austin Seipp wrote:

Right now, Kyrill has suggested a fix I'm attempting (I slightly
botched my first try), and I have found a way to avoid it at the
moment by turning off optimization (which seems to reduce stack
pressure enough to get by on Windows - see the ticket for details).

It's absolutely not necessary to rebuild everything to check if this
works,
it's enough to edit ghc.exe with peflags utility (which has
--stack-reserve
and --stack-commit options) and look if it stop segfaulting. If I could
reproduce the problem I'd have done this long ago.

Cheers,

Kyra

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs



--
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/




___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs






___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: 7.8.1 plan

[Austin Seipp]

Actually, the 0x20 for the reserve was just the default in the
executable - I just set it out based on what peflags told me
initially.

Thank you again Kyrill!

On Thu, Apr 3, 2014 at 9:32 AM, kyra  wrote:
> Btw,  it is committed size which is important here. I proposed to increase
> both only to follow Linux/OSX linker policy which sets stack size to be 8mb
> by default, otherwise we could stay at 1mb for both reserved (windows'
> default value) and committed values.
>
> Regards,
> Kyra
>
>
> On 03.04.2014 18:00, Austin Seipp wrote:
>>
>> Kyrill, you are fantastic! I confirmed this incantation seems to have
>> fixed the problem on my build:
>>
>> $ peflags --stack-reserve=0x20 --stack-commit=0x20 ghc.exe
>>
>> with the RC2 build, and not my own. Hooray!
>>
>> I will work up something soon. Thanks so much again!
>>
>> On Thu, Apr 3, 2014 at 8:50 AM, Austin Seipp 
>> wrote:
>>>
>>> Oh excellent, thank you for the tip Kyrill, I had no idea about this!
>>> My build is on the way, so I will try this and report back soon.
>>>
>>> On Thu, Apr 3, 2014 at 8:34 AM, kyra  wrote:

 On 4/3/2014 17:15, Austin Seipp wrote:
>
> Right now, Kyrill has suggested a fix I'm attempting (I slightly
> botched my first try), and I have found a way to avoid it at the
> moment by turning off optimization (which seems to reduce stack
> pressure enough to get by on Windows - see the ticket for details).

 It's absolutely not necessary to rebuild everything to check if this
 works,
 it's enough to edit ghc.exe with peflags utility (which has
 --stack-reserve
 and --stack-commit options) and look if it stop segfaulting. If I could
 reproduce the problem I'd have done this long ago.

 Cheers,

 Kyra

 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

>>>
>>>
>>> --
>>> Regards,
>>>
>>> Austin Seipp, Haskell Consultant
>>> Well-Typed LLP, http://www.well-typed.com/
>>
>>
>>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: 7.8.1 plan

[kyra]

Btw,  it is committed size which is important here. I proposed to 
increase both only to follow Linux/OSX linker policy which sets stack 
size to be 8mb by default, otherwise we could stay at 1mb for both 
reserved (windows' default value) and committed values.


Regards,
Kyra

On 03.04.2014 18:00, Austin Seipp wrote:

Kyrill, you are fantastic! I confirmed this incantation seems to have
fixed the problem on my build:

$ peflags --stack-reserve=0x20 --stack-commit=0x20 ghc.exe

with the RC2 build, and not my own. Hooray!

I will work up something soon. Thanks so much again!

On Thu, Apr 3, 2014 at 8:50 AM, Austin Seipp  wrote:

Oh excellent, thank you for the tip Kyrill, I had no idea about this!
My build is on the way, so I will try this and report back soon.

On Thu, Apr 3, 2014 at 8:34 AM, kyra  wrote:

On 4/3/2014 17:15, Austin Seipp wrote:

Right now, Kyrill has suggested a fix I'm attempting (I slightly
botched my first try), and I have found a way to avoid it at the
moment by turning off optimization (which seems to reduce stack
pressure enough to get by on Windows - see the ticket for details).

It's absolutely not necessary to rebuild everything to check if this works,
it's enough to edit ghc.exe with peflags utility (which has --stack-reserve
and --stack-commit options) and look if it stop segfaulting. If I could
reproduce the problem I'd have done this long ago.

Cheers,

Kyra

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs




--
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/





___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM

[Karel Gardas]

On 04/ 3/14 04:05 PM, eng. Vassil Ognyanov Keremidchiev wrote:

Yes, but I don't know what is missing in my workflow.

I did not know if I need LLVM runtime on my target ARM machine.


No, you don't need LLVM runtime. You just need LLVM llc/opt if you'd 
like to cross-compile and build registerised ARM binaries.



 Do I
need? I read that there is unregisterised version for ARM that doesn't
need LLVM. So I just could build Haskell cross-compiler that could work
on my Ubuntu and create binaries for my ARM v7 machine.


If you'd like to use unregisterised /via-C binaries, then you don't need 
LLVM at all, you just need to configure with --enable-unregisterised 
IIRC, but I've not tested that so you are on your own.


Also it comes with its own performance penalty of course:
http://ghcarm.wordpress.com/2011/08/07/nofib-benchmarking/

Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM

[eng. Vassil Ognyanov Keremidchiev]

Yes, but I don't know what is missing in my workflow.

I did not know if I need LLVM runtime on my target ARM machine. Do I need?
I read that there is unregisterised version for ARM that doesn't need LLVM.
So I just could build Haskell cross-compiler that could work on my Ubuntu
and create binaries for my ARM v7 machine.

Am I right?


2014-04-02 19:58 GMT+03:00 Carter Schonwald :

> have you read the cross compiler directions on the wiki? :)
> https://ghc.haskell.org/trac/ghc/wiki/CrossCompilation
> http://www.haskell.org/haskellwiki/ARM
>
>
> On Wed, Apr 2, 2014 at 12:30 PM, eng. Vassil Ognyanov Keremidchiev <
> var...@gmail.com> wrote:
>
>> Hello!
>>
>> Thanks, it continued with building until some LLVM errors.
>> But will --with-gcc= arm based compiler will create GHC with:
>> Host: x86 Ubuntu (where compilation should happen)
>> Target: ARMv7 Linux ?
>>
>> Because I don't want to have GHC on my slow and restricted ARM machine.
>>
>> Best regards,
>>   Vassil
>>
>>
>> 2014-03-28 20:09 GMT+02:00 Karel Gardas :
>>
>>
>>> Last time I did that (crossing to ARMv8) I needed to use
>>> --with-gcc= option since for some reason I had not time to
>>> debug setting target triple with --target was not enough. Speaking about
>>> GHC HEAD as of new year eve (2014) time...
>>>
>>> But well, since it this is already some time I'm not sure this was to
>>> cure issue like you have now, but at least you may give it a try...
>>>
>>> Karel
>>>
>>>
>>> On 03/28/14 06:08 PM, eng. Vassil Ognyanov Keremidchiev wrote:
>>>
 Hello!

 Could someone help me with compiling GHC under Ubuntu as a ARM
 cross-compiler?

 Currently I have done those steps:
 sudo apt-get update
 sudo apt-get install autoconf alex happy libtool autopoint zlib1g-dev
 libncurses5-dev ghc-haddock
 sudo export PATH=~/.cabal/bin:$PATH
 sudo cabal install --reinstall happy alex terminfo libffi html
 regex-compat

 git clone http://darcs.haskell.org/ghc.git
 cd ghc

 ./sync-all --no-dph get
 ./sync-all pull
 ./boot
 sudo ./configure --target=arm-linux-gnueabi --enable-unregisterised
 cp mk/build.mk.sample mk/build.mk 

 # here I enable quick-cross configuration
 sudo make

 and I get:

 echo "compiler_stage1_depfile_c_asm_EXISTS = YES" >>
 compiler/stage1/build/.depend-v.c_asm.tmp
 mv compiler/stage1/build/.depend-v.c_asm.tmp
 compiler/stage1/build/.depend-v.c_asm
 inplace/bin/deriveConstants --gen-header -o
 includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir
 includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc"
 --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag
 -Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header
 --gcc-flag -Iincludes/dist-ghcconstants/header --gcc-flag -Irts
 --gcc-flag -fcommon --nm-program "/usr/bin/arm-linux-gnueabi-nm"
 /usr/bin/arm-linux-gnueabi-nm:
 includes/dist-derivedconstants/header/tmp.o: File format not recognized
 deriveConstants: readProcess: /usr/bin/arm-linux-gnueabi-nm
 "includes/dist-derivedconstants/header/tmp.o" (exit 1): failed
 make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h]
 Error 1
 make: *** [all] Error 2


 What I have done wrong? I did not understand the error message well,
 too.



 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

>>>
>>>
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: 7.8.1 plan

[Austin Seipp]

Kyrill, you are fantastic! I confirmed this incantation seems to have
fixed the problem on my build:

$ peflags --stack-reserve=0x20 --stack-commit=0x20 ghc.exe

with the RC2 build, and not my own. Hooray!

I will work up something soon. Thanks so much again!

On Thu, Apr 3, 2014 at 8:50 AM, Austin Seipp  wrote:
> Oh excellent, thank you for the tip Kyrill, I had no idea about this!
> My build is on the way, so I will try this and report back soon.
>
> On Thu, Apr 3, 2014 at 8:34 AM, kyra  wrote:
>> On 4/3/2014 17:15, Austin Seipp wrote:
>>>
>>> Right now, Kyrill has suggested a fix I'm attempting (I slightly
>>> botched my first try), and I have found a way to avoid it at the
>>> moment by turning off optimization (which seems to reduce stack
>>> pressure enough to get by on Windows - see the ticket for details).
>>
>> It's absolutely not necessary to rebuild everything to check if this works,
>> it's enough to edit ghc.exe with peflags utility (which has --stack-reserve
>> and --stack-commit options) and look if it stop segfaulting. If I could
>> reproduce the problem I'd have done this long ago.
>>
>> Cheers,
>>
>> Kyra
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: 7.8.1 plan

[Austin Seipp]

Oh excellent, thank you for the tip Kyrill, I had no idea about this!
My build is on the way, so I will try this and report back soon.

On Thu, Apr 3, 2014 at 8:34 AM, kyra  wrote:
> On 4/3/2014 17:15, Austin Seipp wrote:
>>
>> Right now, Kyrill has suggested a fix I'm attempting (I slightly
>> botched my first try), and I have found a way to avoid it at the
>> moment by turning off optimization (which seems to reduce stack
>> pressure enough to get by on Windows - see the ticket for details).
>
> It's absolutely not necessary to rebuild everything to check if this works,
> it's enough to edit ghc.exe with peflags utility (which has --stack-reserve
> and --stack-commit options) and look if it stop segfaulting. If I could
> reproduce the problem I'd have done this long ago.
>
> Cheers,
>
> Kyra
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: 7.8.1 plan

[kyra]

On 4/3/2014 17:15, Austin Seipp wrote:

Right now, Kyrill has suggested a fix I'm attempting (I slightly
botched my first try), and I have found a way to avoid it at the
moment by turning off optimization (which seems to reduce stack
pressure enough to get by on Windows - see the ticket for details).
It's absolutely not necessary to rebuild everything to check if this 
works, it's enough to edit ghc.exe with peflags utility (which has 
--stack-reserve and --stack-commit options) and look if it stop 
segfaulting. If I could reproduce the problem I'd have done this long ago.


Cheers,
Kyra

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Newcomer Contribution

[Jim Perry]

Hello,

I am wanting to get involved in GHC development and I thought I'd help out
with one of the noob tickets to get more experience. I though I would
tackle #2258/#4114. I would be grateful for any advice/guidance for a
kick-start.

Cheers,
Jim
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: 7.8.1 plan

[Austin Seipp]

Hi all,

One final update: I have found a workaround for the issue Mateusz
reported last week. Luckily it can be fought off somewhat easily for
now for OS X users, but there are more details here:
https://github.com/haskell/cabal/issues/1740

The final thing that ended up being a hold-up is now #8870 - the 32bit
Windows distribution is segfaulting. At first, I thought this was an
anomaly, but I saw several other people who also reported this
problem. After a bit of sweat I've finally reproduced this bug and
tracked this down part of the way, but I've been especially confused
by this issue because apparently it does not affect everyone! Which is
quite bizarre, as given the results I found, I'd suspect everyone to
see it.

Right now, Kyrill has suggested a fix I'm attempting (I slightly
botched my first try), and I have found a way to avoid it at the
moment by turning off optimization (which seems to reduce stack
pressure enough to get by on Windows - see the ticket for details).

Are there any Windows users who would be willing to test a 32bit
Windows binary distribution, should I make a provisional one? I can
have it up within a few hours from now. I'd really love some outside
confirmation of this problem and a resolution once we have it!

As this is the last bug, if I can at least get some confirmation a fix
works, I can have the final release out immediately afterwords - the
tree is otherwise quiet and will remain so.

On Tue, Mar 25, 2014 at 5:24 PM, Austin Seipp  wrote:
> Hello all,
>
> As an updated, I'm looking into the report Mateusz had of 'free'
> failing to build haddocks on OS X*, which I've reproduced. It seems
> nasty - I'll follow up with details ASAP.
>
> * See his recent email to ghc-devs about this problem.
>
> On Tue, Mar 25, 2014 at 12:11 PM, Mateusz Kowalczyk
>  wrote:
>> On 25/03/14 17:09, kyra wrote:
>>> On 3/25/2014 20:52, Mateusz Kowalczyk wrote:
 The only instances of Haddock becoming really slow that I can think of
 is some rather old ticket (#101 on Haddock Trac) in presence of Template
 Haskell but I have closed it a while ago due to lack of information to
 go on and inability to replicate without the reporter's help. Perhaps
 this was your use case?

>>> Aha, this is why I could not reproduce it! I checked it on packages
>>> which used no TH, and that slow behaviour occurred when TH was involved!
>>>
>>> I think it is TH which really triggers producing and splitting of an
>>> assembly output and in this case no-splitting gives *huge* benefit.
>>> Sadly, I have no time to check this right now.
>>>
>>> Regards,
>>> Kyra
>>>
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>
>> There's no rush as it's not going to get into 7.8.1 anyway but I would
>> love to see some numbers before 7.8.2 so please keep us in mind.
>>
>> Thanks!
>>
>> --
>> Mateusz K.
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GHC Trac donw

[Herbert Valerio Riedel]

On 2014-04-03 at 10:19:42 +0200, Simon Peyton Jones wrote:
> Accessing the GHC Trac yields

[...]

> TracError: The Trac Environment needs to be upgraded.
>
> Run "trac-admin /home/trac/ghc upgrade"

Sorry, that was me; I was installing the spam-filter plugin and that
required an upgrade long enough to be noticed... :-)

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

GHC Trac donw

[Simon Peyton Jones]

Accessing the GHC Trac yields
https://ghc.haskell.org/trac/ghc/

Error

TracError: The Trac Environment needs to be upgraded.

Run "trac-admin /home/trac/ghc upgrade"


Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: [GHC] #8953: Inner Thigh Slimming Exercises for Women

[Simon Peyton Jones]

Folks,

The GHC Trac is attracting spam.  Does anyone know enough to stop it?

Simon

| -Original Message-
| From: ghc-tickets [mailto:ghc-tickets-boun...@haskell.org] On Behalf Of
| GHC
| Sent: 03 April 2014 05:26
| Cc: ghc-tick...@haskell.org
| Subject: [GHC] #8953: Inner Thigh Slimming Exercises for Women
| 
| #8953: Inner Thigh Slimming Exercises for Women
| +---
| +--
|Reporter:  szxdai1   | Owner:
|Type:  bug   |Status:  new
|Priority:  normal| Milestone:
|   Component:  Compiler  |   Version:  7.6.3
|Keywords:|  Operating System:
| Unknown/Multiple
|Architecture:  Unknown/Multiple  |   Type of failure:  None/Unknown
|  Difficulty:  Unknown   | Test Case:
|  Blocked By:|  Blocking:
| Related Tickets:|
| +---
| +--
|  How To Decline Thigh Coefficient or retrogress weight swift around your
| thighs offers quite a bit to do with intrinsic helping slimming
| exercises.
|  The easiest method to worsen weight from your thighs would be to do
| exercises that aim your minify body. Inside serving slimming workouts
| are  those workouts that mostly rivet on the fat around your exclusive
| thighs.
|  Virtuous some any portion training contributes to losing helping
| coefficient mostly. When you essential to worsen coefficient around your
| privileged thighs and immobile up, You may penury to accomplish several
| special exercises that alter on this region. I am achievement to part
| with  you two of the most operative helping slimming exercises.
|  [http://tryabsolutegarciniacambogia.com/ ABSOLUTE GARCINIA CAMBOGIA]
| Decline unit accelerated Around Your Thighs Workouts  Leg Butterfly
| Broad: -This use works rise for broad the intrinsical  thighs, Making
| yourself solon elastic and in acquisition it helps with the  toning of
| the thighs. To perform this workout, You instrument hump to sit  on a
| carpeted story after which juncture your soles from the feet  together.
| Your legs is accomplishment to be unstoppered but both of the  feet
| instrument attack apiece other. When you're in this berth,  Countenance
| the knees to alter to the flooring. Lessen your knees towards  the
| flooring as much as you can for the way pliable you are. Spell
| performing this recitation, rub both hands stretchability around your
| privileged thighs.
|  Intrinsical Serving Firmer Workout: -You give feature to fulfill this
| helping slimming learn part a small layer and also be certain you
| somebody  a towel or a dinky wide to relax your brain on. To fulfil this
| workout,  Lie in your sinistral indorse and urinate careful your surface
| is resting  on a folded departed towel or bittie encompassing. This
| truly is to coil.
|  And protect your manus leg change to the base, Slowly flex the best leg
| towards the deceiver individuals. Now you gift essential to uprise your
| unexhausted leg for active six inches off the level and suppress it for
| many transactions. Then petty it to the turn item and now cultivate it
| as  existence presently as it touches the mat  {other tract endorse. Do
| that sleazy portion workout on the sides with the  similar repeating.
|  These serving slimming workouts are painless to fulfil and they could
| be  comfortably through from the status of your own asylum. If you are
| disagreeable to chant up and get narrow thighs, Then I suggest that you
| do  aerophilic exercises too. Recollect your fasting as what you eat
| counts  for your upbeat too. For statesman useful message on how to
| retrograde  serving coefficient in the subordinate part of your body,
| Impose  Privileged helping slimming exercises beneath. Recede metric
| firm around  your thighs is about punish in both consumption a growing
| fasting  organisation and regular workout.'''ABSOLUTE GARCINIA
| CAMBOGIA'''
|  Decline metric allegro around your thighs else finest workouts which
| are  outgo extricated permit functional, Jogging and aquatics. They are
| fun to  do exercises that you ought to sicken benefit of. Don't think
| that  visiting the gym is the exclusive way to total serving slimming
| exercises.
|  Keep your expensive gym body money and remain physically energetic by
| exertion from base and doing fun aerophilous workouts inaccurate.
|  http://tryabsolutegarciniacambogia.com/
| 
| --
| Ticket URL: 
| GHC 
| The Glasgow Haskell Compiler
| ___
| ghc-tickets mailing list
| ghc-tick...@haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-tickets