Re: GHC on Windows (extended/broad discussion)

Hi All, Sorry for the late reply, I need to adjust my mail filtering rules to let these mails go to my inbox as well. I have also taken a few passes through the windows trac and there are a lot of issues with someone assigned to them but with no activity so a while on them. I was also wondering

Re: Linker questions

Hi Edward, Thanks for the information, it really helped make it more clear to me what's going on. I would ideally like to get these validate errors on Windows down to 0 (without marking them as expected fail). So I will probably make a ticket for this. Cheers, Tamar On Thu, Aug 20, 2015 at

CoreToStg Asserts

Hi *, I'm hoping someone could help me understand what the asserts in CoreToStg on line 240 and 216 are trying to tell me. I hit both of them while trying to compile libraries as dyn. WARNING: file compiler\stgSyn\CoreToStg.hs, line 250 $trModule2 False True ghc-stage1.exe: panic! (the

Re: msys2 64 bit: help help!

Hi Simon, Andrey > > 3. After this step, starting a shell failed altogether with > "c:/msys64/mingw64_shell.bat is > > not recognised as an internal or external command". And sure enough, > there is no such file. > > Presumably it existed in step 1. So perhaps step 2 deleted it? > > [...] > >

Re: Build failing

Hi Simon, I have made a diff to fix it but it hasn't been reviewed yet https://phabricator.haskell.org/D1878 Regards, Tamar Sent from my Mobile On Feb 2, 2016 12:07 PM, "Simon Peyton Jones" wrote: > A clean Windows build fails. See below. help! > > Simon > > > >

Re: Cross-compiling Template Haskell via -fexternal-interpreter and IPC

> However, compiling TH by using wine and ghc-iserver.exe fails because the file descriptor ids that GHC passes as arguments to "wine ghc-iserv.exe" don't make sense in the emulated windows world. Just as a note, On Windows we don't pass FDs (As in the posix file descriptor) to the child process.

RE: Windows build

Hi Simon, Thomie changed it so the in place gcc can be called from the testsuite. The tests should pass now. Kind regards, Tamar Sent from my Mobile On Jul 8, 2016 23:02, wrote: > Hi Simon, > > > > For these tests it shouldn’t matter much so I guess I can change them. > >

Re: Linker.c broken

Let’s re-enable it. Or: how can I selectively re-enable it for in my > validate.mk? > > > > *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Phyx > *Sent:* 04 July 2016 13:05 > *To:* Erik de Castro Lopo <mle...@mega-nerd.com>; ghc-devs < > ghc-d

Re: Linker.c broken

I can build and validate in about an hour myself using 9 jobs on a core i7. If I revert the change in the testsuite preventing parallel runs for Windows. Tamar On Mon, Jul 4, 2016, 12:26 Ben Gamari wrote: > "Boespflug, Mathieu" writes: > > > On 4 July 2016

Re: Linker.c broken

a ticket with more information on it and what I found back then, but haven't been able to progress. It might be that they've just fixed it in the mean time. On Mon, Jul 4, 2016, 12:58 Erik de Castro Lopo <mle...@mega-nerd.com> wrote: > Phyx wrote: > > > I can build and validat

Re: Cannot build GHC using the Newcomers guide

Can I ask a silly question. I can't seem to find where stack is recommended for ghc development on the newcomers page, but why is it? I don't want to start another flame war but I can't imagine any scenario where this is useful. As far as I understand the whole benefit of stack is the curated

Re: Cannot build GHC using the Newcomers guide

course, this only works if you are using nix! > > Matt > > On Thu, Jan 26, 2017 at 5:18 PM, Phyx <loneti...@gmail.com> wrote: > > Can I ask a silly question. I can't seem to find where stack is > recommended > > for ghc development on the newcomers page, but why is it

MSYS2 update (those who build on Windows please read)

Hi Windows devs, February comes with a major change in behavior for MSYS2/Cygwin. Tools such as awk/sed etc now use binary mode unless on a text mount: https://cygwin.com/ml/cygwin-announce/2017-02/msg00036.html This is problematic because GHC etc only use the underlying OS to determine how to

Re: MSYS2 update (those who build on Windows please read)

Hi all, MSYS2 maintainers have agreed that the change by Cygwin constitudes a regression for the MSYS2 project and patched out the changes. It's now safe to upgrade MSYS2 again. Tamar On Mon, Feb 20, 2017 at 3:58 PM, Phyx <loneti...@gmail.com> wrote: > Hi Windows devs, > >

Re: Windows build broken

The package has been fixed already but the submodule hasn't been updated. For a quick fix just cd into libraries/time and checkout master. I was hesitant to push the new submodule since we hadn't branched yet for 8.2 On Wed, 22 Feb 2017, 14:09 Simon Peyton Jones via ghc-devs, <

