Re: Fwd: Unable to compile ghc-8.2.2 with ghc-8.4.3

[Sven Panne]

Am Fr., 31. Aug. 2018 um 21:17 Uhr schrieb Brandon Allbery <
allber...@gmail.com>:

> I don't think ghc ever used gcc's version of this; it used the Evil
> Mangler to do it.
>

Well, I actually *do* think it used GCC's global variables: I fixed GHC in
the late 90's to make it work on HP-UX, and I'm quite sure that this
involved fiddling around with header files, finding suitable registers,
describing stack layout, fixing alignment problems etc.  Alas, I don't have
any unregistered build for GHC 0.29 (?) on HP-UX 10 at hand anymore. :-D
Perhaps one of the Simons remembers the details...

>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Fwd: Unable to compile ghc-8.2.2 with ghc-8.4.3

[Sven Panne]

Am Fr., 31. Aug. 2018 um 18:52 Uhr schrieb Ben Franksen <
ben.frank...@online.de>:

> Am 31.08.2018 um 11:57 schrieb Sven Panne:
> > Am Fr., 31. Aug. 2018 um 11:11 Uhr schrieb Sam Halliday <
> > sam.halli...@gmail.com>:
> >
> >> [...] It would make a lot of sense for the
> >> "unregistered" sources to be made available as an optional download
>
> Note that the term is "unregisterized" which refers to putting certain
> global variables into registers; you can't do that in C code.
>

That's only correct for standard C, for GCC there is
https://gcc.gnu.org/onlinedocs/gcc/Global-Register-Variables.html. IIRC
this is exactly how old unregistered builds worked. I am not even sure if
the unregistered builds ever worked *without* GCC, perhaps there was some
CPP magic, but I can't remember
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Fwd: Unable to compile ghc-8.2.2 with ghc-8.4.3

[Sven Panne]

Am Fr., 31. Aug. 2018 um 11:11 Uhr schrieb Sam Halliday <
sam.halli...@gmail.com>:

> [...] It would make a lot of sense for the
> "unregistered" sources to be made available as an optional download
> alongside the source code, if haskell.org were open to that
> possibility.


IIRC, the generated C code is *not* platform-independent, at least that is
what I remember from ancient times. Perhaps I'm wrong and/or this has
changed, but if this is really the case, you would need an additional
download per target platform.

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 8.4.1 released

[Sven Panne]

2018-03-08 17:57 GMT+01:00 Ben Gamari :

> The GHC developers are very happy to announce the 8.4.1 release of
> Glasgow Haskell Compiler. [...]


Just a few tiny remarks regarding "base":

   *
https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.html#included-libraries
says that the shipped "base" has version 2.1, I guess that should be
4.11.0.0.

   * https://wiki.haskell.org/Base_package needs an update.

   * Hackage has no 4.11.0.0 yet, that would be very helpful for the docs.
Yes, there is
https://downloads.haskell.org/~ghc/8.4.1/docs/html/libraries/index.html,
but Hackage is somehow the more canonical place to look up the package docs.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: PSA: `cabal update` command needs manual unsticking

[Sven Panne]

2018-01-02 2:24 GMT+01:00 Gershom B :

> A recent update to hackage, which fixed up the 01-index.tar.gz file,
> revealed a bug in existing versions of cabal-install, when index files
> are cleaned up. This bug means that the `cabal update` command, which
> updates the hackage index file, will fail silently and leave the old
> file in place. It is easy to get things working again, but it requires
> manual intervention. [...]


Quick question: Are stack users affected, too, or only cabal users? I'm
just asking because as a stack user you have
~/.stack/indices/Hackage/01-index.* files lying around, too...
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2

[Sven Panne]

2017-11-06 17:54 GMT+01:00 Ben Gamari :

> Next time something like this arises please do open a ticket.
>

Yep, will do...


> Yes, I have opened a differential adding such a flag. See D4164 [1].
> Please bikeshed to taste.
>

Thanks for the quick fix!


> In general I would really prefer that we *not* consider GHCi's REPL to be
> a stable programmatic interface.


I fully understand that, and that's definitely the way to go. Nevertheless,
parsing tool/compiler output is still one of the most used hacks^H^H^H
techniques for lots of Emacs modes (and probably other IDEs). Not every
project is as open to suggestions and changes as GHC is, so this is often
the only way out.


> That being said, we cannot always preemptively add complexity to the
> project out of fear that a given change might break a hypothetical
> mechanical consumer.


That's of course not what was proposed. :-)


> GHCi is first-and-foremost a REPL for users.
> When evaluating a change, if we feel it is likely that we will break a
> mechanical user then we will likely guard the change with a flag.
> However, if not, we won't.
>

I think the main problem here was communication. I can't speak for the
haskell-mode maintainers, but for my part I didn't notice the problems
because I mainly use LTS Stackage and that is still(!) at 8.0.2 (Why? This
is definitely part of the whole problem.). I tried the 8.2 series only
sparingly and only via the command line, so this is perhaps what others
did, too, so the interaction bug went unnoticed for such a long time.

Cheers,
   Sven
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2

[Sven Panne]

2017-11-05 15:37 GMT+01:00 :

> A better approach might be to develop a "machine-readable" output format
> which then is kept stable, and can be enabled with a flag. Git has a
> similar solution.
>

Without doubt, this is definitely the better approach, but this is hardly
what can be achieved for 8.2.2. Adding some flag to get the old behavior
back when wanted *is* achievable.


> It would be a shame to avoid changes which make the user experience better
> simply because other projects cannot sync their development cycle,
>

Don't get me wrong: I'm all for improving user experience, but making ad
hoc changes without enough thought or even a chance to get the old behavior
back is probably not the right way to proceed. All SW lives in some kind of
ecosystem, so it should behave well in that. And for Emacs users, the user
experience has been made much worse.


> especially if those projects are not universally used or required.
>

This is highly a matter of personal taste: No project is "universally
used", so this is tautological statement. The question is: Is a minor
cosmetic change really worth breaking things in one of the major IDEs?

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 8.2.2 release candidate 2

[Sven Panne]

This is not an issue about 8.2.2 per se, but 8.2 changes in general: Recent
discussions on Haskell Cafe showed serious problems with Emacs'
haskell-mode due to some ad hoc changes like
https://phabricator.haskell.org/D3651. Related GitHub issues:

   https://github.com/haskell/haskell-mode/issues/1553
   https://github.com/haskell/haskell-mode/issues/1496

It should be noted that the output of GHC(i) is actually part of GHC's
interface, so in this light, there have been some breaking changes,
probably unintended, but nevertheless. So my question is: Is there a chance
to revert some of these ad hoc changes and/or add some flags to get the old
behavior back? I guess that Emacs + haskell-mode is one of the most
important IDEs, so it would be a pity to worsen the situation there.

I'm quite aware that it is very late in the release cycle, but it would be
extremely nice if there was something which can be done. In the future it
might make sense to co-operate with the haskell-mode team a bit more,
perhaps adding some tests regarding the required output format etc. to
GHC's test suite.

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: DeriveFoldable treatment of tuples is surprising

[Sven Panne]

2017-03-21 22:29 GMT+01:00 Edward Kmett :

> [... In general I think the current behavior is the least surprising as it
> "walks all the a's it can" and is the only definition compatible with
> further extension with Traversable. [...]
>

OTOH, the current behavior contradicts my intuition that wrapping a type
into data/newtype plus using the deriving machinery is basically a no-op
(modulo bottoms etc.). When I e.g. wrap a type t, I would be very surprised
if the Eq/Ord instances of the wrapped type would behave differently than
the one on t. I know that this is very handwavy argument, but I think the
current behavior is *very* surprising.

Somehow the current behavior seems to be incompatible with the FTP, where
pairs are given a special treatment (if that't the right/intuitive choice
is a completely different topic, though).

Given the fact that "deriving Foldable" is quite old and therefore hard to
change, I would at least suggest a big, fat warning in the documentation,
including various examples where intuition and implementation do not
necessarily meet.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Sven Panne]

2016-07-20 23:16 GMT+02:00 Adam Foltzer :

> [...] I'll quote the Motivations section:
>
>1. Higher than necessary barrier-to-entry.
>
> For the purposes of this proposal, whether we would prefer a competing
> alternative is secondary to the fact that a Github account has become a
> very low common denominator for people wishing to participate in the
> development of open source projects. If we decide to proceed with a
> non-Github platform, we need to make a compelling case that the alternate
> choice does not raise the barrier to entry, or else we need to decide that
> we have different priorities for this effort.
>

+1 for that. Just to give a few numbers, just gathered from Hackage by some
grep/sed/wc "technology": 6799 of the 9946 packages (i.e. 68%) use GitHub.
The numbers are even higher when one considers the top 100 downloaded
packages only: 92% of them use GitHub. So like it or not, the Haskell
community already relies *heavily* on GitHub, and it seems that most people
don't have a problem with that or consider the alternatives inferior.

As Ben already said, using some proprietary SW is no real problem as long
as you can get all your data out of it (in a non-proprietary format). And I
don't understand the point about "proprietary client-side JavaScript" at
all: Should we stop using 99% of the Internet because some server sends us
some JavaScript we have no license for? And what about all those
routers/switches/etc. in between which connect you to the rest of the
world: They definitely run proprietary SW, and nobody cares (for a good
reason).

Don't get me wrong: I'm very much for Open Source, but let's not go over
the top here. Let's use a tool basically everybody knows and focus on the
content, not on the technology.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Sven Panne]

2016-07-10 11:28 GMT+02:00 C Maeder :

> [...] Why does an explicit infix operator make such a big difference for
> you?
>
>   (if c then f else g) $ if d then a else b
>
>   (if c then f else g)  if d then a else b
> [...]
>

Because at first glance, this is visually only a tiny fraction away from

   (if c then f else g)  it d them a elsa b

which would be parsed in a totally different way. (Personally, I think that
if/then/else is useless in Haskell and just a concession for readers from
other programming languages. Having a plain old "if" function would have
done the job in a more consistent way.) Of course syntax highlighting
improves readability here, but code should be easily digestible in black
and white, too. Visual clues matter...
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Sven Panne]

2016-07-08 12:28 GMT+02:00 Joachim Breitner :

> Currenlty,
>
> foobar
>   (do f &&& g)
>   x
>
> calls foobar with two arguments, while
>
> (do f &&& g)
> x
>
> calls (f &&& g) with one argument. The ArgumentDo proposal does not change
> that, only that the parenthesis become redundant.
>

I don't think so:
https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo#BlockasaLHS explicit
states that

   do f &&& g
   x

parses as

   (f &&& g) x

, so

   foobar
  do f &&& g
  x

parses as

   foobar ((f &&& g) x)

under the new proposal, which I find highly confusing. If it doesn't parse
like this under the proposal, the wiki page is wrong and/or the proposal is
not compositional: Why should being below "foobar" change the parse?
"foobar" is not a keyword switching to some different mode.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Sven Panne]

2016-07-08 9:09 GMT+02:00 Joachim Breitner <m...@joachim-breitner.de>:

> Am Freitag, den 08.07.2016, 08:35 +0200 schrieb Sven Panne:
> >foobar
> >   do f &&& g
> >   x
> [...] Only with the proposed addition, it becomes an argument to foobar.
> [...]
>

Huh?  Nope! The Wiki page explicitly says that

   do f &&& g
   x

means

   (f &&& g) x

Why should this be different here? Simply writing "foobar" above that
construct won't trigger any special layout rules, I hope...
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Sven Panne]

