Re: Windows/R issue with FFI

il_source=link_campaign=sig-email_content=webmail> > <#m_7940054291392109769_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > On Mon, Mar 27, 2023 at 9:48 AM Phyx wrote: > >> Hi, >> >> I'm missing some details here here as I'm having trouble following the >>

Re: Windows/R issue with FFI

Hi, I'm missing some details here here as I'm having trouble following the flow. What provides the symbol for that import? As in where does R_NilValue come from? As in, how is it defined. Are you linking against a library or C sources? When you say you replace the trace statement, do you keep

Re: Buy-in for technical proposal 47 which affect GHC devs

ent scheme for how dynamic-too works on Windows. So I wanted to see if the implementation cost isn't high if we could do the library split now. But if it is then no problem, I'll find a work around. Thanks, Tamar On Sat, Mar 25, 2023, 16:54 Ben Gamari wrote: > Phyx writes: > > >&

Re: Buy-in for technical proposal 47 which affect GHC devs

and GHC should be fixed). Thanks, Tamar On Fri, Mar 24, 2023, 21:18 Ben Gamari wrote: > Phyx writes: > > > Hi, > > > > Though I'm no longer a very active GHC developer I do have some > questions. > > > > Overall I'm in support of this but I think I'd rath

Re: Buy-in for technical proposal 47 which affect GHC devs

Hi, Though I'm no longer a very active GHC developer I do have some questions. Overall I'm in support of this but I think I'd rather see an outright split from the start rather than first having a forwarder library. The reason for this is that I'm afraid of the performance impact of having this

Re: The GHC(i)/RTS linker and Template Haskell

Hi Alexis, Most information on this can be found on the Wiki, where a lot of these design decisions are made. e.g. https://gitlab.haskell.org/ghc/ghc/-/wikis/dynamic-ghc-programs The points you've figured out are correct so far, to answer some of your questions: > But I don’t actually

Install WIP app in haskell org

Hi Ben, Is it possible to install the WIP app into the github Haskell org? https://github.com/apps/wip It's quite handy to mark things as in progress. Regards, Tamar ___ ghc-devs mailing list ghc-devs@haskell.org

Re: [ANNOUNCE] GHC 9.2.1-alpha1 now available

Hi, Typically a GHC release is tied to a new cabal release as well. I however can't find a new tag for Cabal. Does this mean I need to use cabal-head or can I use Cabal 3.4? Thanks, Tamar On Thu, Apr 1, 2021 at 5:44 PM Ben Gamari wrote: > Hi all, > > The GHC developers are very happy to

Re: Options for targeting Windows XP?

Hi, > XP. GHCJS seems to at least have a compiler based on GHC 8.6. > 2. Patch GHC with an additional command line argument to produce XP/Vista compatible executables, perhaps by looking at the changes between 7.10 -> 8.0, and re-introducing the XP approach as an option. This would be somewhat

Re: GHC 8.10 backports?

Hi, I currently have https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5055 marked for backports but don't know if it was done or not. Thanks, Tamar Sent from my Mobile On Mon, Mar 22, 2021, 04:33 Moritz Angermann wrote: > Hi there! > > Does anyone have any backports they'd like to see for

Re: What changed between GHC 8.8 and 8.10 that could cause this?

I calls where the RTS loads/links > an object file twice. > And we're not even explicitly linking/loading object files twice, > something to do with the GHC type-checker seems to do that. > I don't see how I can avoid this issue without being forced to run within > a single `runGhc` sess

Re: What changed between GHC 8.8 and 8.10 that could cause this?

Hi, Hmm... I don't agree.. This isn't about grounds of truth or anything like that.. and in fact, an object being in the linker map, doesn't mean its usable at all or meant to be used at all. It can be temporary state (symbol redirection or supporting of deprecated symbols are two that come to

Re: GHC 9.1?