Re: Windows build broken

; > > > Simon > > > > *From:* Phyx [mailto:loneti...@gmail.com] > *Sent:* 22 February 2017 14:14 > *To:* Simon Peyton Jones <simo...@microsoft.com>; ghc-devs@haskell.org > *Cc:* Ashley Yakeley <ash...@semantic.org> > *Subject:* Re: Windows build broken

Re: Notes from Ben's "contribute to ghc" discussion

>> >> ·Auto-push: Ability to push to Phab and have it committed >> automatically if it validates. > > \o/ How would this work? Could there be a cooldown period? e.g. commits sit a day before being auto-committed? Validate really only validates Linux x86_64. The situation is already quite

Re: building ghc-8.0 branch on Win10

Hi Josh, Yes you are hitting a bug in configure that was exposed due to changes in msys. Cherry-pick this commit to your branch https://ghc.haskell.org/trac/ghc/ticket/12487 Tamar On Mon, Sep 19, 2016, 12:24 Josh Berman wrote: > Hi, > > I was able to build the "master"

Re: Test T12504 on Windows

The new output is correct. hsc2hs was patched to fix the error messages it gives. We missed a test it seems. I'll update the test output when I get home. Thanks Simon, Tamar On Tue, Sep 20, 2016, 23:06 Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > Test hsc2hs/T12504 is

Re: Action Required: Status of Harbormaster for Differentials

Hi Ben, Out of curiosity which platforms will be getting harbormaster support? Is this only Linux x86_64? Any plans to expand this in the future to all Tier 1 platforms? Cheers, Tamar On Fri, Aug 26, 2016, 22:39 Ben Gamari wrote: > Joachim Breitner

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

I dislike this approach, having to already deal with a project that does patches via mailing lists it is very hard to follow conversations. As soon as multiple people get involved things fall apart. I have multiple mailing rules and other things just so I can keep track of comments. And then

Re: Windows build

Hi Simon, What does which python 2 and which python 3 return? Along with uname -a? Tamar On Tue, Oct 18, 2016, 10:58 Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > On Windows I now get a lot of framework failures, below. > > I have not tried them all, but some work fine when

Re: Windows build

ypecheck/should_fail$ python2 --version > > Python 2.7.11 > > .../typecheck/should_fail$ python3 --version > > Python 3.4.3 > > .../typecheck/should_fail$ > > > > *From:* Phyx [mailto:loneti...@gmail.com] > *Sent:* 18 October 2016 11:07 > *To:* Simon Peyton

Re: Default options for -threaded

Oops, sorry, only just now seen this. It seems my overly aggressive filters couldn't decide where to put the email :) I do agree to some extend with this. I'd prefer if I made a mistake for my system not to hang. The one downside to this default though is that you can't just hand a program over

Re: Default options for -threaded

Oh, this is surprising, I must admit I haven't tried forkIO, but with forkOS is doesn't move the threads across capabilities. Do you know if this is by design or a bug? On Sat, Oct 8, 2016 at 6:13 PM, Eric Seidel wrote: > I would prefer keeping -N1 as a default, especially now

Re: Telemetry (WAS: Attempt at a real world benchmark)

On Fri, Dec 9, 2016 at 3:53 PM, Ben Gamari wrote: > Simon Peyton Jones via ghc-devs writes: > > > Just to say: > > > > > > · Telemetry is a good topic > > > > · It is clearly a delicate one as we’ve already seen from two widely > > differing

Re: testsuite broken

Bah, String handling in python is a complete mess. In any case, we dropped support for 2 so we can remove the u prefixes. It seems that the Unicode syntax in python 3 was dropped in python 3.0 and reintroduced on 3.3. We were all using 3.5 to test. To get you going again quickly, You can

Re: [GHC] #13035: GHC enters a loop when partial type signatures and advanced type level code mix

Ah, great thanks! On Fri, 6 Jan 2017, 20:32 GHC, wrote: > #13035: GHC enters a loop when partial type signatures and advanced type > level code > mix > -+- > Reporter: xcmw |

Re: Trac to Phabricator (Maniphest) migration prototype

In response to no# 2, I was looking at this my self since I think separate fields would definitely be useful. It seems you can customize the form design on phabricrator. I think it would definitely be worth it to make a new form layout resembling the layout of track. I don't know how it stores it

Re: Trac to Phabricator (Maniphest) migration prototype

Hi Matthew, Great work! I must admit I'm one of the few that generally likes Trac but I'm liking this quite a lot. Just two questions, Is it possible for those like me who have a different username on trac and phabricator to get mapped correctly? And how does the ticket creation process look?

Re: Windows 10 Creators Update will break GHC (Was FW: GHC on Windows 10 15019+)