[ There is a trend to repeat one's argument about this proposed extension
in various mailing lists/wiki pages/etc., so let's repeat myself, too... :-]

2016-07-07 19:44 GMT+02:00 Carter Schonwald :

> the fact that its perilously close to looking like *1 typo* away from a
> parser error about record syntax makes me
> *-1000* now [...]
>

-1000 for exactly the same reason, and more: If you look at the "Block as a
LHS" section on the wiki, things get insame IMHO:

   do f &&& g
   x

should mean "(f &&& g) x"? It's probably 99% more likely that somebody
didn't get the indentation right for the "do". And what about:

   foobar
  do f &&& g
  x

Should the x now be an argument of foobar (as it is currently) or the "do"?
If it is not an argument of the "do", suddenly things get very
context-dependent. Computers are good at handling context-dependent things,
humans are quite bad at it.

Taking one step back: I think a lot of the discussion is based on the false
assumption that "something can be parsed in an unambiguous way by some more
or less random parsing technology" means "it can easily be parsed by a
human". This is a fundamental misconception, otherwise reading programs in
Brainfuck or Whitespace would be easy, too. In our case at hand, visually
determining what is an argument of a function in a quick way is *supported*
by some (perhaps) redundant syntactic stuff. That's exactly the reason why
the current record syntax is a big mistake: Normally, an argument is
beginning after a whitespace (unless there are other syntactic clues like
'$', '(', etc.), but

   foo bar { baz = blah }

runs against this intuition and one has to mentally backtrack. The proposal
at hand would enshrine this kind of broken syntax in more places. As has
already been said in another thread, the goal of language design is not to
make writing correct programs easier (by allowing more and more syntax),
but to make writing wrong programs harder.

And a note about counting votes: I think normal democrating voting
procedures simply don't apply here. Even if e.g. 80% of the voters find
something OK while the other 20% find it confusing, the majority vote
doesn't make the confusion of a fifth of the people go away. For a change
like this, I would expect near unanimous consent, but I think we are very,
very far away from that...
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [Feedback requested]: -fhelpful-import-errors

[Sven Panne]

2016-02-16 18:12 GMT+01:00 Tom Sydney Kerckhove :

> [...] As suggested by `thomie`, I created a design proposal at
> https://ghc.haskell.org/trac/ghc/wiki/Proposal/HelpfulImportError
> and am now looking for feedback.


[ Not sure if the feedback should be submitted here on in the corresponding
ticket... ]

Just a few quick remarks:

   * Whatever you do, never walk the file system tree up or down in an
uncontrolled way, this will kill basically all benefits and is a
show-stopper. File systems like NFS, NTFS, stuff on USB sticks etc. are so
*horribly* slow when used that way that the walks will probably dominate
your compilation time. And even under Linux it's not uncommon to have a few
dozen directory levels and hundreds of thousands of files below our cwd:
Just check out a few repositories, have some leftovers from compilations,
tons of documentations in small HTML files etc., and this sums up quickly.
Git walks up the tree, but only looking for a specific directory and will
e.g. not cross mount points under normal circumstances. This is probably
the limit of what you can do.

   * Caching between runs will be tricky: How will you invalidate the
cache? People can (and will :-) do all kinds of evil things between runs,
so how can you (in-)validate the cache quicker than re-scanning the file
system again?

   * As a general rule to keep in mind during the design: Successful
compiler runs should not pay a price. It's OK if things are a little bit
slower when an error occurs, but the main use case is successful
compilation. This is a bit like exceptions in most programming language
implementations: They are more or less for free when you don't use them
(yes, they have a cost even then because they complicate/invalidate some
compiler optimizations, but let's forget that for now), and are often
costly when you actually raise them.

Just my 2c,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Reconsidering -Wall and -Wcompat

[Sven Panne]

2016-02-14 17:12 GMT+01:00 Ben Gamari :

> [...] This proposal is motivated by concern expressed by some that -Wcompat
> would see little usage unless it is placed in one of the warning sets
> typically used during development. One such set is -Wall, which enables
> a generous fraction of GHC's warning collectionand is is intended [2]
> for use during development.
>

IMHO, the distinction between "during development" and "outside of it" is
purely hypothetical.  A typical workflow is: Develop your code locally
against one GHC/set of libraries, commit to GitHub and let Travis CI do the
real work of testing against a matrix of configurations. If things work
well and the changes are worth it, tag your current state and release it.
Where exactly in this scenario is the code leaving the "during development"
state? I definitely want to enable -Wall for the Travis CI builds, because
that's the place where they are most valuable. As stated on the Wiki, stuff
in -Wcompat will often be non-actionable, so the only option I see if
-Wcompat is included in -Wall will be -Wno-compat for all my projects.
-Wcompat would be restricted to a few manual local builds to see where
things are heading.


> Unfortunately, despite the (albeit only recently stated) intent of
> flag, -Wall is widely used outside of development [3], often with the
> expectation that the result be warning-clean across multiple GHC
> versions. While we hope that -Wall will see less use in this context in
> the future, [...]


Seeing -Wall this way is quite unusual, especially for people coming from
C/C++ (and the numbers quoted from Hackage seem to be a hint that others
think so, too). Normally, -Wall -Wextra -pedantic etc. are life-savers and
should be kept enabled all the time, unless you like endless debugging
hours, of course.

In a nutshell: I would consider -Wall implying -Wcompat an annoyance, but
as long as it can be disabled by 2 lines in .travis.yml, I don't really
care. ;-)

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Typing pattern synonyms

[Sven Panne]

The type of a pattern synonym like

   pattern FOO = 1234

seems to be '(Eq a, Num a) => a', which makes partially makes sense,
although it's not immediately clear to me where the 'Eq a' part comes from.
But probably that would be clear if I read the desugaring rules closely
enough. ;-) My real question is about:

   pattern FOO = 1234 :: Int

This doesn't compile out of the box, GHC seems to require
ScopedTypeVariables, too:

Illegal type signature: `Int'
  Perhaps you intended to use ScopedTypeVariables
In a pattern type-signature

Why is this the case? From a user perspective, the error is totally bogus,
there are no visible type variables at all. Can GHC be fixed to avoid
enabling ScopedTypeVariables?

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Typing pattern synonyms

[Sven Panne]

2015-09-30 20:10 GMT+02:00 David Feuer :

> The Eq constraint is needed to support pattern matching, the raison d’être
> of pattern synonyms.
>
I was just a bit confused by the fact that normally you don't need an 'Eq
a' constraint for pattern matching. But looking at the Haskell report, one
can see that matching against numeric/char/string literals involves (==),
so:

\x -> case x of 1234 -> undefined :: (Eq a, Num a) => a -> r

This makes sense now, and there is no magic involved. :-]

> I'm pretty sure the reason you need ScopedTypeVariables for your second
> example is that GHC only allows pattern signatures with that extension
> enabled.
>
My main question is: Why is this the case? Is it really necessary in our
simple example? The GHC docs should probably mention the magic behind this
in the patter synonym section.


> Once upon a time there was a separate PatternSignatures extension, I
> believe, but not any more.
>
Never heard of that one...
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: HEADS UP: Need 7.10.3?

[Sven Panne]

Building Haddock documentation on Windows for larger packages (e.g.
OpenGLRaw) is broken in 7.10.2, similar to linking: The reason is once
again the silly Windows command line length limitation, so we need response
files here, too. Haddock 2.16.1 already has support for this, but this
seems to be broken (probably
https://github.com/haskell/haddock/commit/9affe8f6b3a9b07367c8c14162aecea8b15856a6
is missing), see the corresponding check in cabal (
https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/Haddock.hs#L470
).

So in a nutshell: We would need a new Haddock release (bundled with GHC
7.10.3) and a new cabal release with support for Haddock response files (in
cabal's HEAD, but not yet released). Would this be possible?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: simultaneous ghc versions

[Sven Panne]

 [...] The only thing I find missing is the ability to install a binary
 distribution without overwriting the existing symlinks (e.g. ghc -
 ghc-7.8.4).


I second the OP's request and Reid's one: I think the binary distributions
for *nices should neither contain unversioned executables nor should they
try to link these to the versioned ones for themselves. This is exactly
what update-alternatives is for, and it does it in a very principled,
standard way everyone understands (or can at least look up :-). Death to
the not-invented-here syndrome! :-D
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: broken source link

[Sven Panne]

2015-07-24 9:59 GMT+02:00 Christian Maeder c.mae...@jacobs-university.de:

 when trying to look up the original definition for
 Data.List.transpose in

 https://downloads.haskell.org/~ghc/latest/docs/html/libraries/Data-List.html
 I found that the source link

 https://downloads.haskell.org/~ghc/latest/docs/html/libraries/src/Data-OldList.html#transpose
 does not work. [...]


Hmmm, basically *all* source links in the library documentation are broken,
I've tried 2 dozen, and none worked... :-/

I think we had several problems with the documentation in the past, so
would it make sense to run an automatic link checker on the library docs
and post the result to e.g. ghc-builds?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.10.2 Release Candidate 2

[Sven Panne]

2015-07-07 7:26 GMT+02:00 Mark Lentczner mark.lentcz...@gmail.com:

 And now Windows RC2 for Haksell Platform is also here:

 http://www.ozonehouse.com/mark/platform/

 [...]


I noticed 2 problems so far:

* The package cache is still always out of date (I thought there was a fix
for that):

--
Sven@SCOTTY /d/Repositories/ObjectName (master)
$ ghc-pkg list
WARNING: cache is out of date: c:/Program Files/Haskell
Platform/7.10.2\lib\package.conf.d\package.cache
ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.
c:/Program Files/Haskell Platform/7.10.2\lib\package.conf.d:
Cabal-1.22.4.0
GLURaw-1.5.0.1
GLUT-2.7.0.1
[...]
--

* Something is missing/misconfigured for Haddock (note the funny non-local
path in the error message):

--
Sven@SCOTTY /d/Repositories/ObjectName (master)
$ cabal sandbox init
Writing a default package environment file to
d:\Repositories\ObjectName\cabal.sandbox.config
Creating a new sandbox at D:\Repositories\ObjectName\.cabal-sandbox

Sven@SCOTTY /d/Repositories/ObjectName (master)
$ cabal configure
Resolving dependencies...
Configuring ObjectName-1.1.0.0...

Sven@SCOTTY /d/Repositories/ObjectName (master)
$ cabal haddock
Running Haddock for ObjectName-1.1.0.0...
Preprocessing library ObjectName-1.1.0.0...
Haddock coverage:
 100% (  3 /  3) in 'Data.ObjectName'
Haddock's resource directory
(G:\GitHub\haddock\.cabal-sandbox\x86_64-windows-ghc-7.10.1.20150630\haddock-api-2.16.1)
does not exist!
--
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.10.2 Release Candidate 2

[Sven Panne]

2015-07-07 13:30 GMT+02:00 Thomas Miedema thomasmied...@gmail.com:



 On Tue, Jul 7, 2015 at 10:54 AM, Sven Panne svenpa...@gmail.com wrote:

 * The package cache is still always out of date (I thought there was a
 fix for that):


 Please reopen https://ghc.haskell.org/trac/ghc/ticket/10205 with the
 output of `which ghc-pkg` and `ghc-pkg list -v`.


Done.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Trouble building applications with Haskell GLUT and freeglut on OS X with GHC 7.10.1

[Sven Panne]

Just a quick addition: The bug tracking this on the GLUT package side is
https://github.com/haskell-opengl/GLUT/issues/19, and it seems to be a
regression in the 7.10 series...
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] RFC: Native -XCPP Proposal

[Sven Panne]

2015-05-06 16:21 GMT+02:00 Bardur Arantsson s...@scientician.net:
 +1, I'll wager that the vast majority of usages are just for version
 range checks.

The OpenGL-related packages used macros to generate some binding magic
(a foreign import plus some helper functions for each API entry),
not just range checks. I had serious trouble when Apple switched to
clang, so as a quick fix, the macro-expanded (via GCC's CPP) sources
had been checked in. :-P Nowadays the binding is generated from the
OpenGL XML registry file, so this is not an issue anymore.

 If there are packages that require more, they could just keep using the
 system-cpp or, I, guess cpphs if it gets baked into GHC. Like you, I'd
 want to see real evidence that that's actually worth the
 effort/complication.

Simply relying on the system CPP doesn't work due to the various
differences between GCC's CPP and the one from clang, see e.g.
https://github.com/haskell-opengl/OpenGLRaw/issues/18#issuecomment-31428380.
Ignoring the problem doesn't make it go away... ;-)

Note that we still need CPP to handle the various calling conventions
on the different platforms when the FFI is used, so it's not only
range checks, see e.g.
https://github.com/haskell-opengl/OpenGLRaw/blob/master/OpenGLRaw.cabal#L588.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Sven Panne]

2015-05-02 12:01 GMT+02:00 Paolino paolo.verone...@gmail.com:
 Hello, I succeded in compiling
 https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html
 on a 32 bit machine with 2GB of memory with ghc 7.10.1. O_O

To alleviate the pain a bit, I've uploaded a new version of OpenGLRaw
(2.5.0.0) to Hackage, containing 2 improvements:

   * 'foreign import dynamic's with the same signature are re-used,
cutting down their number from 3062 to 864.

   * Those 'foreign import dynamic's live in a separate module now.

Travis CI seems to be happy with these changes (the VMs there don't
have much memory, either), although Haddock still seems to eat memory
like hell. But that's a different story...

It would be nice to hear if the new version improved the situation for
people who previous had trouble.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Unable to build 7.10.1 RC1 on Jessie

[Sven Panne]

2015-01-25 11:18 GMT+01:00 harry volderm...@hotmail.com:
 [..] This can be reproduced by running the following commands in the
 debian:jessie docker image:

 apt-get update
 apt-get install ncurses-dev curl gcc ghc make libgmp-dev xz-utils
 curl
 http://downloads.haskell.org/~ghc/7.10.1-rc1/ghc-7.10.0.20141222-src.tar.xz
 | tar xJ
 cd ghc-*
 ./configure
 make

 Any suggestions for someone who knows nothing about c or cpp?

Perhaps there is no C++ compiler installed? Try to add g++ to your
apt-get install command line.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1

[Sven Panne]

2014-11-25 20:46 GMT+01:00 Austin Seipp aus...@well-typed.com:
 We are pleased to announce the first release candidate for GHC 7.8.4:

 https://downloads.haskell.org/~ghc/7.8.4-rc1/ [...]

Would it be possible to get the RC on
https://launchpad.net/~hvr/+archive/ubuntu/ghc? This way one could
easily test things on Travis CI.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: RFC: changes to -i flag for finding source files

[Sven Panne]

2014-04-25 22:26 GMT+02:00 Malcolm Wallace malcolm.wall...@me.com:
 [...] The feature seems like a very low power-to-weight ratio, so -1 from me.

-1 from me, for the same reasons.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: PROPOSAL: Literate haskell and module file names

[Sven Panne]

2014-03-17 14:22 GMT+01:00 Brandon Allbery allber...@gmail.com:
 On Mon, Mar 17, 2014 at 9:08 AM, Edward Kmett ekm...@gmail.com wrote:

 Foo+rst.lhs does nicely dodge the collision with jhc.


 Is this legal on Windows?

According to 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
it is, although I can't test this at the moment.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Linking and constants problems with OpenAL under Windows

[Sven Panne]

Am Sonntag, 15. Februar 2009 08:32:59 schrieb Jared:
 The OpenAL binding's wiki page directs questions to Haskell-Cafe, but the
 more serious of my problems seems to be with GHC.  My platform is GHC
 6.10.1 under Windows XP.  This post boils down to two questions.  First,
 why would GHCi and GHC look for different symbol names when linking, and
 second, has anybody had any success working with the OpenAL binding on
 Windows? [...]

I've just released a new version of the OpenAL package on Hackage. That one 
and the previous release fixed two things which might be related to your 
problems (calling convention and #including headers when checking for constant 
values). Could you please give the new version a try and report the results? 
If things go wrong, a full transcript of the configuration stage and the 
generated config.log file would be very helpful.

Cheers,
   S.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: compiling on solaris 9

[Sven Panne]

On Friday 14 September 2007 16:33, Robert Andersson wrote:
 stdint.h seems to be unavailable on solaris 9. Looking at the
 rts/posix/OSMem.c file we find

   /* no C99 header stdint.h on OpenBSD? */
   #if defined(openbsd_HOST_OS)
   typedef unsigned long my_uintptr_t;
   #else
   #include stdint.h
   typedef uintptr_t my_uintptr_t;
   #endif

Uh, oh... Using long doesn't look very 64bit-safe (it could be int, long, long 
long, who knows?). IIRC some systems without stdint.h provide at least 
inttypes.h, so we should perhaps use this as a fallback?

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: compiling on solaris 9

[Sven Panne]

On Saturday 15 September 2007 13:58, skaller wrote:
 [...]
 1. Measure the size (and alignment, while at it) of all the
 integer types. (trial execute and run).
 [...]
 4. For the ones provided, AND size_t, ptrdiff_t, check
 their size (and signedness). (trial execution)

Small additional note: One can determine the size and alignment *without* 
always resorting to trial execution. Autoconf does this by an 
ingenious evaluation by compilation technique in case of cross-compilation, 
see the implementation of AC_CHECK_SIZEOF and AC_CHECK_ALIGNOF.

 [...]
 6. Test what the typedefs found are actually aliased to
 using C++ (there is no other portable way to do this).
 (Trial execution)

To be honest, I don't understand that point...

Cheers,
  S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ghc6.6 on ps3 - compile error in StgCRun

[Sven Panne]

[ Sorry for the late reply, but I'm just digging through 2-3 months of 
emails... ]

On Saturday 21 April 2007 12:13, Tristan Allwood wrote:
 [...] I now have a shiny new, all extralib (-opengl) ghc 6.6 all working :)

Is there no OpenGL support on the PS3 platform you are compiling on or is it 
just the configure magic failing to detect it? In the latter case I would be 
interested in getting it working.

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ghc-6.6-src-extralibs.tar.bz2

[Sven Panne]

Am Freitag, 8. Dezember 2006 21:08 schrieb Ian Lynagh:
 This will probably have been made with whatever OpenGL was in darcs when
 the build was done (the binary distributions come from the nightly
 builds). [...]

OK, so in a nutshell: Everything is fine with the binary releases, it can just 
be the case that different platforms might see different package versions of 
non-core packages. No big deal to upgrade/downgrade later, given our package 
system/Cabal.

 We should possibly do
 something like having only odd second components (e.g. version 2.3 but
 not version 2.4) in darcs repos so we can at least spot these unstable
 version numbers. Then to do a release you'd push the three patches
 Version=2.4; tag 2.4; Version=2.5
 all at once.

This makes sense, and it would be good if all packages in 
darcs.haskell.org/packages agreed on this numbering scheme. One minor 
question: Who will actually push those three patches and when?

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ghc-6.6-src-extralibs.tar.bz2

[Sven Panne]

Am Donnerstag, 7. Dezember 2006 11:37 schrieb Christian Maeder:
 The archive
 http://www.haskell.org/ghc/dist/6.6/ghc-6.6-src-extralibs.tar.bz2
 does not contain the files ControlPoint.hs and Domain.hs from directory
 libraries/OpenGL/Graphics/Rendering/OpenGL/GL/

If I see things correctly, the 6.6 extralibs contain the version 2.1 of the 
OpenGL package, i.e. the stuff currently in 
http://hackage.haskell.org/packages/unstable/OpenGL/, at least I hope so. :-/

 These files are listed by the binary distribution
 http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-unknown-linux.tar.bz2

 Personally I don't miss these files, but they are of course missing from
 distributions I (and possibly others) made.

 How imported are these files? They are also not listed in
 libraries/OpenGL/openGL.cabal.

The current HEAD (i.e. http://darcs.haskell.org/packages/OpenGL/) contains the 
bleeding edge version of the OpenGL package, and the version number has 
already been bumped to 2.2 there (although the version is not yet finished) 
to avoid confusion. Due to some refactorings, this version has the modules 
you've mentioned, and they are in the .cabal file, too. So if there is 
something wrong, it must be the packaging of the 6.6 distributions, but not 
the OpenGL package itself.

To be honest, I don't fully understand the workflow for building the 
official GHC distributions currently. In former times, the whole tree, 
including libraries, had a CVS tag, so things were crystal-clear. But due to 
the new flexibility of making packages independent, we suffer from versionits 
now, it seems... Some comments/explanations from the packagers are highly 
welcome.

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: OpengGL lockup using GHC 6.6 on Intel Mac

[Sven Panne]

Am Mittwoch, 29. November 2006 19:29 schrieb Joe Jones:
 [...] Anyone know of any issues with the current HOpenGL on Intel? [...]

The Haskell versions of the NeHe tutorials work for me on x86_64 openSUSE 10.1 
(GHC 6.6 and bleeding edge GHC from darcs repo, perhaps a few weeks old), so 
I guess that this is a Mac issue. Jason converted the tutorials on a G4, so I 
assume it is a problem with Mac + Intel. I don't have access to such a 
platform, so some help is needed. Do any of the examples from

   http://darcs.haskell.org/packages/GLUT/examples/

work on your platform?

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: HOpenAL and Haskore

[Sven Panne]

Am Donnerstag, 24. August 2006 11:29 schrieb Juan Rodríguez Hortalá:
 [...]
 And the later is about HOpenAL. Some information is found in
 http://www.haskell.org/HOpenGL/newAPI/index.html , on the entry for
 Sound, but I wonder if there is some tutorial or additional
 documentation anywhere. [...]

Once again, I have to admit that I should write more documentation for my 
packages... :-( Alas, I don't know about any tutorials for the OpenAL/ALUT 
binding, but at least Google can help you to find some for OpenGL/GLUT, which 
is admittedly not very helpful when you try to do some sound programming. The 
general strategy for all those packages is:

 * The underlying C APIs are quite large, so writing detailed documentation 
and tutorials is a herculean task. Therefore it is mandatory to be able to 
re-use existing material for the Haskell bindings.

 * The user of the packages is expected to know the C APIs.

 * The module structure and consequently the Haddock documentation is 
structured very similar to the corresponding specification documents. So when 
you see e.g. 
http://www.haskell.org/HOpenGL/newAPI/OpenAL/Sound-OpenAL-AL-Listener.html 
(updated a few minutes ago) and have a look at the OpenAL specification (sec. 
4.1 and sec. 4.2 in this case), you should have no problems using the stuff, 
even when only reading the synopsis. At least that's the plan... ;-) 
Currently the GLUT and OpenAL packages have quite extensive Haddock 
documentation, the OpenGL package only partly, and the ALUT package 
practically none.

 * ALUT (and GLUT) come with some well-known examples to get you started: 
http://darcs.haskell.org/packages/ALUT/examples/

Of course all this is not a substitue for a nice tutorial, but the Haskell 
wiki would be a great place for this. (= hint ;-) For further questions, the 
libraries mailing list might be a better place.

Cheers,
   S.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Packages in GHC 6.6

[Sven Panne]

Am Mittwoch, 23. August 2006 15:23 schrieb Bulat Ziganshin:
 [...]
 i think that better way is to supply non-core libs in source form and
 just recompile them in this case. so, [...]

Nice theory, but this doesn't work at all in practice: The majority of the 
packages mentioned so far are not purely Haskell, so one needs tons of 
development tools and C libraries, headers, etc. (all in a consistent state, 
of course) to compile those packages, which is a bit tricky on *nices and a 
huge task on WinDoze. And there might even be packages where Joe User can't 
get the development tools without signing an NDA...

Regarding the sets of packages: This discussion comes up again and again, but 
it does not really focus on the main point, namely that we simply don't know 
what is important for a specific user or not. Some people can't live without 
XML parsing, others want fancy graphics and sound, others depend on 
elaborated datastructures but are otherwise happy with putStrln. So the only 
sane way to proceed is as Simon suggested: Ship GHC with the packages needed 
to compile and run Hello, world! and those which are intimately tied to 
GHC, and all the rest is shipped separately.

Cross-module optimizations introduce a lot of dependencies, but are one of the 
strong points of GHC and are *absolutely* necessary to get decent performance 
for some applications. I would very much object to give this up for more 
stable ABIs. This is not a real problem on mature platforms with sensible 
package management systems, like most modern Linux distros, where one could 
easily upgrade GHC and automatically upgrade all the Haskell packages needed. 
Of course WinDoze is a bit different here. Therefore I opt for 2 different 
WinDoze installers, everything between doesn't make sense IMHO:

 * A set of highly modularized, small, separate installers for GHC/core 
packages and each non-core package.

 * As an alternative, a sumo/omnibus/whatever you call it installer 
containing everything from the central darcs repo, plus probably even more. 
This can have the option to install only a subset of the contained packages.

The best option would of course be some kind of net installer, just like 
Cygwin's setup.exe, but this is of course something for the future. 
Meanwhile, the first set of small installers should make people happy which 
have only a limited amount of disk space and a slow internet connection, 
while the sumo installer should make people with modern machines and 
high-speed ADSL/cable-modem/T1 more happy. Let's not forget that we live in a 
world where patches regularly exceed 100MB, downloadable game demos are 1GB 
and disks with 200GB are common even in cheap new computers. In such a 
setting, it is hard to argue that it is much better to surf the Net for an 
hour to get all the packages one wants instead of downloading and installing 
everything in a single click within minutes...

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Building head numerics project

[Sven Panne]

Am Freitag, 5. Mai 2006 09:13 schrieb Simon Peyton-Jones:
 The most straightforward thing to do is not to build the OpenAL package.
 I'm sure Sven is working on fixing it, but meanwhile it's entirely
 inessential.  Simply edit the libraries/Makefile.

I've already fixed the ALUT package, but I'd like to do some more testing 
before I commit the changes. The OpenAL package will be the next thing I'll 
have a look at. The problems resulted from unstable specifications, but the 
good thing is that the specs for both OpenAL and ALUT are quite stable now. 
Hopefully all the distros out there will follow soon with shiny new stable 
packages... :-]

Editing the Makefile should not be necessary, --disable-openal or 
--disable-alut (whatever fails) during configurationtime should be enough.

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC vesrion 6.4.2

[Sven Panne]

Am Sonntag, 30. April 2006 10:15 schrieb Bulat Ziganshin:
 may be it's not too late to just rerelease GHC? especially if hooks
 interface in current cabal version don't planned to change in
 foreseeable future. having common cabal interface for 6.4.2 and 6.6
 will be a great thing

I think that re-releasing SW with varying functionality/APIs under the same 
release number is the worst one can do, as this will only cause confusion 
(Which GHC 6.4.2 are you talking about in your bug report? etc.). A 6.4.3 
release seems to be the more appropriate way and the amount of work involved 
is the same.

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: How to access hs_free_fun_ptr from a Visual Studio DLL

[Sven Panne]

Am Montag, 27. März 2006 14:27 schrieb Brian Hulley:
 [...] For example, in:

foreign import ccall wrapper mkIO :: IO () - IO (FunPtr (IO ()))
foreign import ccall set_callback :: FunPtr (IO ()) - IO ()
foreign import ccall run :: IO ()

foo1 :: IO ()
foo1 = do
   set_callback foo2
   something_else-- does this code still exist?

foo2 :: IO ()
foo2 = ...

main = do
   set_callback foo1
   run  -- causes foo1 to be called at some point

 where set_callback wraps its arg in a FunPtr and calls freeHaskellFunPtr if
 a previous callback function has already been specified.

 If foo1 is generated as dynamic code, then freeing the FunPtr to it as a
 consequence of changing the callback to foo2, becomes problematic unless
 there is a guarantee that currently executing code is always considered to
 be rooted by the program counter.

 So my questions are:

 1) Is my understanding of the FFI definition of freeHaskellFunPtr
 incorrect?

Partially, yes. Your example above leaves out an important point: Calling 
mkIO. Regardless of the implementation details, this has to accomplish two 
things:

 * Making sure that the Haskell function being wrapped is not garbage 
collected. This is important, because the returned FunPtr might contain the 
last reference to the wrapped function internally.

 * Setup some mechanism which does the impedance matching between C and 
Haskell, i.e. put the arguments in the right places, do some stack fiddling, 
etc.

For GHC (and Hugs, IIRC), this is solved by generating a StablePtr to the 
Haskell function and baking it somehow into dynamically generated code (see 
ghc/rts/Adjustor.c), which does the argument/stack fiddling and then jumps to 
some C stub, which in turn uses the StablePtr and the rest of the arguments 
to call the Haskell function. If this sounds tricky and highly 
platform-dependent: Yes, it is! :-)

The main point here is: The Haskell runtime doesn't know the time when it is 
safe to free the StablePtr and the dynamically generated adjustor code. The 
FunPtr's C equivalent could be stored anywhere in C land, perhaps in some GUI 
callback table, some global variables, it could be in use by some other 
(non-Haskell) thread, etc. etc. Consequently, the programmer must help via 
freeHaskellFunPtr/hs_free_fun_ptr, but this should not happen while the 
FunPtr is in use, e.g. while the Haskell callback is currently being 
executed. The technical reason for this is that after returning from Haskell 
land, the adjustor code might need to do some cleanup:

   C - adjustor - stub - Haskell - stub - adjustor - C

It could be the case that the adjustor tail-jumps to the stub, but this is not 
guaranteed to be the case for all platforms.

 2) Are some implementations not treating the program counter and call stack
 as roots for blocks of memory which contain dynamically generated code that
 is currently executing?

As hopefully explained above, a pointer to the adjustor could be everywhere, 
so GC is not an option here.

 3) Are some implementations treating a FunPtr as the sole owner of the code
 it is pointing to, thus requiring the workaround of a scavenger function to
 safely free FunPtr's at a point where it is known that none of the code
 pointed to by any of the FunPtr's is currently executing?

Ownership is not the problem here, but lifetime: A callback should simply not 
free its own FunPtr. This requirement is not much different from having to 
avoid accessing memory which has already been freed.

I know that this is all complicated stuff, but if you would really like to 
understand the mechanisms behind, it would probably be best to pick a 
platform you know and have a look at  dsFExportDynamic in
ghc/compiler/deSugar/DsForeign.lhs and ghc/rts/Adjustor.c.

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: How to access hs_free_fun_ptr from a Visual Studio DLL

[Sven Panne]

Am Samstag, 25. März 2006 20:00 schrieb Brian Hulley:
 I've found a workaround to the problem below: instead of trying to use
 hs_free_fun_ptr, I instead pass a FunPtr to the Haskell function
 freeHaskellFunPtr into my DLL, and use this to free everything, finally
 using it to free itself (!) which I assume should be safe. [...]

It has been quite some time since I've worked on GHC's Adjustor.c and Hugs' 
FFI, but IIRC it is in general *not* safe to do this. On some platforms code 
is being generated dynamically for these kind of callbacks, which has already 
been freed by the time the callback returns. This might appear to work, 
depending on your processor architecture and dynamic memory management 
behaviour, but it's better not to rely on this. Perhaps the FFI spec should 
be clearer here.

I had a similar problem in for timer callbacks in my GLUT binding. They are 
one-shot and have to clean themselves up after the callback executes. The 
solution was to register the FunPtrs to be cleaned up only and do the real 
work in another scavenger callback, see 
http://darcs.haskell.org/packages/GLUT/Graphics/UI/GLUT/Callbacks/Registration.hs

Cheers,
   S.
   
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ForeignPtr's - why can't they be passed directly to foreign functions?

[Sven Panne]

Am Mittwoch, 15. März 2006 18:16 schrieb Duncan Coutts:
 On Wed, 2006-03-15 at 17:01 +, Brian Hulley wrote:
  The above two things were what I was expecting the compiler to do for me
  instead of me having to manually write a wrapper function in Haskell
  using withForeignPtr for each wrapper function for each foreign
  function...

 This is exactly the sort of thing that FFI tools automate. Indeed they
 can do this and much more.

Duncan is right here: Our design goal when specifying the FFI was to define 
only those mechanisms which are absolutely necessary to interface to foreign 
languages. Everything which doesn't need any help from the compiler/RTS is 
explicitly left to higher-level tools. The only real redundancy AFAIK is the 
fact the newtypes are transparent to the FFI, but this is extremely handy 
and improves type safety and readability quite a bit. I admit being guilty 
for having insisted on that non-minimalistic feature, but I'm proud of 
it... ;-)

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: How to find out the C type signature corresponding to a Haskell function type in FFI?

[Sven Panne]

Am Donnerstag, 9. März 2006 08:46 schrieb Bulat Ziganshin:
 Thursday, March 9, 2006, 2:20:00 AM, you wrote:
  foreign import ccall duma_init :: Int - IO Int

 MQK HsInt duma_init(HsInt arg);
 MQK Or use int on the C side and CInt on the Haskell side.
 MQK fromIntegral can be used for converting integers in Haskell.

 for small home projects you can even use Int and int which
 would work in most of Haskell implementations

Uh, oh... :-( This is roughly as safe as assuming that short, int, long, and 
long long are of the same size, so this is highly discouraged. The rationale 
behind the FFI addendum is as follows:

 * If you want to use a given C API, use the types from Foreign.C.Types on the 
Haskell side in the foreign imports.

 * If the C API is under your control, you have basically two options: Either 
use Foreign.C.Types as above, or use the types/preprocessor #defines in the 
HsFFI.h header to bind to basic Haskell types. Which option is better suited 
depends on what you are trying to achieve.

This should be easy enough to use and everything else is not guaranteed to 
work...

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: darcs switchover

[Sven Panne]

Am Freitag, 16. Dezember 2005 12:20 schrieb Malcolm Wallace:
 I've been looking at the cvs configuration file CVSROOT/modules.
 I /think/ the procedure is something like changing this:

   nhc98src-d nhc98   nhc98
   nhc98libraries  -d nhc98/src/libraries fptools/libraries
   nhc98   -a nhc98src nhc98libraries

 to this:

   nhc98src-d nhc98   nhc98
   nhc98libraries  -o darcs get --reponame=nhc98/src/libraries \
http://cvs.haskell.org/darcs/libraries
   nhc98   -a nhc98src nhc98libraries

 and then a fresh cvs checkout of the nhc98 would be required in
 order to pick up the new location.  Has anyone else tried this kind
 of tweak before and confirm that it is likely to work?  If not,
 I might test it out with the smaller cpphs module initially.

As already mentioned on the cvs-all list this morning, this does not 
work... :-(

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: New bug tracker: Trac

[Sven Panne]

Am Dienstag, 6. Dezember 2005 17:42 schrieb Simon Marlow:
 [...]
 Developers with an account on cvs.haskell.org: please add yourselves as
 users on the Trac, so I can give out permissions to edit tickets.  You
 create a user like this:

   - log in to cvs.haskell.org
   - htpasswd /srv/trac/ghc/trac.htpasswd username
   - type your password when prompted
   - let me know when you've done this

Done!

Cheers,
S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHCI and archive libraries.

[Sven Panne]

Am Samstag, 3. Dezember 2005 14:48 schrieb Lennart Augustsson:
 Can't you unpack the ar library and then link the object files
 into a shared library?

On most platforms the code in a *.a library is not shared library code, e.g. 
it is not PIC or something like that. Nevertheless, I think that the *.o 
files GHCi loads are not exactly shared libraries, they are incrementally 
linked relocatable object code (correct me if I'm wrong here, the details of 
shared libraries are still a kind of black art...). So you might have luck 
with unpacking and re-linking like that:

   ar x libblah.a
   ld -r -x -o /my/new/blah.o *.o

The linker flags for doing this vary, depending on the platform, you can have 
a look at GHC's autoconf magic for hints if it doesn't work like mentioned 
above.

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHCI and archive libraries.

[Sven Panne]

Am Samstag, 3. Dezember 2005 15:17 schrieb Lennart Augustsson:
 And on many platforms (well, at least a few years ago) a shared
 library doesn't have to be PIC.  The dynamic loader can do relocation
 when it loads the file.  (Then it can't be shared.)

 But this was a few years ago on Solaris and BSDs, it could be
 different now.

After a quick look this seems to be the case on current x86 Linux systems, 
too: Real shared libraries consist of PIC to enhance sharing code at 
runtime, but nevertheless the dynamic loader seems to be able to load and 
relocate non-PIC, at the cost of less sharing, but often slightly better code 
quality. So the mentioned repacking of a static library into a partially 
linked object file might work for most common platforms.

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: adding to GHC/win32 Handle operations support of Unicodefilenamesand files larger than 4 GB

[Sven Panne]

Am Freitag, 25. November 2005 14:38 schrieb Simon Marlow:
[...] If you want to make it clearer, then add new CPP symbols

   WIN32_UNICODE_FILENAMES
   WIN32_64BIT_OFFSETS

 these can be set based on mingw32_HOST_OS for now, but it leaves the
 possibility of using autoconf later. [...]

Perfect solution for a lazy programmer... ;-) More seriously: Perhaps I was a 
bit unclear, I don't propose to use an autoconf test for each and every tiny 
detail. Using feature-based #ifdefs and #defining them manually in a single 
well-known place based on the platform is often enough. Avoiding the annoying 
What the hell does this #ifdef really test??-questions is the point here...

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: adding to GHC/win32 Handle operations support of Unicode filenames and files larger than 4 GB

[Sven Panne]

Am Montag, 21. November 2005 13:01 schrieb Bulat Ziganshin:
 [...]
 #ifdef mingw32_HOST_OS
 type CFilePath = LPCTSTR
 type CFileOffset = Int64
 withCFilePath = withTString
 peekCFilePath = peekTString
 #else
 type CFilePath = CString
 type CFileOffset = COff
 withCFilePath = withCString
 peekCFilePath = peekCString
 #endif
 [...]
 #ifdef mingw32_HOST_OS
 INLINE time_t __hscore_st_mtime ( struct _stati64* st ) { return
 st-st_mtime; } #else
 INLINE time_t __hscore_st_mtime ( struct stat* st ) { return st-st_mtime;
 } #endif
[...]

Whatever will be done, please use *feature-based* ifdefs, not those 
platform-dependent ones above, which will be proven wrong either immediately 
or after a short time. We already have too much of those wrong ifdefs in the 
code...

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Help wanted! Win32 and HGL for GHC on Windows

[Sven Panne]

Am Freitag, 14. Oktober 2005 11:28 schrieb Duncan Coutts:
[...]
 Well for the special case of the SOE library I have a re-implementation
 of it based on Gtk+/cairo which should work on all platforms. [...]

Which additional stuff would one have to install on an e.g. off-the-shelf SuSE 
Linux distribution or Win2k to use your SOE version? If the answer is not 
none, then there is a good point in making HGL work on plain X11 *and* 
Win32. :-)

Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC 6.4 release candidates available

[Sven Panne]

Ian Lynagh wrote:
[...] Is there an equivalent of this (the no-OpenGL bit):
$(MAKE) prefix=`pwd`/debian/tmp/usr install GhcLibsWithOpenGL=NO 
GhcLibsWithGLUT=NO
that still works or do I have to do it by hand?
The OpenGL/GLUT/OpenAL packages (and a few others) are enabled automatically
if the right headers/libs are found during the configuration stage, otherwise
they are disabled. If you don't want these packages to be built, even if the
right headers/libs are available on the build platform, just give
--disable-opengl/--disable-glut/--disable-openal options to configure.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: RFC: hyperlinks in Haddock docs

[Sven Panne]

Simon Marlow wrote:
They don't look too bad to me... a bit far to the right, perhaps, but
not too bad.  Perhaps some lines in that table would help, or
alternating grey/white background for the rows? [...]
What I mean with drunk can be seen here:
   https://aedion.de/haskell/haddock.png
It's slightly different for Firefox, Netscape,... but always wrong, mixing CSS 
and
tables is a really dark corner. Anyway, alternating colors could be a good 
idea, too.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHCi and C++.

[Sven Panne]

Wolfgang Thaller wrote:
[...] *) static constructors/destructors
Sometimes there are pieces of code that expect to be called before 
main() or at program termination. The GHCi Linker doesn't support this, 
so some code may crash because things haven't been initialised properly.
This will definitely be a source of trouble if you use any C++ library 
whatsoever.
I don't know the story for Linux, but at least one other platform I know has the
addresses of those constructors/destructors in special ELF sections. GHCi could
easily iterate through these, but this is really highly platform-specific. There
used to be a description of a widespread C++ ABI on codesourcery.com, but I 
can't
find it anymore... :-(
*) multiple definitions
There is often some code in C++ header files (e.g. templates, inline 
functions, class members declared in the class declaration). These 
pieces of code are sometimes inlined, but sometimes they are not; in 
that case, gcc generates code for them in every .o file that uses them 
and counts on the linker to just include one version in the final 
executable. The GHCi linker will probably just abort and complain about 
multiply-defined symbols.
IIRC, g++ uses weak symbols for this, at least on some platforms. Handling 
these
doesn't sound too hard (easy sentence when one doesn't intend to implement it 
:-).
The above is just theory, there might be even more problems in practice 
:-( .
Exception handling comes to my mind. Nowadays it's often done via stack 
unwinding,
but I don't know about the details anymore. This might cause some trouble when
C++ code is called from Haskell.
The only golden rule I know about this all: Use only a single C++ compiler for 
the
compilation *and* linking of all your libraries and programs, otherwise be 
prepared
for long hours in front of gdb... :-(
Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: RFC: hyperlinks in Haddock docs

[Sven Panne]

Simon Marlow wrote:
On 22 February 2005 19:37, Duncan Coutts wrote:
Excellent! Thanks a lot.
Any hint as to when the next Haddock release will be?
Maybe when I've got this GHC release out of the way and my hair has
grown back :-S
Before we do a release, I think two issues should be solved IMHO:
   * The table/CSS chaos on the contents page has to be cleaned up, the package 
ids
 on the right look like being layout by somebody drunk... %-)
   * The state of the +/- buttons should be remembered when using 
backward/forward
 in a browser (cookies + ECMA script?).
Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: compiling GHC with a custom path to GCC

[Sven Panne]

Remi Turk wrote:
[...] When using the following command-line
CC=gcc3 CXX=g++3 nice ./configure --enable-hopengl --prefix=/var/tmp/ghc 
--with-gcc=/usr/local/bin/gcc3
[...]
Slightly off-topic: You don't need --enable-hopengl anymore when compiling 
GHC 6.4 or the
CVS HEAD, the OpenGL/GLUT/OpenAL packages are automatically enabled when 
autoconf finds the
suitable libraries and headers. If you don't want that, you can use 
--disable-opengl,
--disable-glut and/or --disable-openal.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: library path problem

[Sven Panne]

Akos Korosmezey wrote:
When I compile a simple code importing Control.Monad.State with 
ghc-6.4.20050217 on Linux I get linking errors:  [...]
You have to use -package mtl when --make is not used, because mtl (where
Control.Monad.State resides) is not an auto package, for more details see:
   http://haskell.org/ghc/docs/latest/html/users_guide/packages.html
Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: newbie: GHC 6.3 build problem

[Sven Panne]

Alson Kemp wrote:
[...]  I'm trying to build cvs-HEAD and am having problems.  The build 
completes just
fine, but the built GHC 6.3 does not include the -I include directories
option for GCC. [...]
I've just stumbled over exactly the same problem in this second, and I'm
already investigating what goes wrong. The problem is probably caused by a
recent change, a GHC from the HEAD about a week ago works fine... :-(
Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ghc for hp-ux 11.11...

[Sven Panne]

[EMAIL PROTECTED] wrote:
Okay, I've tried to follow the directions, and ran into a couple minor issues I
was able to work through, but I got stuck at the cd H/libraries  make boot 
make stage.  The host system is redhat enterprise linux 3, the target is hp-ux
11.11, the output is below: [...]
It looks like you try to get GHC 6.2.2 up and running. Could you try the 
GHC from
CVS HEAD instead, please? The configuration stuff has changed quite a bit, and
I'm reluctant to work on the old STABLE branch. Could you send a log of the
configuration/building plus all config.log and config.status files, please? In
ancient times, I made GHC run on HP-UX 9, but I guess that things suffer from
bit rot...
Cheers,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Error building GHC: can't locate import `Package'

