Re: A modest proposal (re the Platform)

[Bob Ippolito]

+1

I'm just a user, but I'm very excited about the possibility of getting a
GHC 7.8 platform release sooner than later (especially considering Mio and
the other great additions). Another release with the same GHC wouldn't do
me much good.


On Sun, Jan 19, 2014 at 3:14 PM, Mark Lentczner wrote:

> Looks like GHC 7.8 is pretty near release.
>
> And while I know that we really like to have a GHC out for a while, and
> perhaps see the .1 release, before we incorporate it into the Platform,
> this GHC, while including many new and anticipated things, seems pretty
> well hammered on.
>
> Combine that with the now two-month late (all my fault) HP release for
> 2013.4.0.0 isn't slated to really have all that much new in it, in part
> because it is the same GHC as the last HP release.
>
> Now - it would really look foolish, and taken poorly (methinks) if we
> release a HP this month - only to have GHC 7.8 release early Feb. Folks
> would really be head scratching, and wondering about the platform.
>
> SO - I'm proposing ditching the now late 2013.4.0.0 (I admit, I'm finding
> it hard to get excited by it!) and instead move right to putting out
> 2014.2.0.0 - aimed for mid-March to mid-April.
>
> This release would have several big changes:
>
>- GHC 7.8
>- New shake based build for the Platform
>- Support for validation via package tests
>- Support for a "server variant" (no OpenGL or other GUI stuff if we
>had any)
>- Automated version info w/historical version matrix page
>- Several significant packages: I'd like to see Aeson at the very
>least, updated OpenGL stuff
>
> I'd also propose changes for the Mac build (though this is obviously
> independent):
>
>- Built from GHC source, not dist. release. (guarantees consistent
>release)
>- Only 64bit (I know, controversial...)
>
> Thoughts?
>
>
> ___
> Libraries mailing list
> librar...@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Abstract FilePath Proposal

[Bob Ippolito]

Normalization is a very hairy issue, which is not just platform specific
but also filesystem specific. Mac OS X is probably the worst of all words
in that respect, where HFS+ will do NFD normalization and may or may not
have case sensitivity depending on how that partition was formatted.
Network file shares and disk images may or may not have case sensitivity
and can use either NFD or NFC normalization based on mount options.

Contrary to statements earlier in the thread, NFD normalization happens on
HFS+ filesystems (the default) regardless of whether you're using POSIX
APIs or not. It's easy to prove this to yourself by creating a file with
U+00c9 (LATIN SMALL LETTER E WITH ACUTE) in the name (from any of the APIs)
and you'll see it come back out (e.g. from readdir) as two code points: 'e'
and then U+0301 (COMBINING ACUTE ACCENT). It'll also do some weird
transformations to file names that contain byte sequences that are not
valid UTF-8.



On Sun, Jun 28, 2015 at 12:05 PM, Edward Kmett  wrote:

> Worse there are situations where you absolutely _have_ to be able to use
> \\?\ encoding of a path on Windows to read, modify or delete files with
> "impossible names" that were created by other means.
>
> e.g. Filenames like AUX, that had traditional roles under DOS cause weird
> interactions, or that were created with "impossibly long names" -- which
> can happen in the wild when you move directories around, etc.
>
> I'm weakly in favor of the proposal precisely because it is the first
> version of this concept that I've seen that DOESN'T try to get too clever
> with regards to adding all sorts of normalization and this proposal seems
> to be the simplest move that would enable us to do something correctly in
> the future, regardless of what that correct thing winds up being.
>
> -Edward
>
> On Sun, Jun 28, 2015 at 8:09 AM, David Turner <
> dct25-56...@mythic-beasts.com> wrote:
>
>> Hi,
>>
>> I think it'd be more robust to handle normalisation when converting from
>> String/Text to FilePath (and combining things with () and so on) rather
>> than in the underlying representation.
>>
>> It's absolutely crucial that you can ask the OS for a filename (which it
>> gives you as a sequence of bytes) and then pass that exact same sequence of
>> bytes back to the OS without any normalisation or other useful alterations
>> having taken place.
>>
>> You can do some deeply weird stuff in Windows by starting an absolute
>> path with \\?\, including apparently using '.' and '..' as the name of a
>> filesystem component:
>>
>> Because it turns off automatic expansion of the path string, the "\\?\"
>> prefix also allows the use of ".." and "." in the path names, which can be
>> useful if you are attempting to perform operations on a file with these
>> otherwise reserved relative path specifiers as part of the fully qualified
>> path.
>>
>>
>> (from
>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
>> )
>>
>> I don't fancy shaking all the corner cases out of this. An explicit
>> 'normalise' function seems ok, but baking normalisation into the type
>> itself seems bad.
>>
>> Cheers,
>>
>> David
>>
>>
>> On 28 June 2015 at 11:03, Boespflug, Mathieu  wrote:
>>
>>> Hi Neil,
>>>
>>> why does the proposal *not* include normalization?
>>>
>>> There are four advantages that I see to making FilePath a datatype:
>>>
>>> 1. it makes it possible to implement the correct semantics for some
>>> systems (including POSIX),
>>> 2. it allows for information hiding, which in turn helps modularity,
>>> 3. the type is distinct from any other type, hence static checks are
>>> stronger,
>>> 4. it becomes possible to quotient values over some arbitrary set of
>>> identities that makes sense. i.e. in the case of FilePath, arguably
>>> "foo/bar//baz" *is* "foo/bar/baz" *is* "foo//bar/baz" for all intents
>>> and purposes, so it is not useful to distinguish these three ways of
>>> writing down the same path (and in fact in practice distinguishing
>>> them leads to subtle bugs). That is, the Eq instance compares
>>> FilePath's modulo a few laws.
>>>
>>> Do you propose to forego (4)? If so why so?
>>>
>>> If we're going through a deprecation process, could we do so once, by
>>> getting the notion of path equality we want right the first time?
>>> Contrary to type indexing FilePath, it seems to me that the design
>>> space for path identities is much smaller. Essentially, exactly the
>>> ones here:
>>> https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-Posix.html#v:normalise
>>> .
>>>
>>> Best,
>>>
>>> Mathieu
>>>
>>>
>>> On 27 June 2015 at 12:12, Neil Mitchell  wrote:
>>> > Hi Niklas,
>>> >
>>> > The function writeFile takes a FilePath. We could fork base or tell
>>> everyone
>>> > to use writeFile2, but in practice everyone will keep using writeFile,
>>> and
>>> > this String for FilePath. This approach is the only thing we could
>>> figure
>>> > that made sense.
>>> >
>>> > Henning: we do not prop

Re: OS X bindist

[Bob Ippolito]

https://halcyon.global.ssl.fastly.net/original/ghc-7.10.1-x86_64-apple-darwin.tar.bz2
is the build that http://ghcformacosx.github.io/ used.

On Wed, Apr 22, 2015 at 5:10 PM, Andrew Farmer  wrote:

> Forgive me if this has been answered somewhere, but is there an
> officially sanctioned bindist of 7.10.1 for OS X yet? The page I
> usually visit [1] doesn't list one yet.
>
> Thanks!
> Andrew
>
> [1] https://www.haskell.org/ghc/download_ghc_7_10_1
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 7.10.1 bindist for OS X + Haskell Platform 2015.2.0.0 Alpha 2

[Bob Ippolito]

I'm having the same issue with that build.

On Sat, Mar 28, 2015 at 3:42 PM, Alec  wrote:

> Thanks Mark!  But:
>
> % shasum -a 256 ghc-7.10.1-x86_64-apple-darwin.tar.bz2
> f7b112577966391988d16cb44061602f26bbe9a341aa6f4f1301d257895f1c65
>  ghc-7.10.1-x86_64-apple-darwin.tar.bz2
>
> Also, `tar xjf` didn't like it very much.  Did your upload get cut off?
> The tarball is only 77 Megs.
>
> -A
>
> On Sat, Mar 28, 2015 at 6:23 PM Mark Lentczner 
> wrote:
>
>> I have built the 7.10.1 bindist for OS X.
>> It is currently sitting on my server at:
>> ghc-7.10.1-x86_64-apple-darwin.tar.bz2
>> 
>> \O/
>>
>> I have built an Alpha 2 of Haskell Platform 2015.2.0.0 for OS X
>> .
>> It is based on the above bindist.
>> I should have an ubuntu version of the Platform built by tomorrow.
>> \O/
>>
>> - Mark
>>
>> *sha256 sums:*
>> c6eb8d573538eba27dfb2d9acf52a1beaaa512208261528b91e8d1775d133eee
>> ghc-7.10.1-x86_64-apple-darwin.tar.bz2
>> 0cb351281fcf5ef34c54b455a3643d0ff078299a53b2c39d911dbda4aac2d233  Haskell
>> Platform 2015.2.0.0 alpha 2 64bit.pkg
>>
>>
>> ___
>> Libraries mailing list
>> librar...@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
> ___
> Libraries mailing list
> librar...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: MAC builds of 7.8.4 and 7.10.1 RC2