, 09:18 Simon Peyton Jones via ghc-devs, < ghc-devs@haskell.org> wrote: > Yikes that sounds bad! > > > > I just wanted to raise awareness and offer myself to do guided grunt work > (if there is any) to push out a hotfix/inplace patch release for GHC 8.0.2. > > > >

Re: [ANNOUNCE] GHC 8.2.1 release candidate 1

Hi Ben, The windows build is unusable. The settings file has $TopDir expanded and hard-coded to the build path on drydock. Tamar On Mon, 10 Apr 2017, 08:14 Boespflug, Mathieu, wrote: > Hi Ben, > > this is great news! I'm particularly keen on learning more about two > points you

Re: Windows build failing in a new way

Hi Simon, As of this morning the Windows build was working fine https://github.com/Mistuke/GhcWindowsBuild/commit/aa6906b2535224721d8b049cee3edcd938c3e951 those are my nightly logs for last night at commit a02b80f That error seems to be coming from gcc and not ghc. We did update the crt and

Re: Windows build failing in a new way

2017, 16:38 Phyx, <loneti...@gmail.com> wrote: > Hi Simon, > > As of this morning the Windows build was working fine > https://github.com/Mistuke/GhcWindowsBuild/commit/aa6906b2535224721d8b049cee3edcd938c3e951 > those are my nightly logs for last night at commit a02b80f

Re: Windows build failing in a new way

Checking again, I think something else is wrong I'll have to check later. Sorry, but that commit above is still good. If you are really stuck use that one. Tamar On Thu, 9 Mar 2017, 17:11 Phyx, <loneti...@gmail.com> wrote: > That said, running the build on HEAD it seems that the

Re: Windows build failing in a new way

My CI server is also reproducing it while I also haven't been able to locally. Weird indeed. On Thu, 9 Mar 2017, 17:36 Ben Gamari, wrote: > Simon Peyton Jones via ghc-devs writes: > > > My windows build is more broken than usual. I can't even build

Re: FW: GHC on Windows 10 15019+

On Fri, 10 Mar 2017, 13:15 Simon Peyton Jones via ghc-devs, < ghc-devs@haskell.org> wrote: > Phyx and friends: does this ring a bell? Do we have a ticket? > > -Original Message- > From: Glasgow-haskell-users [mailto: > glasgow-haskell-users-boun...@haskell.org] On

Re: Windows build broken again

https://ghc.haskell.org/trac/ghc/ticket/13375 On Tue, 7 Mar 2017, 08:05 David Macek, wrote: > On 4. 3. 2017 22:01, Simon Peyton Jones via ghc-devs wrote: > > Exception: stderr from command: > ['"/c/code/HEAD/inplace/bin/ghc-pkg.exe"', 'dump'] > > Pinpointing the

Re: Windows build broken

Hi Simon, You seem to be in an msys shell instead of a mingw-64 shell (they have different startup shortcuts). We don't support the msys shell as we only want to compile for native windows. You should use the shortcut marked mingw-64. Alternatively to get you going in aclocal.m4 remove line

Re: More windows

This looks like a file lock issue. Just to double check, but do you have the build folder excluded from the antivirus scanner? On Wed, Oct 4, 2017, 13:57 Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > Now in my Windows build, staring with “sh validate –fast –no-clean” I get > >

Re: More windows

ur is new. > > > > Simon > > > > *From:* Phyx [mailto:loneti...@gmail.com] > *Sent:* 04 October 2017 14:17 > *To:* Simon Peyton Jones <simo...@microsoft.com>; ghc-devs@haskell.org > *Subject:* Re: More windows > > > > This looks like a file lock is

Re: dll-split

That's certainly a possibility, though note that this is only an issue for compiling stage2, not end user programs. Since it's only for compiling ghc we don't have to include it in the bindist so license would be less of an issue I think. I'll modify the scripts to pull it automatically when I

Re: Feedback request regarding HSOC project (bringing sanity to the GHC performance test-suite)

Hi Jared, First off, thanks for all the hard work on this. I checked out your branch and made a run, I noticed at the end it had Framework failures: . ./perf/compiler/all.T [] (unexpected indent (, line 298)) so I assume none of the perf tests were run? Though I do see a .git/refs/notes/perf,

Re: Feedback request regarding HSOC project (bringing sanity to the GHC performance test-suite)

ince the current implementation doesn't allow for the data to live together in the same repo. > > Hopefully this answers some questions; I'll make sure this sort of > information is available somewhere so that later users can find these > answers again. Thanks for your though

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: 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: 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,

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: 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

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: 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: -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: 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: 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: [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: 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: 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: 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: 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: 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: 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: 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: [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: 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

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: 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

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: 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: 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

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

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

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

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

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: 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: 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

-- 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

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

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

> 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

> 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

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: [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: 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: [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: 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: [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: 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: [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

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: [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: 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: 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

  1   2   >