[Sven Panne]

Peter Simons wrote:
When building the current CVS HEAD with ghc-6.2.2 on
Linux/x86, I get this error:
[...]
It seems that ParsePkgConfLite.hs omits the Distribution
part when importing Distribution.Package. 
Hmmm, there is no ParsePkgConfLite.hs in the HEAD anymore. Perhaps you have
some old cruft lying around in your build directory?
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Error building GHC: can't locate import `Package'

[Sven Panne]

Peter Simons wrote:
[...] It might be good to remove the file in the clean or
distclean targets, IMHO. I also noticed that
ghc/utils/ghc-pkg/.cvsignore lists it as an ignorable file,
which is why cvs update didn't show anything.
Hmmm, removing countably infinite files which don't belong to the
sources could take a little bit too long in general... :-) But I've
removed the offending line from .cvsignore, so a cvs up should
remove it when it is still there.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: building cygwin

[Sven Panne]

Simon Marlow wrote:
[...] I doubt it'll be trivial - probably lots of 

  #ifdef mingw32_TARGET_OS
will need to change to 
 
  #if defined(mingw32_TARGET_OS) || defined(cygwin_TARGET_OS)
[...]
Hmmm, having some fragile OS-dependent #ifdefs is not the way to go.
While you are there, every
   #ifdef mingw32_TARGET_OS