I am also against not using the odd/even versioning scheme. My objections are similar to what Edward mentioned in that adding "junks" at the end of the build number is problematic for packagers of the toolchain where the packaging has its own way to mark something pre-release. If GHC were to

Re: Stop holding hadrian back with backwards compatibility

Hi, Just leaving my two cents feel free to ignore.. > I almost suggested that this had to be the reason for the back-compat design You're right, but not for backwards compat of Hadrian vs Make, but for compat with RTS versions. I could be wrong, but my understanding is the current design in Make

Re: Has ghc-9.0 for windows changed to require installation?

No, there's no change at all in the portability. This looks like a fallout from switching from Make to Hadrian. ghcii.sh was created as an artifact of make install. Hadrian seems to lack this step. Note that this script is nothing magical, it's just a hack around how signal handlers in Native

Debugging annotation machinery

Hi, I am changing the hashing algorithm used to create Fingerprints but somehow the annrun01.hs test has started failing and I don't quite understand why. >From what I can tell the failure happens during deserialization but the module itself is still found. The calls findGlobalAnns

Re: [ANNOUNCE] Glasgow Haskell Compiler 8.10.3 released

Hi Ben, The package ghc-8.10.3-x86_64-unknown-mingw32-integer-simple.tar.xz reports Tamar@PowPow /t/ghc> ./ghc-8.10.3/bin/ghc.exe -v Glasgow Haskell Compiler, Version 8.10.3, stage 2 booted by GHC version 8.8.3 ... wired-in package integer-wired-in mapped to integer-gmp-1.0.3.0 ... Tamar@PowPow

Re: msys woes

Gamari wrote: > Phyx writes: > > > Right, > > > > I think seems to be a bug in the script that wasn't noticed before. > > > > On line 40 there are () missing around the condition. So it's checking > both > > URLs i think. > > > > The download

Re: msys woes

020, 17:55 Phyx wrote: > Right, > > I think seems to be a bug in the script that wasn't noticed before. > > On line 40 there are () missing around the condition. So it's checking > both URLs i think. > > The download to Haskell.org succeeds but the msys2 one fails s

Re: msys woes

; >> >> On Thu, Oct 8, 2020 at 12:13 PM Phyx wrote: >> >>> Hi Shayne, >>> >>> 8.8.1 had a different mechanism but the primary is still haskell.org. >>> >>> >> I think we are looking at ghc-8.4.3 here (being used on 8.8.1 sources). &

Re: msys woes