[Bob Ippolito]

Thanks Mark! This build seems to work well. I'm in the process of
publishing a new http://ghcformacosx.github.io/ with it.

Austin - do you still plan to get these binaries online? I think haskell.org
has more bandwidth than ozonehouse.com :)

On Thu, Feb 12, 2015 at 7:02 AM, Austin Seipp  wrote:

> I'll get them online with signed hashes today.
>
> On Thu, Feb 12, 2015 at 8:20 AM, Ozgur Akgun  wrote:
> > This is great.
> >
> > What would one have to do to get this added to
> > https://www.haskell.org/ghc/download_ghc_7_8_4 ?
> >
> > Ozgur
> >
> > On 11 February 2015 at 06:16, Mark Lentczner 
> > wrote:
> >>
> >> My build procedure is very minimal:
> >>
> >> export MACOSX_DEPLOYMENT_TARGET=10.6
> >> ./configure 2>&1 | tee ../conf.log
> >> cat > mk/build.mk < >> V=1
> >> SplitObjs=YES
> >> SupportsSplitObjs=YES
> >> HADDOCK_DOCS=YES
> >> LATEX_DOCS=NO
> >> HSCOLOUR_SRCS=YES
> >> BUILD_DOCBOOK_HTML=YES
> >> BUILD_DOCBOOK_PDF=NO
> >> BUILD_DOCBOOK_PS=NO
> >> BeConservative=YES
> >> END
> >> time make -j4 2>&1 | tee  ../make.log
> >> time make binary-dist 2>&1 | tee  ../bd.log
> >>
> >> That is all!
> >
> >
> >
> > ___
> > 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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: gcc vs. clang builds of 7.8.3 on OS X

[Bob Ippolito]

On Sun, Jul 13, 2014 at 12:13 AM, Mark Lentczner 
wrote:

> Found the culprit!!!
>
> XCodeVersion=`xcodebuild -version | grep Xcode | sed "s/Xcode //"`
>
>
> This line in configure doesn't work on a system that just the Xcode
> command line tools installed! It also won't work on an OS X system that has
> some other tool chain (say, via brew) installed. On such systems, itsets
> XCodeVersion to "", which in tur
>
> The follow on code sets XCodeVersion1 and XCodeVersion2 to "0", and then
> this code runs, causing the problem:
>
> SplitObjsBroken=NO
> if test "$TargetOS_CPP" = "darwin"
> then
> # Split objects is broken (#4013) with XCode < 3.2
> if test "$XCodeVersion1" -lt 3
> then
> SplitObjsBroken=YES
> else
> if test "$XCodeVersion1" -eq 3
> then
> if test "$XCodeVersion2" -lt 2
> then
> SplitObjsBroken=YES
> fi
> fi
> fi
> fi
>
>
> ​Alas, it doesn't look like SplitObjsBroken has the logic to allow it to
> be overriden on the ./configure invocation (anyone know for sure? my
> autoconf is very rusty)
>
> Too late here for me to think of a fix
>

Would it be possible to simply stop supporting Xcode builds that old? #4013
is three years old and Xcode < 3.2 only applies to Mac OS X 10.5 and
earlier.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Wither Haskell Platform 2013.4.0.0

[Bob Ippolito]

On Monday, October 14, 2013, Dag Odenhall wrote:

> On Mon, Oct 14, 2013 at 12:20 AM, Brandon Allbery 
> >
> wrote:
>
> Nope. Arch is a rolling release distribution whose policy is directly
>> opposed to the "stable release" philosophy of the Platform. They will
>> package latest versions of everything, not a "stable release". You *cannot*
>> satisfy their requirements with the Platform; ignore them.
>
>  I would say it depends on what you mean by “latest”, since one answer
> could be “latest haskell-platform”. Does Arch Linux ship the latest Python
> packages, even if an older version is included in the stdlib of the latest
> Python release?
>
There isn't a separate "Python" and "Python Platform". Packages that ship
with Python are maintained in Python's repository. Those that are
also maintained separately usually have another package/module name
altogether so both can be installed without interfering with one another.

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