which needs to be changed should be replaced by something feature-specific
like
   #if HAVE_FOO_BAR_FUNCTION
and the autoconf stuff be extended accordingly. If you don't have M4
as your hobby, keeping
   #ifdef mingw32_TARGET_OS
   #define HAVE_FOO_BAR_FUNCTION
   #undef HAVE_BLAH
   ...
   #endif
in a single prominent place is much better than spreading this all
over the code
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Bug in touchForeignPtr?

[Sven Panne]

Keean Schupke wrote:
[...]
Whatever happens I think it must make sure all system resources allocated
by a program are freed on exit - otherwise the machine will have a resource
leak and will need rebooting eventually.
That's an OS task IMHO, not really the task of an RTS. Looks like you're
working on WinDoze... (sorry, couldn't resist :-)
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Bug in touchForeignPtr?

[Sven Panne]

Abraham Egnor wrote:
I've found that when writing an interface to a C library that requires
resource management, it's much better to use the withX (see
Control.Exception.bracket) style of function than to use finalizers -
programs are much easier to reason about and debug.
... and have a much more deterministic behaviour regarding resource
consumption. This is a very important point which is often forgotten.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Bug in touchForeignPtr?

[Sven Panne]

Keean Schupke wrote:
Nope there are some unix resources that c exit routines do not free
like semaphores.
Which library/OS calls do you mean exactly? I always thought that files
are the only resources surviving process termination.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: proposal for ghc-pkg to use a directory of .conf files

