RE: [GHC] #8953: Inner Thigh Slimming Exercises for Women
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: http://ghc.haskell.org/trac/ghc/ticket/8953
| GHC http://www.haskell.org/ghc/
| The Glasgow Haskell Compiler
| ___
| ghc-tickets mailing list
| ghc-tick...@haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-tickets
GHC Trac donw
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: 7.8.1 plan
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 aus...@well-typed.com 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 fuuze...@fuuzetsu.co.uk 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
Newcomer Contribution
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
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
Re: 7.8.1 plan
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 ky...@mail.ru 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
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 aus...@well-typed.com 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 ky...@mail.ru 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: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM
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 carter.schonw...@gmail.com: 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 karel.gar...@centrum.cz: Last time I did that (crossing to ARMv8) I needed to use --with-gcc=cross compiler 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 http://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: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM
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: 7.8.1 plan
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 aus...@well-typed.com 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 ky...@mail.ru 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
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 ky...@mail.ru 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 aus...@well-typed.com 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 ky...@mail.ru 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
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 ky...@mail.ru 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 aus...@well-typed.com 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 ky...@mail.ru 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: Newcomer Contribution
On Apr 3, 2014, at 13:34, Jim Perry jpez.i...@gmail.com 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: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM
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 var...@gmail.com 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::OptionValuestd::string::OptionValue()': /home/varosi/haskell/llvm/include/llvm/Support/CommandLine.h:461: undefined reference to `vtable for llvm::cl::OptionValuestd::string' /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::ArrayRefllvm::SMRange, llvm::ArrayRefllvm::SMFixIt, 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
Re: Haskell Support on Windows (Simon Peyton Jones)
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 carter.schonw...@gmail.com: 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 kuzn...@hotmail.com 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 simo...@microsoft.com 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: 7.8.1 plan
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: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-citeproc / highlighting-kate
On Sat, 22 Mar 2014 22:21:42 +0300
Sergei Trofimovich sly...@gmail.com 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 -Ksize 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 -Ksize 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***CRASH
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: Fwd: Trying to compile GHC under Ubuntu as a cross-compiler for ARM
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 http://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 var...@gmail.com 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 karel.gar...@centrum.cz 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 var...@gmail.com mailto:var...@gmail.com mailto:var...@gmail.com mailto:var...@gmail.com: I'm trying to compile LLVM as is described in: http://bgamari.github.io/__posts/cross-compiling_llvm.__html 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::OptionValuestd::__string::OptionValue()': /home/varosi/haskell/llvm/__include/llvm/Support/__CommandLine.h:461: undefined reference to `vtable for llvm::cl::OptionValuestd::__string' /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