, 2020, 15:54 Shayne Fletcher wrote: > > > On Thu, Oct 8, 2020 at 10:51 AM Shayne Fletcher < > shayne.fletcher...@gmail.com> wrote: > >> >> Hi Phyx, >> >> On Thu, Oct 8, 2020 at 9:10 AM Phyx wrote: >> >>> > `./configure --enable-tarbal

Re: msys woes

> `./configure --enable-tarballs-autodownload` GHC build step on Windows has been failing because repo.msys2.org Afaik GHC doesn't rely ok repo.msys2.org for builds, only for mirroring. The primary url is haskell.org https://downloads.haskell.org/ghc/mingw/ So it's down time shouldn't have

Re: New Windows I/O manager in GHC 8.12

Thanks Simon, cheers :) Sent from my Mobile On Mon, Jul 20, 2020, 15:28 Simon Peyton Jones wrote: > Tamar, I salute you! This is a big piece of work – thank you! > > > Simon > > > > *From:* ghc-devs *On Behalf Of *Phyx > *Sent:* 17 July 2020 16:04 > *

Re: New Windows I/O manager in GHC 8.12

Hi Mikhail, Thanks! And thanks for the jump start :) Cheers, Tamar Sent from my Mobile On Sun, Jul 19, 2020, 09:05 Mikhail Glushenkov wrote: > Hi Tamar, > > Congratulations on getting WinIO merged, this is a really impressive > effort. > ___ >

Re: New Windows I/O manager in GHC 8.12

Oops just a correction here, should be Joseph Adams instead of Joey Hess in the attribution. Regards, Tamar Sent from my Mobile On Fri, Jul 17, 2020, 16:03 Phyx wrote: > Hi All, > > In case you've missed it, about 150 or so commits were committed to master > yesterday. These

Re: New Windows I/O manager in GHC 8.12

inIO branch for a few > months and this is absolutely a game-changer for Windows support. > > Thanks! > > Travis > > On Fri, Jul 17, 2020 at 8:06 AM Phyx wrote: > > > > Hi All, > > > > In case you've missed it, about 150 or so commits were committed to >

New Windows I/O manager in GHC 8.12

Hi All, In case you've missed it, about 150 or so commits were committed to master yesterday. These commits add WinIO (Windows I/O) to GHC. This is a new I/O manager that is designed for the native Windows I/O subsystem instead of relying on the broken posix-ish compatibility layer that MIO

Re: HEAD doesn't build. Totally stalled.

But, where do you actually check for __SSP__ The guard just checks for not windows and not dynamic https://github.com/ghc/ghc/commit/686e72253aed3880268dd6858eadd8c320f09e97#diff-03f5bc5a50fd8ae13e902782c4392c38R1157 shouldn't it just be checking for defined(__SSP__) instead? This check is

Re: Evac.c

Hi Ben, Just FYI, gcc 9 added -fdiagnostics-format=json so that may be an option to make this sort of thing easier to handle. Kind regards Tamar Sent from my Mobile On Thu, Jun 11, 2020, 17:50 Ben Gamari wrote: > Simon Peyton Jones via ghc-devs writes: > > > I'm getting this in HEAD.

Github mirror

Hi Ben, It looks like the github mirror for ghc hasn't updated in a month. Kind regards, Tamar Sent from my Mobile ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Windows testsuite failures

use I'm only paid by the > time I > spend productively. I'd be happier waiting for the CI then. > Yeah, not waiting for CI is how we got in this mess in the first place. Tamar. > Ömer > > [1]: https://gitlab.haskell.org/ghc/ghc/-/jobs/237457 > [2]: https://gitlab.haskell.o

Re: Windows testsuite failures

ore often than once in 6 months. > > We clearly have no idea how to test on Windows. If you know how to do it > then > feel free to submit a MR. Otherwise blocking every MR indefinitely is > worse than > testing Windows less frequently. > > Ömer > > Phyx , 17 Oca 202

Re: Windows testsuite failures

Sure because only testing once every 6 months is a very very good idea... Sent from my Mobile On Fri, Jan 17, 2020, 06:03 Ömer Sinan Ağacan wrote: > Hi Ben, > > Can we please disable Windows CI? I've spent more time fighting the CI than > doing useful work this week, it's really frustrating. >

Re: More failure

Hi Andrey, I'm not sure what the original issue here is (should probably find the original message) but > The Make build system happens to do the right thing, somehow. I believe we should be able to express the same logic in Shake, but it's not easy. I believe this typically works because GCC

Re: Tracking Progress of #7353 (New Windows IO Manager)

Hi Travis, The current MR with my WIP is at https://gitlab.haskell.org/ghc/ghc/merge_requests/1224 This should build without a problem (on Windows, haven't sorted the Linux build failures yet). The threaded version passes the testsuite (i.e. -threaded +RTS --io-manager=native) but the

margebot.

Hello, margebot seems down, or did I miss a memo on how to commit now? Cheers, Tamar ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: gitlab upgrade - change in approval system

I have noticed that you can work around this by editing the Mr and adding yourself explicitly to the approvals list for it. It then allows you to approve it. Sent from my Mobile On Fri, May 17, 2019, 13:54 Ryan Scott wrote: > I would definitely appreciate changing Marge's behavior back to the

Re: Old build system broken

That looks like stage1 has been improperly configured. Does /home/simonpj/code/HEAD/inplace/bin/ghc-stage1 --info *Return anything sensible for target arch? * *I still use the make system exclusively and haven't noticed a failure. * *But my nightlies haven't kicked off yet today. * *Thanks, *

Re: Marge bot UX improvement suggestion

Speaking of bots.. What's a Moe bot? Haha. Sent from my Mobile On Thu, Apr 25, 2019, 16:06 Ben Gamari wrote: > Ömer Sinan Ağacan writes: > > > I think it'd be useful if Marge listed commits that it's trying to merge > in the > > description of the MR so that we could get a list of commits in

Re: Validation Failures on aarch64

Just a wild guess, but considering the time it's taken to run through the testsuite you're running it on a reasonable AArch64 machine. You may be hitting the weak memory ordering bugs https://gitlab.haskell.org/ghc/ghc/issues/15449 , though I haven't followed the ticket very closely... On Mon,

Re: GHC label conventions

Hi Ben, > I consider Linux/x86-64 to be the default; e.g. if there a ticket isn't > labelled with one of the operating system labels then it should be > assumed that either the issue is OS-independent or it's Linux. This is a > compromise but given that we need to assign labels manually, it

Re: GitHub Mirror is broken

Hi Ben, I think the mirror is stuck again. Hasn't updated in 8 days. Cheers, Tamar On Tue, Feb 19, 2019 at 6:30 AM Ben Gamari wrote: > Artem Pelenitsyn writes: > > > Hello devs, > > > > This is just to let you know that the latestes commit on GitHub ghc/ghc > > repo dates back to 22th of

Re: Proposal: Don't read environment files by default

> I am quite confused as to how people are using `ghci` without loading the environment files, at least in the context of cabal v2 (aka "new cabal"). When you run `ghci` on its own, unless you load an environment file, you would only have access to globally installed packages, which is almost

Re: Windows release quality

Hi Andreas, GHC 8.6.4 not supporting profiling libs was the first thing mentioned in the release email - A regression resulting in segmentation faults on Windows introduced by the fix for #16071 backported in 8.6.3. This fix has been reverted, meaning that 8.6.4 is once again susceptible

Re: Discussion: Hadrian's defaults

Agreed, I was also an opponent of -c as the default, and as you pointed out it only works for the case where the default is used. But even if the defaults are used it is still harmful to do it automatically as the user's environment could have changed resulting in different configure output if you

Re: Trac to GitLab migration underway

Hi all, Question, how do I view only Windows issues? I see there is a windows tag but nothing is linked to it. And tickets contain sporadically the "Trac Metadata" field. So I'm not sure how to get the same overview I used on trac. Kind regards, Tamar On Tue, Mar 12, 2019, 18:42 Richard

Re: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration

Can they be sent from a different email address than the main. Gitlab+margebot are quite. Ahum, noisy.. and filtering based on message content has a potential for false positives. Kind regards, Tamar On Wed, Mar 6, 2019, 12:33 Matthew Pickering wrote: > I think gitlab can be configured so

Re: [ANNOUNCE] GHC 8.6.4 is now available

Thanks! To be fair I'm not really sure how popular it is. I was wondering since once I upload the chocolatey packages it's immutable. If there's anything I can help with let me know. Cheers, Tamar On Tue, Mar 5, 2019, 21:47 Ben Gamari wrote: > Phyx writes: > > > Hi Ben, &g

Re: [ANNOUNCE] GHC 8.6.4 is now available

Hi Ben, Thanks for the release! I was wondering, any reason for the no i386 Windows? Should I just create the package without it or is it coming? Thanks, Tamar On Tue, Mar 5, 2019 at 8:53 PM Ben Gamari wrote: > > Hello everyone, > > The GHC team is very happy to announce the availability of

Re: Scaling back CI (for now)?

That aside, the CIs don't seem stable at all. Frequent timeouts even before they start. I have been trying to merge 3 changes for a while now and everytime one of them times out and I have to restart the timed out ones. Then there are merge conflicts and I have to start over. This is "bot

Re: WIP branches

The solution I use to this branch overload is changing my fetch refspecs to list explicitly the branches I want. https://git-scm.com/book/en/v2/Git-Internals-The-Refspec It's not ideal but it gets the job done. I wish git allowed you to exclude branches instead, as I could just exclude /wip/*

Re: Thoughts on the Contributing page

> > Indeed. I hope it's not difficult to fix this, but I'm not sure where to > start. Any suggestions are very welcome. > > It is unfortunately, because it's not a bug. Odds are both of you are using MinTTY which people blindly recommend to use. The problem is MinTTY is not designed to run native

Re: [ANNOUNCE] You should try Hadrian

that `doc/windows.md` hasn’t been updated when > moving to GitLab, and created this MR to fix this: > > > > https://gitlab.haskell.org/ghc/ghc/merge_requests/239 > > > > Please jump into the comments there if you’d like me to fix/clarify > anything. > > >

Re: [ANNOUNCE] You should try Hadrian

Hi Andrey, I'm looking at https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md and https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/windows.md wondering why the default instructions for Windows are using stack, this isn't currently the case. In order for ./boot and

Re: Using same stdout/stderr files for multiple tests?

Actually, I had a few minutes to spare on the train so https://gitlab.haskell.org/ghc/ghc/merge_requests/226 :) Cheers, Tamar On Sun, Jan 27, 2019 at 4:36 PM Phyx wrote: > Hi Omer, > > If you frequently require this it would be a trivial thing to add, it's a > small

Re: Using same stdout/stderr files for multiple tests?

Hi Omer, If you frequently require this it would be a trivial thing to add, it's a small modification to find_expected_file, I can probably find some time next week to do this for you if you want. > > I don't believe there is a way to do this. I would likely make > test_debug.stdout a symlink to

Re: [GitLab] Introducing Marge-bot

> I also don't think one should be allowed to approve their own > PR. If it is trivial enough to justify a self-accept then someone else > should also be able to trivially accept it. I disagree whole heartedly, as someone who's had to wait weeks for trivial patches to get reviews no thanks. We

Re: MR does not merge

The problem is with the different platforms that need to be tested. I could see this getting stuck in an infinite retest and rebase loop because you have to wait on different builds to finish not just one. So I think this is a harder problem to solve than we're making it out to be. The system

Re: Blocking a task indefinitely in the RTS

ing to model? > > On Tue, Jan 8, 2019 at 3:56 AM Phyx wrote: > >> > Oh, I see :( I guess it's not that easy of a fix then. Perhaps the >> RTS could use a new intrinsic for blocking on foreign state >> >> Yeah, that's what I was/am currently working on, &q

Re: Blocking a task indefinitely in the RTS

> Oh, I see :( I guess it's not that easy of a fix then. Perhaps the RTS could use a new intrinsic for blocking on foreign state Yeah, that's what I was/am currently working on, "IOPort" has much of the same property of MVar but doesn't have this deadlock guarantee and only supports a single

Re: Blocking a task indefinitely in the RTS

> Maybe that should be considered a false positive (bug) for the deadlock checker? Just because the Haskell runtime has a single thread, that doesn't imply the whole program is necessarily single-threaded (in the presence of foreign things). I'd think this is a legitimate use case for MVars.

Re: Blocking a task indefinitely in the RTS

is still alive? Can you show the code that > you're testing? > > On Mon, Jan 7, 2019, at 14:09, Phyx wrote: > > Hi Phil, > > > > Thanks for the reply, however that just gives me a forced deadlock > removal > > as before. > > > > new bound thr

Re: Blocking a task indefinitely in the RTS

world. Kind regards, Tamar On Mon, Jan 7, 2019 at 5:44 AM John Lato wrote: > Can you use an os-level structure? E.g. block on a file descriptor, > socket, or something like that? > > On Sun, Jan 6, 2019, 10:37 Phyx >> Hi All, >> >> I'm looking for a way to b

Re: Blocking a task indefinitely in the RTS

-- giveToExternalCode awaken > takeMVar mvar > > On Sun, Jan 6, 2019, at 10:37, Phyx wrote: > > Hi All, > > > > I'm looking for a way to block a task indefinitely until it is woken up > by > > an external event in both the threaded and non-t

Blocking a task indefinitely in the RTS

Hi All, I'm looking for a way to block a task indefinitely until it is woken up by an external event in both the threaded and non-threaded RTS and returns a value that was stored/passed. MVar works great for the threaded RTS, but for the non-threaded there's a bunch of deadlock detection in the

Re: Windows test failures

forgot to copy in ghc-devs. On Fri, Dec 7, 2018 at 12:05 AM Phyx wrote: > Ah great, > > Normally an msys2 .profile will contain the following line > > # Set user-defined locale > export LANG=$(locale -uU) > > which would attach ".UTF-8" to the user's current l

Re: Windows test failures

ntercalate "," opts > ++ ")" >return pm > > New code for function SourcePlugin.hs:interfaceLoadPlugin' > > interfaceLoadPlugin' :: [CommandLineOption] -> ModIface -> IfM lcl ModIface > interfaceLoadPlugin' _ iface > = do liftIO $ putStrLn $

Re: Windows test failures

quot;en_GB" > > LC_COLLATE="en_GB" > > LC_MONETARY="en_GB" > > LC_MESSAGES="en_GB" > > LC_ALL= > > > > Does that help at all? > > > > I can try your “export LANG=en_GB.UTF-8” … shall I do that? Can I test > its eff

Re: Windows test failures

Roland > > PS: I can't say anything about the tests 'plugin-recomp-pure' and > 'plugin-recomp-impure' as these tests run successfully on my (slow) Windows > box. > > Am Sonntag, den 02.12.2018, 20:42 + schrieb Phyx: > > Hi Simon, > > That's a bit better (stil

Re: Windows test failures

> Simple Plugin Pass Run > > Simple Plugin Passes Queried > > Access violation in generated code when reading 0xa824 > > > > Attempting to reconstruct a stack trace... > > > >Frame Code address > > * 0x49adab0 0x1eb49ec C:\code\HEAD\inplace\bin\ghc

Re: Windows test failures

d > > Access violation in generated code when reading 0xa824 > > > > Attempting to reconstruct a stack trace... > > > >Frame Code address > > * 0x49adab0 0x1eb49ec C:\code\HEAD\inplace\bin\ghc-stage2.exe+0x1ab49ec > > > > make[1]: *** [Makefile:99:

Re: Windows test failures

wrote: > Ben, Phyx, and other CI folk > > ‘sh validate –fast’ still gives a lot of failures on Window. The output > is below. I would be so good to get this to zero! > > (another minor thing is that it would be great to eliminate the long path > at the beginning – this is pl

Re: split_marker crash

> > > > *From:* Andreas Klebinger > *Sent:* 19 November 2018 20:38 > *To:* Ben Gamari > *Cc:* Phyx ; Simon Peyton Jones < > simo...@microsoft.com>; ghc-devs@haskell.org > *Subject:* Re: split_marker crash > > > > I might already have found the specific cause

Re: split_marker crash

On Mon, Nov 19, 2018 at 8:33 PM Ben Gamari wrote: > Andreas Klebinger writes: > > > Hello, > > > > I'm fine with reverting for now. But could you give me a way to > > reproduce this error? > > > > I've not seen crashes on either linux and windows in various configs. > > > I suspect that Simon

Re: [ANNOUNCE] GHC 8.6.1 released

Hi All, I've made a ticket for this but it seems it hasn't gotten any attention at all. As it stands now the 8.6.1 tarballs for Windows are a bit broken. Because of a mistake I've made during the mapping of the ACLs from fopen to CreateFile it's accidentally asking for WRITE attributes rights

Re: Windows testsuite failures

skell.org/trac/ghc/ticket/15670 > > https://ghc.haskell.org/trac/ghc/ticket/15671 > > > > these should bring down the amount of failing tests to about 5. > > > > Kind Regards, > > Tamar > > > > *From: *Simon Peyton Jones > *Sent: *Thursday, September 20,

Re: constant pooling in GHC

anings, but what do you mean specifically? > > On Sat, Sep 15, 2018 at 10:33 AM Phyx wrote: > >> Hi All, >> >> I'm hoping someone here can save me some time. I'm working on something >> that relies on constants in the same translation unit being pooled before >&g

Re: Windows testsuite failures

Hi Simon, Thanks for the email. I haven't been building head much as I'm working on top of some older commits. From a quick look it seems like the plugin ones are probably testisms, the plugins aren't found so likely a missing path entry somewhere. The linker ones are are weird, I'll need to

constant pooling in GHC

Hi All, I'm hoping someone here can save me some time. I'm working on something that relies on constants in the same translation unit being pooled before assembly. I've noticed GHC does some const pooling at -O1 , but this doesn't seem to be very consistent, which leads me to believe this is a

Re: Haskell DLL (using FFI) causes memory leak.

Oh and also, neither of those tickets you linked to should prevent you from using a newer GHC to make shared libraries. the Rts.h headers are nothing but convenience functions and you can just create the prototypes you need in your own headers. On Mon, Aug 27, 2018 at 5:46 PM Phyx wrote: >

Re: Haskell DLL (using FFI) causes memory leak.

Hi, You're likely just hitting a memory leak, Haskell DLLs and the RTS aren't designed to be unload-able, which is why you can't call hs_init again after you stop. The leak happens only when you do a foreign export because foreign exports create C wrappers to initializers for each function you

Re: [ANNOUNCE] GHC 8.6.1-beta1 available

Hi Ben, I forgot to update the changelog at the time I think, It should probably be stated that this release fixes the 32 bit Windows segfaults. Cheers, Tamar On Sat, Aug 11, 2018 at 3:31 AM, Ben Gamari wrote: > > Hello everyone, > > The GHC development team is very pleased to announce the

Re: Harbormaster: Build failure on OS/X build. How to fix it as a non Mac user

Hi, They are stats failures. Not good enough, which means you have a regression in memory usage. Look at the full test log https://phabricator.haskell.org/harbormaster/build/48354/1/?l=100 They also failed on windows, but currently harbormaster doesn't fail when tests fail for windows. Clicking

Re: Strace

mple-plugin > package.plugins01 TOP=/c/code/HEAD/testsuite* > > *cd "./T14335.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c > T14335.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagno

Re: Strace

just replay the action it did. Cheers, Tamar > > Thanks > > > > Simon > > > > *From:* Phyx > *Sent:* 13 June 2018 17:19 > *To:* Simon Peyton Jones > *Cc:* ghc-devs@haskell.org > *Subject:* Re: Strace > > > > Hi Simon, > > > > T

Re: Strace

Hi Simon, The strace is only supposed to run when the normal test pre_cmd fails. If it's running that often it means your tests are all failing during pre_cmd with a framework failure

Re: Why do we prevent static archives from being loaded when DYNAMIC_GHC_PROGRAMS=YES?

You could work around the dlopen issue as long as the static library is compiled with -fPIC by using --whole-archive (assuming you permit dangling references which will need to be resolved later) and making a shared library out of the static code. But you'd have to create one shared library per

Re: Trac email

> > Simon > > > > *From:* Phyx > *Sent:* 31 May 2018 22:43 > *To:* Artem Pelenitsyn > *Cc:* Simon Peyton Jones ; ghc-devs@haskell.org > *Subject:* Re: Trac email > > > > The mail servers were backed up with spam apparently. No emails were > deliver

Re: -fghci-leak-check apparently causes many tests to fail

I don't know what -fghci-leak-check does at all, but if they are to be expected we shouldn't accept the changes. Instead change the default options in the testsuite to pass -fno-ghci-leak-check (I assume that exists) On Thu, May 31, 2018, 06:49 Ryan Scott wrote: > I recently ran the testsuite

Re: Trac email

The mail servers were backed up with spam apparently. No emails were delivered or received to any of the mailing lists https://www.reddit.com/r/haskell/comments/8mza0y/whats_up_with_mailhaskellorg_dark_since_sunday/ Cheers, Tamar On Thu, May 31, 2018, 15:26 Artem Pelenitsyn wrote: > Hello, > >

Re: End of Windows Vista support in GHC-8.6?

I have updated https://ghc.haskell.org/trac/ghc/wiki/Platforms/Windows > accordingly. > > Cheers, > Simon > > 2018-03-05 18:29 GMT+01:00 Phyx <loneti...@gmail.com>: > >> >> >> On Mon, Mar 5, 2018, 17:23 Ben Gamari <b...@well-typed.com> wrote: >> &

Re: Windows: cannot create here-doc

Hi Simon, This one is very strange, from the error and the fact that it continues it looks like whatever TEMP and TMP are pointing to are not always available or some locking issue is going on. I would try running ProcMon https://docs.microsoft.com/en-us/sysinternals/downloads/procmon and

Re: Perl locale

Hi Simon, That's weird, "ENG" isn't a valid locale as far as I know. The locale should be getting set by your .profile by the line # Set user-defined locale export LANG=$(locale -uU) In my case that returns $ locale -uU en_GB.UTF-8 I would check to see if that line is in your .profile (it

Re: More windows

Hi Simon, Hmm I'm not sure about replacing sh with bash. I think bash has some Non-POSIX extensions that may affect the behavior of valid posix scripts. Is bash --login slow as well? How about once sh or bash starts, are commands still slow then? I assume your computer is domain joined and you

Re: Windows

On Mon, Mar 26, 2018 at 11:08 AM, Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > One other thing. The instructions at > > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > > say to set PATH thus > > > > export PATH=/mingw64/bin:\$PATH > > > > But > >- in

Re: End of Windows Vista support in GHC-8.6?

On Mon, Mar 5, 2018, 17:23 Ben Gamari wrote: > Simon Jakobi via ghc-devs writes: > > > Hi! > > > > Given that Vista’s EOL was in April 2017 > > < > https://support.microsoft.com/en-us/help/22882/windows-vista-end-of-support > > > > i assume that

Re: Can't push to staging area?

This is a local git configuration issue. Your pack scripts (git-upload-pack etc) are on a path that requires sudo or your sudoers configuration is wrong. See https://stackoverflow.com/questions/24059597/phabricator-git-ssh-clone-fails-with-password-required-error On Thu, Jan 4, 2018, 01:06

Re: ghc-prim 0.5.1.1 not on Hackage

Hmm I think this one belongs on the ghc trac. The version doesn't seem to exist in master either https://github.com/ghc/ghc/commits/master/libraries/ghc-prim/ghc-prim.cabal and only exists in the 8.2 branch. The commit and bug report it references #14171 doesn't seem to have any code changes to

Re: [GHC] #14537: Do not link to msvcrt.dll

Add a -v3 to ghc to see what's happening. On Wed, Dec 13, 2017, 07:23 GHC wrote: > #14537: Do not link to msvcrt.dll > -+- > Reporter: johndoe |Owner: (none) >

Re: Bringing back #ghc IRC logging

Herbert said he submitted the request months ago. As botbot.me site says they don't honor every request, so I guess we weren't selected. I'd still prefer botbot.me as it seems more stable than ircbrowse.net which also doesn't seem to work on mobile (Android, get a server error) On Wed, Oct 25,

  1   2   >