[Sven Panne]

Duncan Coutts wrote:
[...] The advantage of doing this is that it makes things easier for the
package managers. Each individual file can belong to the appropriate
package and so instead of having to execute registration/unregistration
actions on install/uninstall it's just another file to add/remove. The
other advantage is that there is no longer a global file that needs to
be modified which means uninstallation is cleaner (most package managers
do not remove files that were modified after installation).
These are exactly the reasons why e.g. the configuration files for apache2
on my SuSE Linux 9.1 are set up this way. It's very handy, clean and modular.
[...] I had a peak at the code in ghc for dealing with .conf files. I'd guess
it'd be best ok just check if the specified package file is a directory
or an ordinary file and act accordingly. Ie you could say -package-conf
packages/ and ghc could by default read from $HC-LIB/package.conf and
$HC-LIB/package.conf.d/ or something.
Sounds resaonable to me. I can't see any downsides of doing it this way.
I can knock up a proof of concept patch if anyone thinks this is a good
idea. It should be totally backward compatible, it's ok to use both, but
ditro packagers might like to enforce a policy of using a directory of
package files for external libraries.
OK, just send us a patch and if there are no objections we can merge it into
the HEAD.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: CVS build failure

[Sven Panne]

Peter Simons wrote:
Linux x86, I configure my build with the script:
 | #! /bin/sh --
 |
 | GHC=ghc-6.2.2
 | SUBDIRS=alex ghc haddock happy hslibs libraries
 |
 | for n in ${SUBDIRS} .; do
 |   echo $n/mk/build.mk XMLDocWays := html
 | done
 |
 | autoreconf -i
 | ./configure --prefix=/usr/local/ghc-current \
 |   --enable-src-tree-happy   \
 |   --enable-src-tree-haddock \
 |   --enable-src-tree-alex\
 |   --with-ghc=${GHC}   \
 |   --with-hc=${GHC}\
 |   --enable-hopengl  \
 |   --disable-openal  \
 |   ;
[...]
Just a small note here: Simply using
   make XMLDocWays=html
should build everything recursively, including the HTML docs, without
any need for a build.mk.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: CVS build failure

[Sven Panne]

Peter Simons wrote:
And some more information on the issue. When I run the
configure script, I see this error message on the screen
(which probably won't make it into the config.log output):
 | checking for xmllint... /usr/bin/xmllint
 | checking for DocBook DTD... ok
 | checking for xsltproc... /usr/bin/xsltproc
 | checking for DocBook XSL stylesheet directory...
 |  ./configure: line 4557: 22276 Segmentation fault
 |  $XsltprocCmd ${fp_var}/html/docbook.xsl conftest.xml
 |  /dev/null 21
 | no
 | configure: WARNING: cannot find DocBook XSL stylesheets,
 |  you will not be able to build the documentation
The xsl stylesheets are installed at
  /usr/share/sgml/docbook/xsl-stylesheets-1.65.1/
on my machine, so configure _should_ find them.
Hmmm, a segfault while running xsltproc looks like a problem with
your setup (a Gentoo system). Are you able to run xsltproc with
the HTML DocBook stylesheet on a simple document by hand? And the
hardcore way of debugging would be
   sh -x ./configure whatever you use
and make the output available.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Building the add-ons in libraries/...

[Sven Panne]

Peter Simons wrote:
The CVS version of the libraries tree comes with all kinds
of neat and dangerously unstable code I'd like to use,
particularly the arrows subdirectory. Now I wonder: Is
there some build.mk magic I could perform to tell GHC to
build these libraries as part of my normal build? So that I
get them (and the documentation) installed automatically
when I rebuild GHC? [...]
No, there isn't, but modifying libraries/Makefile should be easy (see the SUBDIRS
handling there). I'm not sure about the current status of the arrows package. Ross?
  ==fptools== make all -wr;
   in /usr/local/src/ghc-current/happy/doc
  
  rm -f -rf happy/
  /usr/bin/xsltproc --stringparam base.dir happy/ \
  --stringparam use.id.as.filename 1 \
  --stringparam html.stylesheet fptools.css \
  --stringparam toc.section.depth 3 --stringparam section.autolabel 1 \
  --stringparam section.label.includes.component.label 1   \
  /html/chunk.xsl happy.xml
  warning: failed to load external entity /html/chunk.xsl
  cannot parse /html/chunk.xsl
  make[2]: *** [happy/index.html] Error 4
  make[1]: *** [all] Error 1
  make[1]: Leaving directory `/usr/local/src/ghc-current/happy'
  make: *** [/usr/local/src/ghc-current/happy/src/happy-inplace] Error 2
  make: *** Deleting file `/usr/local/src/ghc-current/happy/src/happy-inplace'
Looks like there is a definition path missing somewhere.
It looks like configure hasn't found a DocBook XSL directory on your machine.
Could you provide us with a little bit more information, please (log of the
configure run, config.log, platform, ...)?
What's a little bit funny is that make all is trying to build documentation,
this is normally not the case. What's in your build.mk?
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Double - CDouble, realToFrac doesn't work

[Sven Panne]

It's an old thread, but nothing has really happened yet, so I'd like to
restate and expand the question: What should the behaviour of toRational,
fromRational, and decodeFloat for NaN and +/-Infinity be? Even if the report
is unclear here, it would be nice if GHC, Hugs, and NHC98 agreed on something.
Can we agree on the special Rational values below?
Printing those values could be more consistent for these systems, too, BTW.
Cheers,
   S.
Simon Peyton-Jones wrote:
| Hmmm, this is a little bit of a dark corner in the H98 report, but
there are
| probably other people on this list who know better than me. :-] The
problem
| is that 'realToFrac' is defined as 'fromRational . toRational', so the
first
| question is: How is 'toRational' supposed to handle NaN? One thing
coming to
| my mind is '0 :% 0', but this is normally a value which can't be
constructed.
| So the next question is: Would this be allowed? +Infinity and
-Infinity could
| be represented similarly then ('1 :% 0' and '(-1) :% 0'), and
'fromRational'
| could handle these values specially. But I can't believe that this has
been
| discussed for the first time. SPJ? Malcolm?
I don't recall a discussion about this, and a quick search in my mail
archive didn't turn up anything except the enclosed from George Russell.
I'm pretty ignorant about the dark corners of numerics, but it does seem
bad that passing through Rational loses information.  Perhaps the Report
should specify normalised representations for +Inf, -Inf and NaN as
Rationals (1:%0, -1:%0, and 0:%0 seem like plausible candidates).  

If someone wants to try this out, and send us a patch for the Rational
library, we could incorporate it.  And so far as the report goes,
perhaps the Errata could contain a note identifying the issue, and
suggesting a solution.  It's a bit late to *specify* a solution unless
we are really sure about it.
Simon
-Original Message-
From: George Russell [mailto:[EMAIL PROTECTED] 
Sent: 25 February 2000 10:19
To: [EMAIL PROTECTED]
Subject: Floating-point nitpicking: floor(Inf) and floor(NaN)

floor(Inf) and floor(NaN) do not appear to be defined in Standard
Haskell.
(They both come down to properFraction which is only defined for
Ratio.)
This differs from (for example) the Standard ML Basis Library, where it
is specified that floor(Int) should raise Overflow and floor(NaN) should
raise Domain.  Hence Hugs and GHC do different things.
Hugs returns floor(Inf) = 0 and floor(NaN) = 0
GHC returns floor(Inf) = very very large integer and floor(NaN) = even
larger
integer.  (This is because the GHC implementation of properFraction
simply
ignores the case of Inf/NaN and treats the artificially high exponent
encoded
in those floating-point numbers as if it were a real one.)
My own opinion is that Standard ML is right here and that floor(x)
should
raise an exception (In Haskell terms, fail) when x does not correspond
to a 
real number.

| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Sven Panne
| Sent: 08 August 2004 17:02
| To: Hal Daume III
| Cc: GHC Users Mailing List; Malcom Wallace
| Subject: Re: Double - CDouble, realToFrac doesn't work
| 
| Hal Daume III wrote:
|  [...]
|  Prelude Foreign.C (0 :: CDouble) / 0
|  NaN
|  Prelude Foreign.C (0 :: Double) / 0
|  NaN
|  Prelude Foreign.C realToFrac ((0 :: Double) / 0) :: CDouble
|  -Infinity
| 
|  yikes!  the NaN got turned into a -Infinity!!!
| 
|  aside from manually checking for 'strange' Double/CDouble values and
|  wrapping realToFrac, is there a better way?  also, does this count
as a
|  bug?
| 
| Hmmm, this is a little bit of a dark corner in the H98 report, but
there are
| probably other people on this list who know better than me. :-] The
problem
| is that 'realToFrac' is defined as 'fromRational . toRational', so the
first
| question is: How is 'toRational' supposed to handle NaN? One thing
coming to
| my mind is '0 :% 0', but this is normally a value which can't be
constructed.
| So the next question is: Would this be allowed? +Infinity and
-Infinity could
| be represented similarly then ('1 :% 0' and '(-1) :% 0'), and
'fromRational'
| could handle these values specially. But I can't believe that this has
been
| discussed for the first time. SPJ? Malcolm?
| 
| When you compile the stuff above with optimizations on, you get what
you've
| expected, thanks to RULES which shortcut the route via Rational
completely.
| 
| Cheers,
| S.
| 
| ___
| Glasgow-haskell-users mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Change in ghc-6.2.2 distribution files

[Sven Panne]

Gregory Wright wrote:
Did the file ghc-6.2.2.tar.bz2 get changed without the version number being
changed? The md5 sum of the files has changed, breaking the darwinports
and presumably the *BSD ports builds as well.
I didn't see any notice to the list, so I'm not sure if the change is 
intentional, or if the wrong file is being distributed.
Hmmm, I guess it's this:
   http://www.haskell.org//pipermail/cvs-ghc/2004-October/022173.html
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: newCString -- to 'free' or not?

[Sven Panne]

Glynn Clements wrote:
Peter Simons wrote:
When I create a CString with Foreign.C.String.newCString, do
I have to 'free' it after I don't need it anymore? Or is
there some RTS magic taking place?
How about Foreign.Marshal.Utils.new and all those other
newXYZ functions? 
Yes. The new* functions allocate the memory with malloc, and you have
to free it yourself. OTOH, the with* functions allocate the memory
with alloca, and it is freed automatically. [...]
Just to be nitpicking: The FFI does *not* guarantee that Haskell's
malloc(Bytes)/realloc(Bytes)/free is the same as C's malloc/realloc/free.
So you should not e.g. use C's free for something allocated via Haskell's
malloc.
Apart from that, it may help to remember the following equations:
   alloca = malloc + free (exception-safe!)
   new = malloc + poke
   with = alloca + poke
