Re: Array heap objects

No, I don't think that gets me all the way to what I want, although it might be a reasonable approach to one *part* of it. The main idea I'm after is efficient representations of things like HashMap, where nodes in a tree have variable numbers of children. First, let's look at how HashMap is

Re: msys woes

Phyx writes: >> I'm not sure what you mean by "the tag won't move". Could you clarify? > > I mean that the tag called 8.8.4-release will still point to the a broken > hash no? Since it represents the hash of the commit the release was made > from. > Ahh, yes. 8.8.4-release will not change. In

Re: msys woes

On Thu, Oct 8, 2020 at 4:28 PM Ben 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 to Haskell.org

Re: msys woes

> I'm not sure what you mean by "the tag won't move". Could you clarify? I mean that the tag called 8.8.4-release will still point to the a broken hash no? Since it represents the hash of the commit the release was made from. Sent from my Mobile On Thu, Oct 8, 2020, 21:28 Ben Gamari wrote: >

Re: msys woes

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 to Haskell.org succeeds but the msys2 one fails since that > package is gone. > > The

Re: Array heap objects

David Feuer writes: > Ah, too bad about reuse. What do you mean about walking over both pointers > and non-pointers? The extra word (for pointers-first layout) or few words > (for bitmapped) will be more than made up for in most cases by not needing > extra heap objects between a node and its

Re: msys woes

On Thu, Oct 8, 2020 at 1:18 PM Phyx wrote: > From the looks of it the repo.msys2.org system doesn't have enough space > to restore all these old packages. > > So we'll have to handle it on our end. The easiest way to get your builds > working again is by applying a patch with the fix to the

Re: msys woes

>From the looks of it the repo.msys2.org system doesn't have enough space to restore all these old packages. So we'll have to handle it on our end. The easiest way to get your builds working again is by applying a patch with the fix to the source tree. Sent from my Mobile On Thu, Oct 8, 2020,

Re: msys woes

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 since that package is gone. The whole thing after the || needs to be

Re: msys woes

On Thu, Oct 8, 2020 at 12:19 PM Shayne Fletcher < shayne.fletcher...@gmail.com> wrote: > > > 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

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). > You don't need to run the entire pipeline to test this. Just run > >

Re: msys woes

Hi Shayne, 8.8.1 had a different mechanism but the primary is still haskell.org. You don't need to run the entire pipeline to test this. Just run ./mk/get-win32-tarballs.sh download x86_64 This should echo to stdout more information. Kind regards, Tamar Sent from my Mobile On Thu, Oct 8,

Re: msys woes

On Thu, Oct 8, 2020 at 11:18 AM Sylvain Henry wrote: > Could you share the contents of "missing-win32-tarballs" log file? > Where exactly does that file reside? In any case I think the answer is likely no Sylvain as it will be on an inaccessible Azure host. -- Shayne Fletcher

Re: Array heap objects

Ah, too bad about reuse. What do you mean about walking over both pointers and non-pointers? The extra word (for pointers-first layout) or few words (for bitmapped) will be more than made up for in most cases by not needing extra heap objects between a node and its children. Simon has explained

Re: msys woes

Could you share the contents of "missing-win32-tarballs" log file? Thanks, Sylvain On 08/10/2020 16:51, Shayne Fletcher wrote: Hi Phyx, On Thu, Oct 8, 2020 at 9:10 AM Phyx > wrote: > `./configure --enable-tarballs-autodownload` GHC build step on Windows

Re: msys woes

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-tarballs-autodownload` GHC build step on Windows >> has been failing because repo.msys2.org >> >> Afaik GHC doesn't rely

Re: msys woes

Hi Phyx, On Thu, Oct 8, 2020 at 9:10 AM Phyx wrote: > > `./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

"boilerplate" tool released

Hello all, I have just released "boilerplate" to Hackage http://hackage.haskell.org/package/boilerplate boilerplate is a command line tool that generates explicit boilerplate and inserts it into your source code, enclosed in comments that text editors can easily hide from view. Like the way

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

msys woes

For the last 5 days, the `./configure --enable-tarballs-autodownload` GHC build step on Windows has been failing because repo.msys2.org has been unavailable (https://github.com/msys2/MSYS2-packages/issues/2171). Apparently that's fixed today and the server can now be reached but still the

Re: Array heap objects

On October 7, 2020 2:02:53 PM EDT, David Feuer wrote: >Yes, the bitmap structures used to encode the structure of stack >frames. These *look* like they might be reusable for mix-and-match >arrays in Haskell-land. If so, that could be a pretty cheap new >feature. Ahh, yes. In principle we could