Depending on your needs, pooled allocation may an option, too:
   http://haskell.org/ghc/docs/latest/html/libraries/base/Foreign.Marshal.Pool.html
In that case, all allocations are belong to a given pool and memory is
deallocated when the pool in question is. Furthermore:
   withPool = newPool + freePool (exception-safe!)
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Release candidate for 6.2.2 availabe

[Sven Panne]

Peter Simons wrote:
I have some trouble building ghc from CVS HEAD. I'm not sure
whether this applies to the release candidate version, too,
Nope...
but I figured I'd better report it anyway, just in case.
Fine, we like to hear about bugs...  :-}
 1) The build fails:
My fault, already fixed.
 2) make distclean fails:
I'll have a look into it.
 3) In order to build GHC's user manual and the
documentation for the older libraries, I use the following
bit of shell scripting before I run configure:
 | DOCDIRS=alex ghc haddock happy hslibs libraries
 | 
 | for n in ${DOCDIRS}; do
 |   echo $n/mk/build.mk SGMLDocWays := html
 | done
 | 
 | echo  mk/build.mk SGMLDocWays := html

But apparently, this has stopped working! [...]
Yes, SGML docs are dead, long live XML. :-) To e.g. recursively build
all HTML documentation simply use
   make html
or to recursively build and install all documentation in HTML and PostScript:
   make XMLDocWays=html ps install-docs
This reminds me of the fact that I should update the documentation in the
HEAD a little bit... Furthermore, with our current build system there is no
need for a build.mk anymore IMHO.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Double - CDouble, realToFrac doesn't work

[Sven Panne]

Hal Daume III wrote:
[...]
Prelude Foreign.C (0 :: CDouble) / 0
NaN
Prelude Foreign.C (0 :: Double) / 0
NaN
Prelude Foreign.C realToFrac ((0 :: Double) / 0) :: CDouble
-Infinity
yikes!  the NaN got turned into a -Infinity!!!
aside from manually checking for 'strange' Double/CDouble values and 
wrapping realToFrac, is there a better way?  also, does this count as a 
bug?
Hmmm, this is a little bit of a dark corner in the H98 report, but there are
probably other people on this list who know better than me. :-] The problem
is that 'realToFrac' is defined as 'fromRational . toRational', so the first
question is: How is 'toRational' supposed to handle NaN? One thing coming to
my mind is '0 :% 0', but this is normally a value which can't be constructed.
So the next question is: Would this be allowed? +Infinity and -Infinity could
be represented similarly then ('1 :% 0' and '(-1) :% 0'), and 'fromRational'
could handle these values specially. But I can't believe that this has been
discussed for the first time. SPJ? Malcolm?
When you compile the stuff above with optimizations on, you get what you've
expected, thanks to RULES which shortcut the route via Rational completely.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: type synonyms in instances...

[Sven Panne]

MR K P SCHUPKE wrote:
[...] It just tidies up a few long instances.
... and results in far better documentation when Haddock is used. That's just
another use for the oh-so-ugly cpp.  :-]   A small excerpt from my OpenGL
binding:
-- OpenGL/include/HsOpenGLTypes.h ---
...
/* Using a type synonym in an instance head is not Haskell98, but it is much
   better for a useful documentation. */
#ifdef __HADDOCK__
#define GLbyte_   GLbyte
#define GLdouble_ GLdouble
#define GLfloat_  GLfloat
#define GLint_GLint
#define GLshort_  GLshort
#define GLubyte_  GLubyte
#define GLuint_   GLuint
#define GLushort_ GLushort
#else
#define GLbyte_   HTYPE_GLBYTE
#define GLdouble_ HTYPE_GLDOUBLE
#define GLfloat_  HTYPE_GLFLOAT
#define GLint_HTYPE_GLINT
#define GLshort_  HTYPE_GLSHORT
#define GLubyte_  HTYPE_GLUBYTE
#define GLuint_   HTYPE_GLUINT
#define GLushort_ HTYPE_GLUSHORT
#endif
-- -OpenGL/Graphics/Rendering/OpenGL/GL/BasicTypes.hs ---
...
-- | Signed 2\'s complement binary integer (min. 32 bits)
type GLint = HTYPE_GLINT
-- OpenGL/Graphics/Rendering/OpenGL/GL/Rectangles.hs 
...
instance Rect GLint_ where
   ...
-
The HTYPE_FOO are autoconf-detected types like Int32 etc. Without this cpp-trickery
the documentation for the classes/instances/types involved would be much worse.
It would be nice if the next Haskell standard supported this more directly.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Socket Options

[Sven Panne]

Carsten Schultz wrote:
Wouldn't that make
 getSocketOption :: Socket - SocketOption - IO Int
a bit strange? How would you propose to change it?
Possible, but also possibly overkill, would be:
newtype Debug = Debug Bool
newtype SendBuffer = SendBuffer (Maybe Int)
[...]
class SocketOption a where [...]
instance SocketOption Debug [...]
instance SocketOption SendBuffer [...]
[...]
setSocketOption :: SocketOption a = Socket - a - IO ()
getSocketOption :: SockerOption a = Socket - IO a
However, while quite clever :-), this would not be far from having a
seperate get/set-functions for every option (and could indeed be
implemented that way).
This is a recurring problem and has been solved several times e.g. in some
Haskell GUI bindings and my OpenGL/GLUT binding, see e.g.:
   http://haskell.org/HOpenGL/newAPI/OpenGL/Graphics.Rendering.OpenGL.GL.StateVar.html
If we had:
   socketOptionDebug :: Socket - StateVar Bool
   socketOptionSendBuffer :: Socket - StateVar (Maybe Int)
   ...
then we could write:
   socketOptionDebug mySocket $= True
   maybeBuf - get $ socketOptionSendBuffer mySocket
   ...
But there are some reasons for not using this here:
   * Alas, HasGetter/HasSetter/StateVar/... are not standard.
   * It's a bit overkill for the simple task at hand. :-)
I would simply go for a single setter function and several getters here.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ghci and ld scripts

[Sven Panne]

Simon Peyton-Jones wrote:
We've no idea what to do here.  In your case it'd be possible to just
ignore the script, but presumably not so in general. [...]
I've just made a quick test on my SuSE 9.1 Linux and it seems to be the
case that an explicit -lpthread is not necessary anymore, even for
programs using pthread calls. Strange, but handy. :-) Could you try if
things work for you without adding pthread to extra_libraries?
Another way would be using some kind of autoconf/shell magic to test
for the linker script and install a link to /lib/libpthread.so.0 with
the name myownpthread.so to the installation directory of your package
and add myonwpthread to extra_libraries. Ugly...
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [HOpenGL] GHC 6.2.1 Binding Completeness

[Sven Panne]

[ I'm cross-posting this, perhaps some kind soul has binary snapshots available. ]
Yann Morvan wrote:
[...] I recently installed the last version of GHC (6.2.1) that comes
with the new OpenGL binding. I was just starting to port my code to it,
but I have trouble finding some basic functionnalities (like glTexImage2D for 
instance). Is that binding incomplete ?
Alas, no, the OpenGL binding on the release branch is not complete.
If yes when will it be finished ? If no when will the redbook examples be ported to it ?
The story is quite a bit different on the main branch, the binding is almost
finished there, you get OpenGL 1.5 plus a few dozen extensions. The only missing
bit is currently NURBS, but it's already halfway there. We generally don't
merge new features onto the release branch, only bug fixes, hence the difference.
Currently there are official releases including this, but if you can tell a
bit about your intended platform, perhaps somebody else on the GHC/Hugs mailing
lists can help (Linux, WinDoze, MacOS X and Solaris reportedly work). I can offer
bleeding edge snapshots of Hugs and GHC including the latest and greatest OpenGL/GLUT
binding compiled for x86 Linux (SuSE 9.1, don't know if the RPMs work on other 
platforms).
Another option is building GHC and/or Hugs from CVS for yourself, which is not
that hard nowadays (at least if you have enough GB and GHz :-), see:
   http://haskell.org/ghc/docs/latest/html/building/building-guide.html
I am reduced to greping the code of the binding for calls to the C openGL
functions and suspect that I am missing things.
Thanks to Haddock, there is no need for grep-ing. I keep the docs on
   http://haskell.org/HOpenGL/newAPI/
fairly actual, and the GHC packages include similar documentation.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: UTF-8 encode/decode libraries.

[Sven Panne]

Duncan Coutts wrote:
On Mon, 2004-04-26 at 18:49, David Brown wrote: [...]
toUTF :: String - String
Hmmm, String - [Word8] would be nicer...

fromUTF :: String - String
... and here: [Word8] - String or [Word8] - Maybe String.
Furthermore, UTF-8 is not restricted to a maximum of 3 bytes per character,
here an excerpt from man utf8 on my SuSE Linux:
   * UTF-8  encoded  UCS  characters  may  be up to six bytes
 long, however the Unicode standard specifies no  characters­
 above  0x10, so Unicode characters can only be up to
 four bytes long in UTF-8.
IIRC we discussed encoders/decoders quite some time ago on the libraries
mailing list, but nothing really happened, which is a pity. We should
strive for something more general than UTF-8 - UCS/Unicode, there are
quite a few more widely used encodings, e.g. GSM 03.38, etc. Any takers?
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: undefined references when using package

[Sven Panne]

Jan Christiansen wrote:
[...] Sadly defining the dependencies didn't solve the problem. I get
this error message:
Preprocess/PhilsLine.o(.text+0x13e): In function `s2We_entry':
: undefined reference to `CHDziBaseTypes_CodePosition_con_info'
Preprocess/PhilsLine.o(.text+0x25e): In function `s2W6_entry':
: undefined reference to `CHDziBaseTypes_CodePosition_con_info'
Preprocess/PhilsLine.o(.text+0x382): In function `s2VY_entry':
: undefined reference to `CHDziBaseTypes_CodePosition_con_info'
Preprocess/PhilsLine.o(.text+0x49e): In function `s2VP_entry':
: undefined reference to `CHDziBaseTypes_CodePosition_con_info'
Preprocess/PhilsLine.o(.text+0x6a1): In function `s2Yz_entry':
: undefined reference to `CHDziBaseTypes_CodePosition_con_info'
Preprocess/PhilsLine.o(.text+0x809): more undefined references to 
`CHDziBaseTypes_CodePosition_con_info' follow
/usr/local/lib/ghc-6.2.1/libHSCHD.a(Concurrent.o)(.text+0x22): In function 
`__stginit_CHDziControlziConcurrent_':
: undefined reference to `__stginit_CHDziBaseTypes_'  [...]
All these undefined references (zi = .) seem to be within your own
package CHD, but guessing what goes wrong exactly is a bit hard without
further information. A complete log of what you are doing might help, a
tar file including your sources would be even better (when building is as
simple as make or the like). This is a general hint for people reporting
non-trivial problems: Whenever possible, package up everything necessary for
reproducing the problem in a way that a plain make suffices, and attach it
to your problem report. Remember: This is a lazy mailing list... :-)
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Two problems with heap profiling

[Sven Panne]

Stefan Reich wrote:
Problem 1: -hr crashes in some circumstances. [...]
No idea about this one...

Problem 2: hp2ps doesn't work at all. [...]
That's a little bit harsh. :-) First of all it's not hp2ps, but GHC's RTS
which has a buglet. Furthermore, it only has this problem in some locales.
As a workaround you could try to switch your locale e.g. to English while
running your Haskell program.
I've fixed this about a month ago in the HEAD, but it did not make its way
into the STABLE branch. SimonM?
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: undefined references when using package

[Sven Panne]

Jan Christiansen wrote:
I try to generate a package out of some haskell sources. Everything looks to 
work fine but when I try to compile a program using this package I get a 
linking error. It reports undefined reference to seemingly everything that 
is accessible form outside the package. I'm using ghc-6.2.1 and I would be 
very grateful for a hint.
This sounds like missing dependencies in your package configuration file. Most
package mention e.g. at least the base package:
   package_deps   = [ base ]

Looking at the undefined references will probably help to figure out what should
be mentioned in your case. You don't have to do this transitively, BTW, GHC(i)
is cunning enough to do this itself, e.g. the base package depends on the rts
package, but you don't have to specify this in your configuration file.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: What means MutVar# ?

[Sven Panne]

Hans Nikolaus Beck wrote:
[...] I've readed tha writeIORef (and readIoRef etc) is used to write directly
to memory places fo implementing variables, as in example in HOpenGL used. Is
this also Haskell standard ?
Huh? I'm not sure what you mean exactly, but with the help of unsafePerformIO
and a pragma for clever compilers you can simulate something like a global
variable in Haskell. Here an excerpt from the GLUT menu handling module:
   {-# NOINLINE theMenuTable #-}
   theMenuTable :: IORef MenuTable
   theMenuTable = unsafePerformIO (newIORef emptyMenuTable)
   getMenuTable :: IO MenuTable
   getMenuTable = readIORef theMenuTable
   modifyMenuTable :: (MenuTable - MenuTable) - IO ()
   modifyMenuTable = modifyIORef theMenuTable
Definitely not something to be proud of, but quite handy from time to time. :-)
Alternatives are passing the IORef to every function which needs it (but this
would clutter up the GLUT API in the above case) or using the FFI for holding
global data on the C side. GHC uses a similar hack internally, too, BTW.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Release Candidate for 6.2.1 available

[Sven Panne]

Just a short note from my side: I've tested both the branch (not the
.tar.bz2) on x86 Linux and the .msi on Win2k. Both seem to work fine...
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Release Candidate for 6.2.1 available

[Sven Panne]

Any chance of a *.msi for the release candidate? A nightly *.msi would
be even better...
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: config.h namespace clashes

[Sven Panne]

John Meacham wrote:
[...]
also, it would be good if config.h could be renamed to something like
ghc-config.h, because otherwise the conflict between the names can hide
bugs where you get the incorrect config.h or make it tricky to get at
the GHC one if it is actually the one you want.
That's definitely on the fptools-ToDo-List: Every package/project should
have its own configuration shell script, configuration header used only
for build time and configuration header included in pre-built distributions.
It's just a matter of splitting of configure.ac and pushing the relevant
parts down the fptools hierarchy. Any volunteers? I'll do it when I've got
some time left and no one else has done it by then, but this will definitely
not be in the near future...
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: optimization question

[Sven Panne]

John Meacham wrote:
I was wondering if:

case x of 
foo - Foo
bar - Bar
fuzz - Fuzz
fuzo - Fuzo
x - other .. thing

would optimize to

let z = other .. thing in
case x of 
('f':x) - case x of
('u':'z': x) - 
z - Fuzz
o - Fuzo
_ - z
oo - Foo
_ - z
bar - Bar
_ - z
String literals are handled in a special way in GHC, so your example is
essentially converted into an if-cascade, which is not what you want.
OTOH, if you write the strings in their expanded form like ['f','o','o'],
you get your optimized version automatically. Perhaps Simon^2 can comment
on the rationale behind this, I can't remember the reason...
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ghc-pkg 6.2 incorrectly parses commas within quotes

[Sven Panne]

Ashley Yakeley wrote:
Any word on whether this has been/will be fixed? [...]
Well, it's fixed in CVS for quite a while, but it's up to Simon^2 when a
new GHC release comes out.
Personally I'd favour tossing this feature altogether, [...]
Me too...  :-P * * *

Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: linking problems after switching from GHC5 to GHC6

[Sven Panne]

Volker Wysk wrote:
I've put together a minimal program which reproduces the problem. Save the
three attachments in a new directroy and type make. I'ts just as
described earlier. The trivial program compiles with GHC5, but not GHC6. [...]
Hmmm, it looks like GHC is reversing the order of files in the linking step.
Mentioning liba.a *before* Main.o in the linking step is a workaround...
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: classes and template haskell (bug?)

[Sven Panne]

Jeremy Shaw wrote:
I attempted to build cvs head but it died with the following error:

/usr/bin/ghc6 -H16m -O  -istage1/utils  -istage1/basicTypes  -istage1/types  -istage1/hsSyn  -istage1/prelude  -istage1/rename  -istage1/typecheck  -istage1/deSugar  -istage1/coreSyn  -istage1/specialise  -istage1/simplCore  -istage1/stranal  -istage1/stgSyn  -istage1/simplStg  -istage1/codeGen  -istage1/absCSyn  -istage1/main  -istage1/profiling  -istage1/parser  -istage1/cprAnalysis  -istage1/compMan  -istage1/ndpFlatten  -istage1/cbits  -istage1/iface  -istage1/nativeGen -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package concurrent -package posix -package util -recomp -Rghc-timing  -H16M '-#include hschooks.h'  -fno-warn-incomplete-patterns -fvia-C -Onot -fno-ignore-interface-pragmas  -c parser/Parser.hs -o stage1/parser/Parser.o  -ohi stage1/parser/Parser.hi

parser/Parser.hs:1878: Variable not in scope: `$'
[...]
You need a rather recent version of Happy from CVS to compile the HEAD.

Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ghc warnings messed up in 6.01

[Sven Panne]

John Meacham wrote:
[...] ;ghc -W -fglasgow-exts  Foo.hs
The current HEAD version (no idea about the release branch) of ghc correctly
says:
Foo.hs:1:
Warning: Module `List' is imported, but nothing from it is used
 (except perhaps instances visible in `List')
Foo.hs:7: Warning: Defined but not used: ds

[...] problem 1 is particularly bad, since a single unused toplevel could
cascade to generating a ton of warnings, all of which must be sorted
through to find the actual cause. [...]
This is your personal opinion and actually a matter of taste: I prefer the
new transitive way of issuing the warnings, otherwise you only get a
single warning about ds being unused, remove it, recompile, get the next
warning, etc. etc. With the new way you can simply remove everything which
appears in the unused foo warnings and you're done.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Transmitting Haskell values

[Sven Panne]

Simon Marlow wrote:
Generating a single unified index is entirely possible, given all the
.haddock files for the relevant packages.  I'll try to get this into the
next version of Haddock.
But only as an option and/or addition, I hope...

2. Remove the split between type/class index and 
function/constructor 
index in the Haddockish doc-index.html file.


Yes, this is also something I'd like to do.
Hmmm, I actually prefer the current situation: If you don't even know if you
should look for a type or a function, you probably have more trouble than
just two indices...  :-]
3. Some links in the indexes are bold, others aren't.


The bold ones represent the *original* defining module for the entity,
as compared to a module which just re-exports it.  However, knowing this
information isn't very useful, and arguably it shouldn't be displayed to
the user at all.  I'll change this for the next Haddock version.
Again, I like the current situation, it saves you the trouble to look into
simple collecting modulues (doing only imports and re-exports) by giving
the user a clue where the documentation is.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: None

[Sven Panne]

Arunkumar S Jadhav wrote:
[...] all is well now except that ghc is complaining about GL,
and GLU packages. Can't these packages be installed in one shot?
Hmmm, there are no GL and GLU packages: With `--enable-hopengl' you
get an OpenGL package (containing the GL/GLU API, there is no point
in distinguishing these parts IMHO) and a GLUT package. The latter
depends on the former, and both are auto packages, so even a plain
   ghc --make Hello.hs

should work for your setup. What is the output of:

   ghc-pkg -l
   ghc-pkg -s OpenGL
   ghc-pkg -s GLUT
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: HOpenGL :(

[Sven Panne]

Arunkumar S Jadhav wrote:
[...] When I do

$ ghc -package HOpenGL --make Hello.hs

I get the following error 

ghc-6.0.1: unknown package name: HOpenGL
HOpenGL consists of two packages: OpenGL and GLUT, and the latter implies
the former, so
   ghc -package GLUT --make Hello.hs

should work. To see which packages are installed, you can use

   ghc-pkg -l

Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: None

[Sven Panne]

Arunkumar S Jadhav wrote:
[...] which means neither HOpenGL, nor GLUT comes preinstalled in 
ghc-6.0.1 :(. Any solutions ??
It's a decision of the packager whether HOpenGL is supported or not
(you didn't write what binary package you use or if you built GHC for
yourself). If it's not there, you have to build GHC for yourself, adding
`--enable-hopengl' to configure's commandline.
There are activities to make installation of separate packages easy for
the end-user (see http://www.haskell.org/mailman/listinfo/libraries), so
problems like this should be easier to fix in the future.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Placement of OPTION pragmas

[Sven Panne]

Henrik Nilsson wrote:
But different people may have different opinions [...]
... and this is concisely stated in Wadler's Law of Language Design.
(http://www.informatik.uni-kiel.de/~mh/curry/listarchive/0017.html :-)
Seriously, I don't really care on what we agree here, it's only a minor
issue. My point is simply: Comments can (and usually *do*) lie, things
which are relevant to the compiler can not, so the truth should always
come first...
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Placement of OPTION pragmas

[Sven Panne]

Juanma Barranquero wrote:
OPTIONS pragmas are only looked for at the top of your source files,
upto the first (non-literate,non-empty) line not containing OPTIONS. 


Why doesn't non-empty include comment-only lines?

I usually start source files with the equivalent of:
[...]
and currently {-# OPTIONS ... #-} must be before the header...
... and I think it is fine that way, I would even be happy if it had
to be the very first line. OPTIONS can change the language (well, at
least in parts), so they should be placed in a prominent place. It
would be easy to change GHC's behaviour the way you asked for, but
this would make things hard for a *human* reader of the source code.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC build fails without alex

[Sven Panne]

Peter Simons wrote:
[...]
 | typecheck/TcSimplify.lhs:22:
 | Failed to load interface for `TcUnify':
 | Bad interface file: stage2/typecheck/TcUnify.hi-boot-6
 | stage2/typecheck/TcUnify.hi-boot-6:6: parse error on input `.'
 |
 | typecheck/TcSimplify.lhs:22:
 | Module `TcUnify' (hi-boot interface) does not export `unifyTauTy'
 | make[1]: *** [stage2/typecheck/TcSimplify.o] Error 1
 | make[1]: Leaving directory `/usr/local/src/ghc-current/ghc/compiler'
 | make: *** [stage2] Error 2
I performed a 'distclean', a 'cvs update', and tried it again -- same
problem. I'm compiling on Linux/x86 using GHC 5.04.3 and GCC 3.2.3.
Just update again...  :-)

Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: readline problem on OS X

[Sven Panne]

Shin-Cheng Mu wrote:
 [...] However, GHCi says:

   Loading package util ... linking ...
   /usr/local/lib/ghc-6.0/HSutil.o: unknown symbol
   `___stginit_SystemziConsoleziReadline_'
   ghc-6.0: panic! (the `impossible' happened, GHC version 6.0):
   can't load package `util'

 Anyone knows what the problem might be? [...]
Perhaps the package dependencies are not correct for the Mac build.
(Wolfgang?). Try adding -package readline to GHCi's commandline.
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users