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

2018-08-31 Thread 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

2018-08-31 Thread 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

2018-08-31 Thread 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

2018-03-09 Thread 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: [Haskell] PSA: `cabal update` command needs manual unsticking

2018-01-02 Thread 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...
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell


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

2018-01-02 Thread 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

2017-11-06 Thread 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

2017-11-05 Thread 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

2017-11-05 Thread 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: Remove eq and show from num class

2017-09-09 Thread Sven Panne
2017-09-08 10:43 GMT+02:00 Herbert Valerio Riedel :

> [...] Moreover, the CLC together with the Hackage Trustees also maintains
> the
> https://github.com/haskell/pvp specification which is integral to the
> way Hackage and the Cabal solver interact. [...]
>

Although I'm actively following quite a few Haskell-related mailing lists
and maintain various Haskell packages, this is the first time in my life
that I've heard of https://pvp.haskell.org/. It would be good to improve
communication about such central pieces of information... :-/ Don't get me
wrong: The page itself is great, as are other pages/repos/mailing lists,
but the overall organization of information leaves a lot to be desired IMHO.

Cheers,
   S.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


Re: Haskell 2020: 'let' to be optional and with wider scope of visibility, like other Haskell functions

2017-04-17 Thread Sven Panne
2017-04-17 14:19 GMT+02:00 Adam Bergmark :

> I just wanted to say that there is no need to apologize for making a
> proposal!
>

+1 for that, and sorry if I sounded harsh, that wasn't my intention.
Proposals are important (we need more of them, not less), and so are
discussions about them. Nothing would be worse than a dead language nobody
cares about...
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


Re: Haskell 2020: 'let' to be optional and with wider scope of visibility, like other Haskell functions

2017-04-16 Thread Sven Panne
2017-04-16 17:21 GMT+02:00 Vassil Ognyanov Keremidchiev :

> 1) It's not a problem, it's a improvement in syntax with lowering
> verbosity.
>

If it's not a real problem, it probably shouldn't be done: Every tiny
change in the syntax, even if it's somehow backwards compatible, has a high
cost in the whole ecosystem: The compiler has to be changed (probably by
far the easiest part), libraries for parsing/pretty-printing Haskell have
to be adapted, Editors/syntax highlighting rules have to be changed,
books/tutorials have to be rewritten and people have to be retrained (yes,
even if they don't use the new syntax: others might use it). To outweigh
this pain, there should be be a real gain, saving just 4 keystrokes isn't
worth it. And for me, and probably others, it's not an improvement in
syntax, it actually makes things worse by removing a syntactic cue.


> It's similar with the difference between Pascal and C syntax. One of the
> reasons we all love Haskell is because it's not so verbose.
>

I think it's actually not the non-verbosity which makes Haskell attractive,
it's its expressiveness. These are two quite different things.


> I have asked often why do-block is so different, than non-do-block.
>

Because it is fundamentally different from the rest, having a sequential
nature (for some meaning of "sequential" given by the underlying monad).


> Exchanging "x = foo" with "x <- foo" will result in error, so there is no
> problem that the difference is small.
>

Of course a machine will see the difference easily and immediately, the
question is: Will people do so, too?


> 2) you're right. May be lazyness could solve that? I'm not sure here.
>

So what are the desugaring rules for your proposal? I have the gut feeling
that they will be quite a bit more complicated and non-local than the
current ones. Remember the famous quote:

   "If you can't explain it to a six year old, you don't understand it
yourself."

;-)
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


Re: DeriveFoldable treatment of tuples is surprising

2017-03-22 Thread 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: Multiple imports on a single line

2017-02-01 Thread Sven Panne
2017-02-01 22:39 GMT+01:00 Vassil Ognyanov Keremidchiev :

> Yes, but it could be a bit more denser without so much repetition of
> "import", like:
>
> import Data.Text, qualified Data.Map as M, qualified Vector as V hiding
> (Vector)
>
> i.e. the same as current situation, but allow for multiple imports for the
> same word "import" comma separated. What do you think? The difference in
> syntax is not so much different, than just allowing commas.
>

I think this is worse than separate imports, each on a separate line. The
Python people have even put something like this into a PEP:
https://www.python.org/dev/peps/pep-0008/#imports This is for a very good
reason: The one-liners have very few visual hints for the reader to
comprehend it quickly. So even if Haskell allowed this comma-separated
chain of imports, code containing it probably wouldn't survive a code
review in most companies, where maintainability is the prime goal.

I often see a confusion between greater expresiveness (good goal) and
having to type less (largely irrelevant goal). By all means make the module
system more expressive, but try to avoid "clever" things for convenience.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


Re: Proposal process status

2016-07-21 Thread 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

2016-07-11 Thread 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

2016-07-08 Thread 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

2016-07-08 Thread 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

2016-07-08 Thread 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

2016-02-16 Thread 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

2016-02-14 Thread 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


Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP

2015-10-06 Thread Sven Panne
2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel :

> [...] That being said, as how to write your Monad instances today with GHC
> 7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This
> *does* work (admittedly for an easy example, but this can be
> generalised):
>
>
> --8<---cut here---start->8---
> module MyMaybe where
>
> import Control.Applicative (Applicative(..))
> import Prelude (Functor(..), Monad(..), (.))
> -- or alternatively: `import qualified Prelude as P`
> [...]
> --8<---cut here---end--->8---
>
> This example above compiles -Wall-clean and satisfies all your 3 stated
> requirements afaics. I do admit this probably not what you had in mind.
>

OK, so the trick is that you're effectively hiding Applicative from the
Prelude (which might be a no-op). This "works" somehow, but is not
satisfactory IMHO for several reasons:

   * If you explicitly import all entities from Prelude, your import list
will typically get *very* long and unreadable. Furthermore, if that's the
suggested technique, what's the point of having a Prelude at all?

   * Some people see qualified imports as the holy grail, but having to
prefix tons of things with "P." is IMHO very ugly. Things are even worse
for operators: The whole notion of operators in itself is totally useless
and superfluous *except* for a single reason: Readability. And exactly that
gets destroyed when you have to qualify them, so I would (sadly) prefer
some #ifdef hell, if that gives me readable code elsewhere.

   * With the current trend of moving things to the Prelude, I can envision
a not-so-distant future where the whole Control.Applicative module will be
deprecated. As it is now, it's mostly superfluous and/or contains only
stuff which might better live somewhere else.


> [...] That's because -Wall-hygiene (w/o opting out of harmless) warnings
> across multiple GHC versions is not considered a show-stopper.
>

That's your personal POV, I'm more leaning towards "-Wall -Werror". I've
seen too many projects where neglecting warning over an extended period of
time made fixing them basically impossible at the end. Anyway, I think that
a sane ecosystem should allow *both* POVs, the sloppy one and the strict
one.


> [...] Beyond what Ben already suggested in another post, there was also the
> more general suggestion to implicitly suppress warnings when you
> explicitly name an import. E.g.
>
>   import Control.Applicative (Applicative(..))
>
> would suppress the redundant-import warning for Applicative via Prelude,
> because we specifically requested Applicative, so we don't mind that
> Prelude re-exports the same symbol. [...]
>

Uh, oh... That would be bad, because one normally wants to see redundant
imports. Without the compiler telling me, how should I find out which are
redundant? Manually trying to remove them step by step? :-/

Cheers,
   S.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

2015-10-05 Thread Sven Panne
2015-10-05 17:09 GMT+02:00 Gershom B :

> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (b...@serpentine.com)
> wrote:
> [...] As for libraries, it has been pointed out, I believe, that without
> CPP one can write instances compatible with AMP, and also with AMP + MRP.
> One can also write code, sans CPP, compatible with pre- and post- AMP. [...]
>

Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is
now part of the Prelude, you can't simply import some compatibility module,
because GHC might tell you (rightfully) that that import is redundant,
because (<$>) is already visible through the Prelude. So you'll have to use
CPP to avoid that import on base >= 4.8, be it from it Data.Functor,
Control.Applicative or some compat-* module. And you'll have to use CPP in
each and every module using <$> then, unless I miss something obvious.
AFAICT all transitioning guides ignore -Wall and friends...
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

2015-10-05 Thread Sven Panne
2015-10-05 11:59 GMT+02:00 Simon Thompson :

> [...] It’s really interesting to have this discussion, which pulls in all
> sorts of well-made points about orthogonality, teaching, the evolution of
> the language and so on, but it simply goes to show that the process of
> evolving Haskell is profoundly broken. [...]
>

I wouldn't necessarily call the process "broken", but it's a bit annoying:
Because of the constant flux of minor changes in the language and the
libraries, I've reached the stage where I'm totally unable to tell if my
code will work for the whole GHC 7.x series. The only way I see is doing
heavy testing on Travis CI and littering the code with #ifdefs after
compilation failures. (BTW: Fun exercise: Try using (<>) and/or (<$>) in
conjunction with -Wall. Bonus points for keeping the #ifdefs centralized.
No clue how to do that...) This is less than satisfactory IMHO, and I would
really prefer some other mode for introducing such changes: Perhaps these
should be bundled and released e.g. every 2 years as Haskell2016,
Haskell2018, etc. This way some stuff which belongs together (AMP, FTP,
kicking out return, etc.) comes in slightly larger, but more sensible
chunks.

Don't get me wrong: Most of the proposed changes in itself are OK and
should be done, it's only the way they are introduced should be improved...
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


Typing pattern synonyms

2015-09-30 Thread 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

2015-09-30 Thread 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?

2015-09-17 Thread 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: [Haskell] ANNOUNCE: Haskell Platform 7.10.2

2015-07-31 Thread Sven Panne
[ re-posted with a link instead of an attachment, the mail size limit seems
to be a bit small on some lists... ]

2015-07-30 21:08 GMT+02:00 Mark Lentczner mark.lentcz...@gmail.com:

 Haskellers, we are pleased to announce the release of

 Haskell Platform 7.10.2
 *get it here... https://www.haskell.org/platform/*
 [...]


Nice! I've just tested things under Windows, and everything works for me so
far, only one tiny nit remains: In the documentation index
(file:///.../Haskell%20Platform/7.10.2/lib/extralibs/doc/index.html)
package names for the non-GHC packages are still missing in the right
column, see http://i.imgur.com/jh0u8EP.png. I'm not sure if this is a
glitch in the HP build or a bug in Cabal or a bug in Haddock or..., so I
don't know where to open an issue. Does anybody have a clue what might
cause this? If I build packages locally in a sandbox, their documentation
shows similar bugs. Is this working for other people or do they experience
the same behavior?

Nevertheless, great work!

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


Re: simultaneous ghc versions

2015-07-31 Thread 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

2015-07-24 Thread 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

2015-07-07 Thread 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

2015-07-07 Thread 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

2015-06-22 Thread 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

2015-05-06 Thread 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

2015-05-03 Thread 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

2015-01-25 Thread 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

2014-11-26 Thread 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

2014-04-28 Thread 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

2014-03-17 Thread 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: PROPOSAL: Literate haskell and module file names

2014-03-17 Thread 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.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell

2013-10-05 Thread Sven Panne
2013/9/27 Heinrich Apfelmus apfel...@quantentunnel.de:
 Actually, I'm reading about WebGL right now, and it appears to me that it
 should be very easy to support in Threepenny. [...]

I am not sure if WebGL is enough: WebGL is basically OpenGL ES 2.0,
which is again basically OpenGL 2.0 plus some extensions. OpenGL
itself is currently at 4.4, and the situation regarding the supported
shading language versions is even worse. In a nutshell: WebGL =
ancient OpenGL. If it's enough for your purposes, fine, but otherwise
I guess a lot of people want something more recent.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell

2013-10-05 Thread Sven Panne
2013/9/27 Conal Elliott co...@conal.net:
 [...] Am I mistaken about the current status? I.e., is there a solution for
 Haskell GUI  graphics programming that satisfies the properties I'm looking
 for (cross-platform, easily buildable, GHCi-friendly, and
 OpenGL-compatible)? [...]

Time warp! ;-) Point your browser at the g...@haskell.org archives a
decade ago... I think the consensus at that time was a bit
disappointing: Either one could have something portable but hard to
install and alien-looking, or something non-portable but easy to
install and native-looking. The fundamental UI concepts on the various
platforms differed so much that there was no hope for a grand unified
pretty UI library, so those GUI efforts basically ended. I think the
reasoning behind this hasn't changed recently, but I would love being
proven wrong.

Cheers,
   S.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Mystery of an Eq instance

2013-09-24 Thread Sven Panne
2013/9/22 Mike Meyer m...@mired.org:
 On Sat, Sep 21, 2013 at 5:28 PM, Bardur Arantsson s...@scientician.net
 wrote:
 Trying to make something whose name is Not A Number act like a
 number sounds broken from the start.

The point here is that IEEE floats are actually more something like a
Maybe Float, with various Nothings, i.e. the infinities and NaNs,
which all propagate in a well-defined way. Basically a monad built
into your CPU's FP unit. ;-)

 I just went back through the thread, and the only examples I could
 find where that happened (as opposed to where floating point
 calculations or literals resulted in unexpected values) was with
 NaNs. Just out of curiosity, do you know of any that don't involve
 NaNs?

Well, with IEEE arithmetic almost nothing you learned in school about
math holds anymore. Apart from rounding errors, NaNs and infinities,
-0 is another fun part:

   x * (-1)

is not the same as

   0 - x

(Hint: Try with x == 0 and use recip on the result.)

 Float violates the expected behavior of instances of - well, pretty
 much everything it's an instance of. Even if you restrict yourself to
 working with integer values that can be represented as floats.  If
 we're going to start removing it as an instance for violating instance
 expectations, we might as well take it out of the numeric stack (or
 the language) completely.

Exactly, and I am sure 99.999% of all people wouldn't like that
removal. Learn IEEE arithmetic, hate it, and deal with it. Or use
something different, which is probably several magnitudes slower. :-/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] ANNOUNCE: New OpenGL packages

2013-09-15 Thread Sven Panne
New versions of the OpenGL packages are available on Hackage:

   * OpenGLRaw 1.4.0.0
   * GLURaw 1.4.0.0
   * OpenGL 2.9.0.0
   * GLUT 2.5.0.0

The mid-term goal is to make all these packages conform to the latest
OpenGL 4.4 specification, and while we're not yet there, this release
is nevertheless an important stepping stone towards that goal. The
packages contain a few non-backwards compatible changes, something
which is never nice for a public API, but it has been necessary:
OpenGL has come a long way from its initial fixed function pipeline to
its current form flexible form centered around shaders and buffers.
Because of this, a few design decisions on the Haskell side were not a
good fit anymore and simply had to change. Nevertheless, almost all
changes needed in the applications and libraries using the OpenGL
packages should be mechanical and straightforward. If not:
hope...@haskell.org is the place to get help if needed.

Hopefully the new packages will make it into the next Haskell Platform
release (2013.4.0.0), at least if I find out how to make it through
the proposal process... ;-)

Cheers,
   S.

P.S.: Here a list of the changes for each package:

==
Changes in the OpenGLRaw package
==

* Added support for the following extensions:

 GL_ARB_occlusion_query2
 GL_ARB_timer_query
 GL_ARB_draw_indirect
 GL_ARB_gpu_shader5
 GL_ARB_tesselllation_shader
 GL_ARB_transform_feedback3
 GL_ARB_ES2_compatibility
 GL_ARB_get_program_binary
 GL_ARB_separate_shader_objects
 GL_ARB_shader_atomic_counters
 GL_ARB_compute_shader
 GL_ARB_ES3_compatibility
 GL_ARB_framebuffer_no_attachments
 GL_ARB_shader_storage_buffer_object
 GL_ARB_query_buffer_object

* Added GLfixed type from OpenGL 4.1.

* Moved GLhandle type to
Graphics.Rendering.OpenGL.Raw.ARB.ShaderObjects where it belongs and
fixed its representation on Mac OS X.

* Added new Graphics.Rendering.OpenGL.Raw.Type module which exports
all GL types. Core31 and Core32 export only their respective subset
now.

* Correctly typed bitfield tokens as, well, GLbitfield instead of GLenum.

* Consistently use ‘Ptr a’ for ‘void*’ which are not opaque.

* Use ccall instead of stdcall on x86_64-windows.

* Use the OpenGLES framework on iOS.

==
Changes in the GLURaw package
==

* Use ccall instead of stdcall on x86_64-windows.

* Use the OpenGLES framework on iOS.

==
Changes in the OpenGL package
==

* Added sync object support.

* Added full support for OpenGL 4.4 query objects, extending and
changing the previous query object API a bit.

* Split ObjectName class into ObjectName + GeneratableObjectName
classes. Added single-name variants deleteObjectName and
genObjectName, they are a very common use case.

* Made BufferObject and TextureObject abstract. Now all GL objects
names are abstract and have to be explicitly generated. The only
exception is DisplayList, which is required to be non-abstract by the
spec.

* Shader is not a class anymore, but a data type with an ObjectName
instance and a creation action. Added ShaderType and shaderType.

* Added partial support for tessellation/geometry/compute shaders.

* Program is not a GeneratableObjectName, but has a createProgram
action now. Added attachShader and detachShader for incremental
changes.

* Deprecated shaderSource and added shaderSourceBS instead. Using
ByteString is more efficient and forces the caller to think about
encodings, e.g. via Data.Text.Encoding.

* Added support for shader/program binaries and shader precision queries.

* Revamped texture targets, adding partial support for texture buffer
objects and texture arrays.

* OpenGL 3.1 deprecated separate polygon draw modes, so use
GL_FRONT_AND_BACK internally in polygonMode whenever possible.

* Added missing Eq/Ord/Show instances for lots of data types.

* Simplified TransformFeedbackVaryings API, making it a bit more
similar to the one for activeAttribs and activeUniforms.

* Exported ContextProfile’.

* Renamed BlitFramebufferMask (to BlitBuffer) and its constructors.

* Renamed BufferRangeAccessBit (to MapBufferUsage) and its constructors

* Removed currentMatrix, genLists, deleteLists and isList, they have
been deprecated for ages.

* Full internal support for UTF-8.

* Do not expose internal #hidden modules.

* Lots of Haddock fixes and improvements.

* Renamed IndexedTransformFeedbackBuffer to IndexedTransformFeedbackBuffer.

* Fixed clip plane query.

==
Changes in the GLUT package

Re: [Haskell-cafe] Renumbered mailing list posts

2013-08-12 Thread Sven Panne
2013/8/12 Joachim Breitner m...@joachim-breitner.de:
 happens with mailman/pipermail occasionally.

o_O That's news to me... Why/how does this happen? This sounds like a
serious bug to me, the URLs should really, really be stable to be of
any use.

  It is more reliable to link to message ids, e.g. via gmame: [...]

That hint doesn't really help to unbreak the Haskell wiki, the various
trac instances, my mailbox, etc. :-(

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell] ANNOUNCE: OpenGLRaw 1.1.0.1

2009-10-11 Thread Sven Panne
A new version of the OpenGLRaw package has been uploaded to Hackage. This is a 
bug-fix-only release, fixing the retrieval of core OpenGL API entries on  
Windows. This fix should have already been included in the previous 1.1.0.0 
version, but it was accidentally left out (thanks to Tobias Bexelius for 
pointing this out).

Cheers,
   S.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell] ANNOUNCE: GLUT 2.2.2.0

2009-09-13 Thread Sven Panne
A new version of the GLUT package has been uploaded to Hackage.

   * Fixed linking issues on Mac OS X, the package should work out of the box 
without any warnings or additional flags now.

   * Handle additional mouse buttons via 'AdditionalButton Int' in the 
MouseButton type.

   * Made a few minor typing adjustments, which don't really matter for the 
type synonyms used for the basic OpenGL types so far, but which do matter for 
the upcoming datatype renamings for them.

   * Aesthetic improvements in the brick shader example.

Cheers,
   S.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell] ANNOUNCE: GLURaw 1.1.0.0

2009-09-13 Thread Sven Panne
A new version of the GLURaw package has been uploaded to Hackage.

   * Fixed linking issues on Mac OS X, the package should work out of the box 
without any warnings or additional flags now.

  * Fixed the type of gluUnProject4, the near and far parameters are of type 
GLclampd, not GLdouble. This matches the GLU spec.

Cheers,
   S.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell] ANNOUNCE: OpenGLRaw 1.1.0.0

2009-09-13 Thread Sven Panne
A new version of the OpenGLRaw package has been uploaded to Hackage.

  * Use opaque newtypes for the basic OpenGL types, adding the common 
instances for them, too. Note that this might break programs which depend on 
the concrete representations. Use explicit conversions where necessary, making 
all assumptions explicit.

   * Fixed linking issues on Mac OS X, the package should work out of the box 
without any warnings or additional flags now.

   * Fall back to GetProcAddress on Windows when WGL doesn't find an API 
entry. This should fix problems using core functions with some driver/OS 
combinations.

   * Added support for OpenGL 3.2 and the latest NV extensions.

   * All extensions export all their functions/tokens/types, even if they are 
in the core. This will keep the extension module exports more stable.

  * Fixed the types of the glPixelMap functions, using GLsizei instead of 
GLint for the size, following the OpenGL specification.

Cheers,
   S.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell] ANNOUNCE: OpenGL 2.4.0.0

2009-09-13 Thread Sven Panne
A new version of the OpenGL package has bee uploaded to Hackage.

   * Added contextProfile query.

   * Made a few tiny internal typing changes to make things work with the 
latest OpenGLRaw package.

Cheers,
   S.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell] ANNOUNCE: OpenGL 2.4.0.1

2009-09-13 Thread Sven Panne
A new version of the OpenGL package has been uploaded to Hackage.

   * Fixed maxTextureUnit query. This change didn't make it in the last 
release... :-(

Cheers,
   S.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell-cafe] Re: [Haskell] ANNOUNCE: GLUT 2.2.1.0

2009-08-17 Thread Sven Panne
Am Sonntag, 16. August 2009 22:10:23 schrieb Rafael Gustavo da Cunha Pereira 
Pinto:
 BTW, as an enhancement for 2.2.2.0, you could treat unnamed mouse buttons.
 Mouses with more axis and more buttons are becoming increasingly common,
 and unmarshalMouseButton is not prepared to accept them!!

 Here are exceptions I caught, playing with my Genius Traveler 515 mouse:

 unmarshalMouseButton: illegal value 5
 unmarshalMouseButton: illegal value 6
 unmarshalMouseButton: illegal value 7
 unmarshalMouseButton: illegal value 8

Good point, I had similar reports already, but I simply forgot to handle this 
in yesterday's release. The right way to handle this would probably be 
extending the MouseButton data type with an 'AdditionalButton Int' constructor 
and simply pass the unknown button numbers via this case. I am not so sure 
about a nice name for this constructor: AdditionalButton? GenericButton? Or 
simply MouseButton, just like the type itself?

Cheers,
   S.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell] ANNOUNCE: GLUT 2.2.1.0

2009-08-16 Thread Sven Panne
A new version of the GLUT package has been uploaded to Hackage.

 * The package is now autoconf-free. API entries are resolved dynamically at 
runtime, just like the OpenGLRaw and GLURaw packages.

 * Support for sRGB framebuffers has been added, just use SRGBMode with 
initialDisplayMode. To use this functionality, you need the upcoming freeglut 
2.6.0 library, older versions and classic GLUT do not support this feature.

 * Support for context profiles has been added via initialContextProfile. 
Again, this works with the upcoming freeglut 2.6.0 library only.

Cheers,
   S.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell] ANNOUNCE: GLUT 2.2.0.0

2009-07-29 Thread Sven Panne
A new version of the GLUT package has been uploaded to Hackage. It depends on 
the new OpenGL, StateVar and Tensor packages, but apart from that the API is 
unchanged. Furthermore, a simple, pure OpenGL 3.1 demo has been added, which 
does not rely on any deprecated OpenGL functionality (SmoothOpenGL3).

Cheers,
   S.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell] ANNOUNCE: StateVar 1.0.0.0

2009-07-14 Thread Sven Panne
To further modularize the OpenGL/OpenAL packages, a new StateVar package has 
been released to Hackage. It contains state variables, which are references in 
the IO monad, like IORefs or parts of the OpenGL state.

Cheers,
   S.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell] ANNOUNCE: ObjectName 1.0.0.0

2009-07-14 Thread Sven Panne
A new (tiny) ObjectName package has been released to Hackage. It contains the 
class ObjectName, which corresponds to the general notion of explicitly 
handled identifiers for API objects, e.g. a texture object name in OpenGL or a 
buffer object name in OpenAL.

Cheers,
   S.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell] ANNOUNCE: OpenGLRaw 1.0.1.0

2009-07-14 Thread Sven Panne
A new version of the OpenGLRaw package has been uploaded to Hackage. Support 
for the following OpenGL extensions has been added:

   GL_NV_texture_shader2
   GL_NV_depth_clamp
   GL_NV_primitive_restart
   GL_NV_vertex_array_range2
   GL_NV_occlusion_query
   GL_NV_fence
   GL_NV_light_max_exponent
   GL_NV_texture_env_combine4
   GL_NV_fog_distance
   GL_NV_register_combiners2
   GL_NV_register_combiners
   GL_NV_light_max_exponent
   GL_NV_multisample_filter_hint
   GL_NV_texture_shader
   GL_NV_vertex_array_range
   GL_NV_texgen_emboss
   GL_NV_copy_depth_to_color

Cheers,
   S.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell] ANNOUNCE: GLURaw 1.0.0.0

2009-07-14 Thread Sven Panne
A new GLURaw package has been uploaded to Hackage. It contains full support 
for all GLU functionality and is similar in spirit to the OpenGLRaw package, 
i.e. it is a 1:1 mapping of the C interface, no libraries or headers are 
needed at build time, and the GLU API entries are resolved dynamically at 
runtime.

Cheers,
   S.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0

2009-06-12 Thread Sven Panne
Am Donnerstag, 11. Juni 2009 19:23:17 schrieb Bryan O'Sullivan:
 Since this is a new package, is there any possibility that the naming could
 be more economical?

 Graphics.Rendering.OpenGL.GL.CoordTrans is awfully long.

 I think that Graphics.Rendering. is clutter, and OpenGL.GL. seems
 redundant to me. I'd very much like to encourage the idea that tremendously
 long package names ought to be considered poor form.

While I consider this a bit long, too, there are a few reasons why it was done 
this way. The OpenGLRaw package exports 1025 functions, 1673 tokens and 20 
types, so one clearly needs some way of structuring this, the only question is 
how.

You rarely import on such a fine-grained level, most of the time you simply 
use the rather short

   import Graphics.Rendering.OpenGL

import, where you can even add as GL if you like for short explicit 
qualification later. Another example: If you explicitly only want to use pure, 
modern OpenGL 3.1 the raw way, use:

   import Graphics.Rendering.OpenGL.Raw.Core31

If you additionally want to use the ARB_compatibility extension, use:

   import Graphics.Rendering.OpenGL.Raw.Core31
   import Graphics.Rendering.OpenGL.Raw.ARB.Compatibility

If you want the OpenGL 3.1 core plus all ARB extensions, use

   import Graphics.Rendering.OpenGL.Raw.Core31
   import Graphics.Rendering.OpenGL.Raw.ARB

And if you are very lazy, you can simply pull in the whole raw binding with

   import Graphics.Rendering.OpenGL.Raw

This leaves the decision about the granularity of the import to the user of 
the package, which is a good thing IMHO. The .Raw part is necessary to 
distinguish between the raw and the nice interface, leaving the dot out or 
replacing it with _ wouldn't really buy us much.

One point here is debatable: Do we really need the .Rendering part in the 
package name or would simply Graphics.OpenGL.Raw be enough? We discussed the 
structure of the hierarchy when hierarchical packages were in their infancy, 
many years ago, and it was consensus then to distinguish between 
Graphics.Rendering and Graphics.UI. I don't have very strong feelings 
about .Rendering and .UI, and if the consensus nowadays is to remove it, 
I'll be happy to change this. But let's move the discussion about this to the 
libraries mailing list.

A few final remarks: Leaving out Graphics. completely would be a very bad 
idea, the naming hierarchy should reflect the underlying conceptual hierarchy. 
The only problem with hierarchies in general is that sometimes the position in 
it is not very clear. I have e.g. never fully understood why Monad and 
Applicative are below Control, but Foldable is below Data...

Cheers,
   S.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0

2009-06-12 Thread Sven Panne
Am Donnerstag, 11. Juni 2009 19:23:17 schrieb Bryan O'Sullivan:
 [...] I think that Graphics.Rendering. is clutter, and OpenGL.GL. seems
 redundant to me. [...]

I forgot to mention one thing here: OpenGL.GL is currently *not* redundant, 
there is OpenGL.GLU in the OpenGL package, too. GL and GLU are separate 
libraries, even living in separate DLLs/*.sos, having separate headers, etc., 
so they should be kept separate in Haskell at some level, too.

Nevertheless, with OpenGL 3.1 GLU is dead, anyway, so in future versions there 
will be no .GL part in the package names.

Cheers,
   S.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0

2009-06-11 Thread Sven Panne
As a first step to make the OpenGL package easier to install, more modular and 
a bit more flexible, a low-level binding for OpenGL has been uploaded to 
Hackage. From OpenGLRaw's package description:


OpenGLRaw is a raw Haskell binding for the OpenGL 3.1 graphics system and lots 
of OpenGL extensions. It is basically a 1:1 mapping of OpenGL's C API, 
intended as a basis for a nicer interface. OpenGLRaw offers access to all 
necessary functions, tokens and types plus a general facility for loading 
extension entries. The module hierarchy closely mirrors the naming structure 
of the OpenGL extensions, making it easy to find the right module to import. 
All API entries are loaded dynamically, so no special C header files are 
needed for building this package. If an API entry is not found at runtime, a 
userError is thrown.

OpenGL is the industry's most widely used and supported 2D and 3D graphics 
application programming interface (API), incorporating a broad set of 
rendering, texture mapping, special effects, and other powerful visualization 
functions. For more information about OpenGL and its various extensions, 
please see http://www.opengl.org/ and http://www.opengl.org/registry/.


Version 1.0.0.0 covers the OpenGL 3.1 core, all ARB extensions and all EXT 
extensions. Great care has been taken to introduce as few build dependencies 
as possible, so neither autoconf is required, nor any OpenGL headers. Future 
versions of the OpenGL package will basically be a convenience layer above 
this package, but you can always fall back to the raw binding if required. To 
get a taste for it, have a look at http://aedion.de/haskell/SmoothRaw.hs, 
which should look extremely familiar to anyone who has used OpenGL's C API.

Any feedback is highly appreciated.

Cheers,
   S.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


Re: [HOpenGL] renderString not working in ghci

2009-06-01 Thread Sven Panne
[ Reprise of an old GHCi problem, GHC HQ read on please... ]

Am Mittwoch, 20. Mai 2009 09:24:14 schrieb Matthijs Kooijman:
 I've been playing around with GLUT (latest version from hackage, on Debian)
 a bit yesterday and am having some troubles with renderString. It works
 fine when I compile a binary using ghc, but when running from ghci I get an
 error similar to the following (I don't have the actual error at hand atm).

 freeglut(interactive): font 0xsomething not found

 From looking at the freeglut code, it seems this means that the font
 pointer passed in does not match the address of any of the font variables
 in the library. I'm not completely sure how the linking works in ghci, but
 it appears that something goes wrong with dynamic linking?

 Is this a known problem, or does anyone have any pointers where to debug
 this?

After thinking about this for a while, I got a déjà vu feeling and browsed 
through old mails, and there it was, the thread about the arcane, dark corners 
of dynamic linking and position independent code, where (almost) no man has 
gone before: ;-)

   http://www.haskell.org/pipermail/cvs-ghc/2007-September/038458.html

I think that we finally came to the conclusion that we *have* to compile code 
with -fPIC on some platforms, including x86_64, but looking at the verbose 
output of the build step of the GLUT package on x86_64, one can see that there 
is nothing PIC-related at all. Adding --ghc-option=-fPIC to Cabal's build 
step for the GLUT package makes ARBOcclude.hs (and renderString in general) 
work again.

So my questing is: Is this a bug in GHC, i.e. should it always use -fPIC 
implicitly? Or is this a bug in my GLUT package's .cabal file? I have a 
tendency to believe the former possibility... Or asked the other way round: Is 
there a reason why -fPIC is not the default for GHC?

Cheers,
   S.

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


Re: [HOpenGL] renderString not working in ghci

2009-06-01 Thread Sven Panne
Am Montag, 1. Juni 2009 22:48:56 schrieb Duncan Coutts:
 I don't know how the problem reported in that message is related to the
 renderString problem (which I do not understand), but the behaviour you
 see there is not terribly surprising. It's an artefact of the way
 dynamic linking works and should not generally cause any problems.

The word generally is a problem in itself. ;-) The main point is that GHCi'l 
dynamic linker behaves differently from the system's dynamic linker, so this 
is a very good reason to consider this a bug. It might not surface very often, 
but it is nevertheless a different behaviour a.k.a. bug.

 The only case where it should make a difference is if code is assigning
 any meaning to the address of functions, eg to compare them for
 identity. In that case going via a thunk will make a difference. Is that
 what freeglut is doing do you think?

It is not about the address of functions, it is about data addresses. Here is 
the relevant snippet from GLUT's/freeglut's header file for non-Windows 
platforms:

--
/*
 * I don't really know if it's a good idea... But here it goes:
 */
extern void* glutStrokeRoman;
extern void* glutStrokeMonoRoman;
extern void* glutBitmap9By15;
   ...

/*
 * Those pointers will be used by following definitions:
 */
#   define  GLUT_STROKE_ROMAN   ((void *) glutStrokeRoman)
#   define  GLUT_STROKE_MONO_ROMAN  ((void *) glutStrokeMonoRoman)
#   define  GLUT_BITMAP_9_BY_15 ((void *) glutBitmap9By15)
...
--

As you can see, GLUT's fonts are represented by the addresses of global 
variables. This might not be the nicest way to do this, but it has to be done 
for binary compatibility reasons and there is *nothing* dubious about this. 
Note that e.g. we are very lucky that errno is a macro for a function call 
on all platforms for which -fPIC is relevant, otherwise we would have the same 
problem with it, too.

The GLUT Haskell package uses a simple C wrapper around these macros:

--
void*
hs_GLUT_marshalBitmapFont(int fontID)
{
  switch (fontID) {
  case 0 : return GLUT_BITMAP_8_BY_13;
  case 1 : return GLUT_BITMAP_9_BY_15;
  case 2 : return GLUT_BITMAP_TIMES_ROMAN_10;
  case 3 : return GLUT_BITMAP_TIMES_ROMAN_24;
  case 4 : return GLUT_BITMAP_HELVETICA_10;
  case 5 : return GLUT_BITMAP_HELVETICA_12;
  case 6 : return GLUT_BITMAP_HELVETICA_18;
  }
  return (void*)0;
}
--

For reasons explained in great length in the mail thread quoted, GHCi's linker 
doesn't link the wrapper correctly on some platforms when -fPIC is not used 
for its compilation.

 I rather suspect it's freeglut doing something dubious with comparing
 function pointers.

The only one doing dubious things is GHCi's dynamic linker... ;-)

 On most platforms -fPIC imposes some overhead and so it is only used
 when it's advantageous or necessary. On most platforms code that will
 live in a shared library should or must be compiled with -fPIC. x86-64
 is one of the few architectures where the overhead is relatively low.

So my question is again: Why is -fPIC not the default for GHC on x86_64? If we 
don't want the overhead, that's OK (any benchmark numbers?), but then GHC's 
documentation should really contain a big, fat warning that GHCi's dynamic 
linker gets cases like the one above wrong.

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


Re: [Haskell-cafe] Data.Binary and little endian encoding

2009-05-18 Thread Sven Panne
Am Sonntag, 17. Mai 2009 15:08:29 schrieb Don Stewart:
 Sven.Panne:
  [...]
  I think most problems can be fixed in a rather pragmatic way by adding a
  few functions to the binary package:
 [...]
 Patches are welcome.

Attached. A few remarks:

 * This is only a quick and mildly tested implementation of the IEEE 
functions, especially NaNs, infinities and denormalized numbers are untested. 
These problems could totally be avoided if we can coerce representations 
directly, changing only their interpretation.

 * The *host functions assume an IEEE platform, but this can easily be changed 
(see comments).

 * Perhaps one can use unsafeCoerce for word32ToFloat and friends, but I 
haven't checked this.

 * I've seen a few {- INLINE -} comments. Is this really wanted or only a 
typo?

 * A comment about using peek/poke for the *le/*be functions is wrong, because 
this would introduce alignment constraints on some platforms.

I think the main point is to provide a nice and efficient API, hiding all the 
dirty stuff in the implementation.

  One final remarks: I think the low level functions of the binary package
  should really keep the notions of endianess and alignment constraints
  separate, something which isn't done currently: The *host functions have
  alignment restrictions, the *be/*le functions don't. There is no good
  reason for this non-orthogonality.

 That seems reasonable.

There are various ways to achieve this, but the most obvious way leads to a 
combinatorial explosion of functions:

   no. of types * 3 (LE/BE/host) * 2 (aligned/unaligned)

Furthermore, it would be good to split the binary package into the 2 layers 
already discussed first, then it is perhaps a bit clearer what a nice API 
would look like. I think it would be best to shift this API design discussion 
to the libraries list.

Cheers,
   S.

Only in binary-0.5.0.1: dist
diff -r -u binary-0.5.0.1.orig/src/Data/Binary/Builder.hs binary-0.5.0.1/src/Data/Binary/Builder.hs
--- binary-0.5.0.1.orig/src/Data/Binary/Builder.hs	Sat Mar  7 23:59:44 2009
+++ binary-0.5.0.1/src/Data/Binary/Builder.hs	Mon May 18 17:36:22 2009
@@ -41,20 +41,27 @@
 , putWord16be   -- :: Word16 - Builder
 , putWord32be   -- :: Word32 - Builder
 , putWord64be   -- :: Word64 - Builder
+, putFloatIEEEbe-- :: Float - Builder
+, putDoubleIEEEbe   -- :: Double - Builder
 
 -- ** Little-endian writes
 , putWord16le   -- :: Word16 - Builder
 , putWord32le   -- :: Word32 - Builder
 , putWord64le   -- :: Word64 - Builder
+, putFloatIEEEle-- :: Float - Builder
+, putDoubleIEEEle   -- :: Double - Builder
 
 -- ** Host-endian, unaligned writes
 , putWordhost   -- :: Word - Builder
 , putWord16host -- :: Word16 - Builder
 , putWord32host -- :: Word32 - Builder
 , putWord64host -- :: Word64 - Builder
+, putFloatIEEEhost  -- :: Float - Builder
+, putDoubleIEEEhost -- :: Double - Builder
 
   ) where
 
+import Prelude hiding (significand, exponent)
 import Foreign
 import Data.Monoid
 import Data.Word
@@ -360,6 +367,60 @@
 -- on a little endian machine:
 -- putWord64le w64 = writeN 8 (\p - poke (castPtr p) w64)
 
+-- | Write a Float in IEEE big endian format
+putFloatIEEEbe :: Float - Builder
+putFloatIEEEbe = putWord32be . floatToWord32
+{-# INLINE putFloatIEEEbe #-}
+
+-- | Write a Double in IEEE big endian format
+putDoubleIEEEbe :: Double - Builder
+putDoubleIEEEbe = putWord64be . doubleToWord64
+{-# INLINE putDoubleIEEEbe #-}
+
+-- | Write a Float in IEEE little endian format
+putFloatIEEEle :: Float - Builder
+putFloatIEEEle = putWord32le . floatToWord32
+{-# INLINE putFloatIEEEle #-}
+
+-- | Write a Double in IEEE little endian format
+putDoubleIEEEle :: Double - Builder
+putDoubleIEEEle = putWord64le . doubleToWord64
+{-# INLINE putDoubleIEEEle #-}
+
+floatToWord32 :: Float - Word32
+-- floatToWord32 = unsafeReinterpret
+floatToWord32 = encodeIEEE 8 23
+
+doubleToWord64 :: Double - Word64
+-- doubleToWord64 = unsafeReinterpret
+doubleToWord64 = encodeIEEE 11 52
+
+-- TODO: Check if this works for denormalized numbers, NaNs and infinities.
+encodeIEEE :: (RealFloat a, Bits b, Integral b) = Int - Int - a - b
+encodeIEEE exponentBits significandBits f =
+  (signBit `shiftL` (exponentBits + significandBits)) .|.
+  (exponentField `shiftL` significandBits) .|.
+  significandField
+   where (significand, exponent) = decodeFloat f
+
+ signBit | significand  0 = 1
+ | otherwise = 0
+ exponentField | significand == 0  exponent == 0 = 0
+   | otherwise = fromIntegral exponent + exponentBias + fromIntegral significandBits
+ significandField = fromIntegral (abs significand) .. significandMask
+
+ exponentBias = bit (exponentBits - 1) - 1
+ significandMask = bit significandBits - 1
+
+{-
+-- Evil! Poor man's version 

Re: [Haskell-cafe] Linkage errors in scenegraph

2009-05-17 Thread Sven Panne
Am Sonntag, 17. Mai 2009 01:07:55 schrieb Gregory D. Weber:
 I'd like to get the scenegraph package
 (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/scenegraph)
 to work, but am encountering linkage errors.
 [...]
 Also, I notice that in the cabal file for scenegraph, the
 list of exposed modules

 Exposed-Modules: Graphics.SceneGraph,
   Graphics.SceneGraph.Basic,
 Graphics.SceneGraph.Vector,
 Graphics.SceneGraph.Render,
 Graphics.SceneGraph.SimpleViewport,
   Graphics.SceneGraph.GraphViz,
 Graphics.SceneGraph.Library,
 Graphics.SceneGraph.Dump,
 Graphics.SceneGraph.Textures

 does not include Graphics.SceneGraph.Matrix, but that should only mean
 that I can't call functions of that module directly -- not that the
 other SceneGraph modules can't call them -- right? [...]

That basically means that the scenegraph package is broken. ;-) Internal 
modules have to be listed in other-modules:, a section the Cabal file 
doesn't contain. As a quick fix, you can add all missing modules in this 
section, but this should of course be fixed in the official package, too.

http://www.haskell.org/cabal/release/cabal-latest/doc/users-
guide/authors.html#buildinfo

Cheers,
   S.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Data.Binary and little endian encoding

2009-05-17 Thread Sven Panne
Am Freitag, 15. Mai 2009 06:37:22 schrieb Don Stewart:
 timd:
  On a related matter, I am using Data.Binary to serialise data from
  haskell for use from other languages. [...]
 [...]
 Yep, it's possible, just not portably so. Google for Data.Binary IEEE
 discussions.

I think this topic pops up over and over again, and the proposed solutions 
are no solutions at all, neither from a performance point of view, nor from an 
ease of use point of view. Proposing insane bit fiddling by hand when all one 
technically needs is often a peek or poke amounts to simply ignoring an 
API problem. ;-)

I think most problems can be fixed in a rather pragmatic way by adding a few 
functions to the binary package:

Add to Data.Binary.Builder:

   putFloatIEEEbe :: Float - Builder
   putDoubleIEEEbe :: Double - Builder
   putFloatIEEEle :: Float - Builder
   putDoubleIEEEle :: Double - Builder
   putFloatIEEEhost :: Float - Builder
   putDoubleIEEEhost :: Double - Builder

Add to Data.Binary.Get:

   getFloatIEEEbe :: Get Float
   getDoubleIEEEbe :: Get Double
   getFloatIEEEle :: Get Float
   getDoubleIEEEle :: Get Double
   getFloatIEEEhost :: Get Float
   getDoubleIEEEhost :: Get Double

Add to Data.Binary.Put:

   putFloatIEEEbe ::  Float - Put
   putDoubleIEEEbe ::  Double - Put
   putFloatIEEEle ::  Float - Put
   putDoubleIEEEle ::  Double - Put
   putFloatIEEEhost ::  Float - Put
   putDoubleIEEEhost ::  Double - Put

The *host functions are basically peek/poke for most platforms. The *le/*be 
functions can use peek/poke if the endianess matches (compile time decision) 
*and* the alignment is OK for the given platform (runtime decision). Non-IEEE 
platforms always have to do the bit fiddling internally, but all this is 
hidden behind the above API.

IIRC I have proposed something similar 1-2 years ago, but I can't remember any 
reason why this hasn't been implemented. Any comments on the above functions?

One final remarks: I think the low level functions of the binary package 
should really keep the notions of endianess and alignment constraints 
separate, something which isn't done currently: The *host functions have 
alignment restrictions, the *be/*le functions don't. There is no good reason 
for this non-orthogonality.

Cheers,
   S.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell] ANNOUNCE: OpenGL 2.2.3.0

2009-05-16 Thread Sven Panne
A new version of the OpenGL package has bee uploaded to Hackage. This is 
a feature release, containing the following changes and additions:

  * Added support for GL_ARB_copy_buffer, GL_ARB_depth_buffer_float, 
GL_ARB_half_float_pixel, GL_ARB_texture_rectangle, GL_EXT_packed_float and 
GL_EXT_texture_shared_exponent extensions.

  * Added missing parts of GL_ARB_vertex_shader extension.

  * Announce that we support MESA_ycbcr_texture and APPLE_ycbcr_422 
extensions.

  * Improved generic vertex attribute array API.

  * Added support for unsigned integral uniforms.

  * Added more GLSL type tokens.

  * Added missing query for texture size limits.

  * Include missing aclocal.m4 and README in source distribution and removed 
unused Makefiles and prologue.txt.

  * Added 2 hacks to determine the Haskell equivalents of 
GLchar/GLintptr/GLsizeiptr with ancient GL headers.

  * Added Vector1, Vector4 and Vertex1 data types for orthogonality.

  * Added Functor, Applicative, Foldable , Traversable, Typeable and Typeable1 
instances for all vertex attributes plus all possible derivable instances.

Cheers,
   S.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


Re: [Haskell-cafe] Decoupling OpenAL/ALUT packages from OpenGL

2009-05-16 Thread Sven Panne
Am Montag, 11. Mai 2009 12:04:07 schrieb Neil Brown:
 [...] So possible additions to your type-class list are Foldable and maybe
 Traversable (no harm, although I'd have to reach further for an example
 for this).  I guess the tricky decision might be whether to provide a
 Num instance  (again, probably more suitable for Vector2)? [...]

OK, I've added a bunch of instances for all vertex attribute types in the 
OpenGL 2.2.3.0 package. Let me know if there are standard classes for which 
you would like to see instances, too.

I've deliberately omitted instances for Num, because they are not correct from 
a mathematical point of view: You can't e.g. add two points (only a point and 
a vector), the difference between two points is not a point (it's a vector), 
etc.

Cheers,
   S.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Decoupling OpenAL/ALUT packages from OpenGL

2009-05-10 Thread Sven Panne
Am Montag, 4. Mai 2009 13:33:33 schrieb David Duke:
 Decoupling basic primitives for geometric modelling from OpenGL would be
 useful. [...]
 Even just data constructors and instances of these within Functor and
 Applicative are a useful starting point. [...]

I've taken a closer look at the available packages for vector math/linear 
algebra. They differ in a lot of respects, starting from their representations 
of vectors and matrices, use of the type system and its extensions, 
strictness, structure of their type classes, etc.

This leads me to the conclusion that I should only lift the data types for 
vectors and matrices out of the OpenGL package, including only instances for 
standard type classes like Eq, Ord, Functor, etc. This means that the new 
package will *not* include type classes for things like scalars, vector 
spaces, etc. These can be defined by the other packages in their own type 
class language. I really fail to see a common ground in this respect, even 
for basic things: Keeping things H98-compliant is a must for me, so putting 
things like fundeps or associated types in this new package is a no-go for me. 
Nevertheless, having a common set of (strict) data types for vector math will 
probably be very useful, even if it won't fulfill everybody's needs.

What standard instances should be defined for those vectors and matrices? 
Things coming to mind are Eq, Ord, Show, Storable, Typeable1, Functor and 
Applicative. Have I missed some type classes?

Regarding Functor/Applicative: The obvious instances for e.g. a 2-dimensional 
vertex are:

   data Vertex2 a = Vertex2 a a

   instance Functor Vertex2 where
  fmap f (Vertex2 x y) = Vertex2 (f x) (f y)

   instance Applicative Vertex2 where
  pure a = Vertex2 a a
  Vertex2 f g * Vertex2 x y = Vertex2 (f x) (g y)

They fulfill all required laws, but are these the only possible instances? If 
not, are they at least the most canonical ones in a given sense? And 
finally: Does somebody have a real-world example where the Applicative 
instance is useful? Usages of the Functor instance are much more obvious for 
me.

Cheers,
   S.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Decoupling OpenAL/ALUT packages from OpenGL

2009-05-03 Thread Sven Panne
Am Sonntag, 3. Mai 2009 00:56:00 schrieb Tillmann Vogt:
 Sven Panne schrieb:
 * a tiny ObjectName package, consisting only of OpenGL's ObjectName
  class (In Data.ObjectName? I'm not very sure about a good place in the
  hierarchy here.)

 How about Data.GraphicsObjects ? [...]

Thanks for all the suggestions so far, a few remarks from my side (I just 
picked the last mail for the reply, no strong reason for this...):

Data.GraphicsObjects is a bit misleading, because OpenAL's Buffers and 
Sources are instances, too, and they have nothing to do with graphics. 
Instances of ObjectName are just opaque resources from an external API, which 
you have to allocate and deallocate explicitly.

 I think it would be nice to have data types and functions for dot
 produkt, scalar product, norms, ...
 together with HOpenGL types.

I fear that this might open a can of worms and could lead to even longer 
discussions than the ones about a collection framework. The design space for a 
vector math package is quite large, and I fear that e.g. a mathematician 
trying to implement some linear algebra package has vastly different 
requirements than somebody trying to implement the n-th incarnation of the 
Quake engine. Some points to consider:

   * Should the components of vectors etc. be strict? In OpenGL they are, and 
Data.Complex is similar in this respect. In my experience non-strict 
components lead to space leaks too easily, and I guess this is the rationale 
behind Complex, too. But non-strict components have some benefits, too, of 
course, especially if you do symbolic computation.

   * Should we abstract over the number of dimension of vectors, etc.? If yes, 
how strong can our compile-time type checking be?

   * If we really make this a more general vector math package, things like 
colors etc. should probably stay in the OpenGL package. But there are a few 
other packages needing color data types, too...

   * If the package is not general enough, it might be a bad idea to steal 
names/hierarchy locations which *are* general.

Nevertheless, I'd be happy to see some proposals for a sensible, compact 
vector math package. Probably we can fulfill most of the common use cases with 
something simple.

And one word about lumping the 3 packages together: Any function, module, and 
package should have *one* clearly defined task, this is crucial for every SW 
design. I would have a hard time explaining what this super package is all 
about, even if we throw only 2 of the 3 packages together. Personally I feel 
that this is a strong argument for 3 separate packages.

 (I know that glu has tesselation). [...]

But GLU is basically dead with OpenGL 3.x. :-)

Cheers,
   S.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] ANN: Silkworm game

2009-05-03 Thread Sven Panne
Nice work! Two minor suggestions, apart from the the paths issue already 
discussed here:

   * Either include a license file in the source distribution or remove the 
corresponding line in the .cabal file. Cabal won't work if it is specified and 
missing.

   * List all your build dependencies directly, so users can simply do a 
cabal install, pulling all missing dependencies automatically. No need for 
Makefiles or a long description in the README anymore...

Patch for those items attached.

As a side note, I get a very bad feeling when Hipmunk gets compiled on my 
x86_64 box:

chipmunk/cpCollision.c: In function ‘findVerts’:

chipmunk/cpCollision.c:174:0:
 warning: cast from pointer to integer of different size

chipmunk/cpCollision.c:180:0:
 warning: cast from pointer to integer of different size
chipmunk/cpCollision.c: In function ‘findPointsBehindSeg’:

chipmunk/cpCollision.c:233:0:
 warning: cast from pointer to integer of different size
chipmunk/cpCollision.c: In function ‘seg2poly’:

chipmunk/cpCollision.c:274:0:
 warning: cast from pointer to integer of different size

chipmunk/cpCollision.c:276:0:
 warning: cast from pointer to integer of different size
chipmunk/cpSpace.c: In function ‘queryFunc’:

chipmunk/cpSpace.c:411:0:
 warning: cast from pointer to integer of different size

chipmunk/cpSpace.c:411:0:
 warning: cast from pointer to integer of different size

This can't be correct, but I'll probably have to take a look at that. Or is it 
a know bug that Hipmunk ist not 64bit-clean?

Cheers,
   S.



--- Silkworm.cabal.orig	2009-04-14 00:33:14.0 +0200
+++ Silkworm.cabal	2009-05-03 13:48:05.0 +0200
@@ -2,7 +2,6 @@
 Version: 0.2
 Description: 2D game based on the Hipmunk physics engine bindings.
 License: LGPL
-License-file:LICENSE
 Author:  Duane Johnson
 Maintainer:  duane.john...@gmail.com
 Build-Type:  Simple
@@ -10,5 +9,5 @@
 
 Executable haq
   Main-is:   main.hs
-  Build-Depends: base
+  Build-Depends: base, array, containers, directory, random, pngload, Hipmunk, GLFW, OpenGL
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: Linking and constants problems with OpenAL under Windows

2009-05-02 Thread 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


[Haskell] ANNOUNCE: ALUT 2.1.0.2

2009-05-02 Thread Sven Panne
A new version of the ALUT package has been uploaded to Hackage. Again, this is 
a bug fix only release, containing only tiny changes:

  * Include missing aclocal.m4 and examples in source distribution

  * Removed unused Makefiles and prologue.txt

  * Fixed OpenAL URLs

Cheers,
   S.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell] ANNOUNCE: OpenAL 1.3.1.3

2009-05-02 Thread Sven Panne
A new version of the OpenAL package has been uploaded to Hackage. Again, this 
is a bug fix only release:

  * Include OpenAL header when checking values of constants

  * Include missing aclocal.m4 and examples in source distribution

  * Removed unused Makefiles and prologue.txt

  * Removed empty demos subdirectory

  * Fixed OpenAL URLs

Hopefully this release will fix build issues on MacOS X and Windows. Thanks to 
Balazs Komuves for making me aware of these bugs, and providing a patch.

Cheers,
   S.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell] ANNOUNCE: GLUT 2.1.2.1

2009-05-02 Thread Sven Panne
A new version of the GLUT package has been uploaded to Hackage. This is a bug 
fix only release, containing only tiny changes:

  * Include missing aclocal.m4 and examples in source distribution

  * Removed unused Makefiles and prologue.txt

Cheers,
   S.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell-cafe] Decoupling OpenAL/ALUT packages from OpenGL

2009-05-02 Thread Sven Panne
I'd like to get some feedback from the Haskell community about some packaging 
issues, so here is my problem: As a medium-term goal, I'd like to decouple the 
OpenAL/ALUT packages from the OpenGL package, because there are very sensible 
use cases where you might need some sound, but not OpenGL. The current 
coupling has mostly historic reasons.

The OpenAL package depends on the OpenGL package in 3 areas:

   * OpenAL uses OpenGL's notion of StateVars all over the place.

   * OpenAL's Buffer and Source are instances of OpenGL's ObjectName class.

   * OpenAL's sources and listeners have some properties like velocity, 
orientation, direction and position which are modeled by OpenGL's Vector3 and 
Vertex3 data types.

The ALUT package depends on the OpenGL package because of GettableStateVars.

The packages are supposed to fit nicely together, so using the same types is a 
must, but the actual packaging is not nice. So the obvious idea is to 
introduce 3 new packages which lift out functionality from the OpenGL package:

   * a small StateVar package, consisting only of OpenGL's StateVar module 
(in a better place in the name hierarchy, of course, perhaps Data.StateVar?)

   * a tiny ObjectName package, consisting only of OpenGL's ObjectName class 
(In Data.ObjectName? I'm not very sure about a good place in the hierarchy 
here.)

   * a package containing most of the data types/newtypes in OpenGL's 
VertexSpec module (Vertex{2,3,4}, Color{3,4}, etc.) plus instances for the 
base classes like Eq, Ord, Show, etc. I really don't know a good name for this 
package and what a good place in the hierarchy would be (probably something 
like Data.Foo, but what is Foo?)

The point is: The first two package would be very small. Would this be OK? 
Does anybody see other alternatives? What would be good names for those 
packages and where in the naming hierarchy should they really go?

Cheers,
   S.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] How to install HOpenGL to Windows?

2009-04-30 Thread Sven Panne
Am Mittwoch, 29. April 2009 11:25:31 schrieb Duncan Coutts:
 On Mon, 2009-04-27 at 19:03 +0200, Sven Panne wrote:
  [...]
  As usual, things are always a bit trickier than they appear initially: On
  non- Windows systems it is not always sufficient to link against libGL
  alone, sometimes you'll have to link against several X11 libs, too. I am
  not sure if this is still a widespread problem, but in the past it was.

 Right. It's still possible to use custom code in Setup.hs to test these
 kinds of things. It's a bit less easy however.

That's why the autoconf macros are so tricky. Re-inventing the wheel in 
Haskell is not something I'd like to do. Note: I see autoconf as a necessary 
evil, not as a glorious tool. The predefined autoconf macros contain man years 
(if not man decades) of sweat and tears from people trying to make their SW 
portable. If you only know 1 or 2 platforms, everything looks easy, but this 
is not the case at all. Good luck for everybody trying to ignore that 
accumulated knowledge...

 I didn't know that there was any working GHC for Cygwin. Or do you mean
 building a non-cygwin lib but under the cygwin shell? [...]

I don't know if GHC currently builds under Cygwin, but in former times it was 
*the* way (read: one and only way) to build it on Windows.

  On *nices you look into /usr/include and /usr/local/include, and
  that's it, unless the user tells you something different. And Apple is
  always a very creative company, so they decided to put *their* OpenGL
  headers in a completely different path where no -I flag can help...

 But you have some way of finding them right? Even if it's platform
 dependent. We can do the same in the .cabal file or the Setup.hs.
 There's also a Cabal flag users can pass to tell us about extra lib and
 include dirs.

I even have standard, well-documented, platform-independent way: Tell 
configure about it via the environment variable CPPFLAGS for headers and 
LDFLAGS for libraries. Cabal is buggy in this respect, IIRC, it passes no or 
incorrectly named variables to configure.

 Absolutely, finding headers is important. Cabal now checks at configure
 time that all header files and libs listed in the .cabal file can
 actually be found.

I don't know what Cabal does internally, but simply checking for the existence 
of a header file or a library file is *far* too naive, look into the autoconf 
docs and/or mailing lists to see why. You actually have to compile for header 
checks and link for library checks, everything else is plainly wrong, because 
you'll probably miss dependencies, pick up the wrong stuff, etc.

 One suggestion I've seen is just to improve the ffi pre-processors. The
 c2hs tool is in a position to discover if the calling convention is
 stdcall or ccall so it could generate the foreign imports correctly. [...]

This wouldn't help much: The foreign imports in OpenGL are written by hand, 
and when the OpenGL ARB ever manages to release some consistent, machine-
usable and complete API description (the current .spec files fail in almost 
all these aspects), they will be generated from that, not from C headers, 
because, not surprisingly, the latter lack a lot of information.

 In practise I've not found that most configure scripts actually do
 feature based tests. There's some, but half of it degenerates into if
 we've not got the OSX framework for this then do that. I mean they just
 end up doing platform-specific conditionals. [...]

This is often correct for hobby projects of inexperienced people, but not 
necessarily for larger or more mature projects. And in a (very) few cases, 
platform-specific conditionals are even the right thing to do, but not in the 
vast majority of cases, of course.

And this has nothing to say about autoconf itself: Seeing e.g. ugly Haskell 
code is not a reason to condemn Haskell itself, either.

 Anyway, so that's why I'd like us to look in detail at what features we
 need in Cabal to let us switch most packages from using ./configure
 scripts to using Setup.hs scripts.

As I said in another email: I'll happily review and accept patches for this, 
but I won't spend any effort on re-inventing the autoconf wheel in Haskell.

Cheers,
   S.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: Inter-module links with Haddock broken?

2009-04-28 Thread Sven Panne
Am Samstag, 25. April 2009 14:48:03 schrieb Sven Panne:
 Currently I am unable to make inter-module links (of the form
 'Foo.Bar.baz') work with the Haddock shipped with GHC 6.10.2. [...]

Until a few moments ago, I wasn't aware of the fact that Haddock has a trac 
for itself nowadays, so I guess my problem is a symptom of:

   http://trac.haskell.org/haddock/ticket/78

What is the schedule for the Haddock milestone 2.5.0 mentioned in that ticket? 
When can we expect that fix in a shipped GHC?

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


[Haskell] ANNOUNCE: OpenGL 2.2.2.0

2009-04-28 Thread Sven Panne
A new version of the OpenGL package has bee uploaded to Hackage. This is 
mainly a bug fix release, containing the following changes:

  * Minor tweaks for recent Cabal versions.

  * Removal of old GHC build system relics.

  * Handle invalid framebuffer operation error.

  * Terminate GLSL attribute names with NUL in various functions.

  * Access 3D texture functions via their core API names, improving 
portability (e.g. for MacOS X).

  * Added a workaround for a bug in the SGI tessellator.

  * Fixed marshalling of control points for evaluators.

  * Added mapBuffer/unmapBuffer and beginQuery/endQuery to exported API.

Cheers,
   S.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell] ANNOUNCE: GLUT 2.1.2.0

2009-04-28 Thread Sven Panne
A new version of the GLUT package has been uploaded to Hackage. This is a 
feature release, adding all the shiny new features of the upcoming freeglut 
2.6.0 C library plus a few older bits and pieces which had been missing:

  * Minor tweaks for recent Cabal versions

  * Removal of old GHC build system relics.

  * Added support for OpenGL 3.x context creation (freeglut only)

  * Added support for getModeValues (freeglut extension)

  * Added freeglut-specific full screen API

  * Added freeglut-specific (de-)initialization API

  * Added support for multisampling with given samples per pixel (freeglut)

  * Added support for mouse wheel callback (freeglut)

  * Added support for window state callback (freeglut)

  * Added support for captionless/borderless windows (freeglut 2.6.0)

  * Handle special keys introduced by freeglut 2.6.0

The most important addition is the ability to create versioned context, so you 
can use forward compatible OpenGL 3.1 contexts. Death to the fixed function 
pipeline!! ;-)

Cheers,
   S.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell] ANNOUNCE: OpenAL 1.3.1.2

2009-04-28 Thread Sven Panne
A new version of the OpenAL package has been uploaded to Hackage. This is a 
bug fix only release:

  * Minor tweaks for recent Cabal versions

  * Removal of old GHC build system relics.

  * Use the correct calling convention on Windows.

Cheers,
   S.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell] ANNOUNCE: ALUT 2.1.0.1

2009-04-28 Thread Sven Panne
A new version of the ALUT package has been uploaded to Hackage. This is a bug 
fix only release, containing only tiny changes:

  * Minor tweaks for recent Cabal versions

  * Removal of old GHC build system relics.

Cheers,
   S.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


Re: [Haskell-cafe] How to install HOpenGL to Windows?

2009-04-27 Thread Sven Panne
Am Montag, 27. April 2009 00:11:20 schrieb Duncan Coutts:
 On Sun, 2009-04-26 at 19:03 +0200, Sven Panne wrote:
 [...]
 * How to link programs using OpenGL

 This is because the GL libs are called different names on different
 platforms right? But they're consistent within each platform, it's just
 Windows vs everyone else isn't it?

 How about:

 if os(windows)
   extra-libraries: gl32
 else
   extra-libraries: GL

As usual, things are always a bit trickier than they appear initially: On non-
Windows systems it is not always sufficient to link against libGL alone, 
sometimes you'll have to link against several X11 libs, too. I am not sure if 
this is still a widespread problem, but in the past it was. Hopefully most 
*nices get their dynamic library dependencies right nowadays... :-P Windows 
is, as always, a special beast, especially when you take Cygwin into account: 
On Cygwin you can either build against the native OpenGL or against Cygwin's 
X11 OpenGL. This can be configure via --without-x. How can we do this in 
.cabal files? And MacOS had some peculiarities which I can't fully remember 
anymore, too.

 * The Haskell types corresponding to the OpenGL types

 Does hsc2hs #type not help us with this? [...]

I am not sure, because I haven't had a look at hsc2hs for a long time, and at 
the beginning of the OpenGL binding there were no such tools, not even the FFI 
in its current form. Perhaps I'll have a look at this, but to make this work, 
I am sure that we'll have to solve the next item:


 * To do the former: How to find the OpenGL C headers

 What's needed here? Are they not in standard locations? Cabal has
 support for users to specify non-standard locations.

What is a standard location for headers on Windows? There is no such 
concept. On *nices you look into /usr/include and /usr/local/include, and 
that's it, unless the user tells you something different. And Apple is always 
a very creative company, so they decided to put *their* OpenGL headers in a 
completely different path where no -I flag can help...

Having access to the OpenGL headers is crucial for finding out which C types 
are behind OpenGL types like GLint, GLenum, ... The OpenGL spec only specifies 
minimum requirements for these types and *not* their C mapping.

 * The library calling convention

 This is stdcall on Windows and ccall everywhere else right?

 How about:

 if os(windows)
   cpp-options: -DCALLCONV=stdcall
 else
   cpp-options: -DCALLCONV=ccall

This should be fine, at least when we solve the Cygwin problem discussed 
above: The X11 OpenGL libraries on Windows do *not* use stdcall, only the 
native OpenGL libraries. (The whole calling convention story on Windows 
really, really sucks, IMHO...) Using CPP for this simple task doesn't look 
right, but with the current FFI I don't see a way around this, which is a 
shame. Any ideas/proposals for a FFI change?

 * How to load OpenGL extensions

 I don't know enough of the details here to comment.

You'll have to know if wglGetProcAddress, NSAddressOfSymbol (+ a bit more 
code) or some variant of glXGetProcAddress has to be used, plus their 
necessary headers. This is probably doable via some platform switches in 
Cabal, too.

A few general remarks:

 * Ignoring the (usual) Windows trouble, I like autoconf's approach of testing 
features instead of relying on extremely fragile platform conditionals. The 
latter are a constant source of troubles and from a SW engineering point of 
view, they are a clear step backwards. The I know my platform approach which 
you basically propose reminds me of the xmkmf hell from the last millennium: 
If X11 didn't know your platform, you had a *lot* of fun getting the platform 
description right.

 * We can go this autoconf-free route, but this is a part of my bindings which 
I definitely won't maintain in full time. I'll be happy to review and accept 
patches, but making things work on Windows, Cygwin, Linux, *BSD, MacOS X, ... 
is a lot of work, which is a fact I have painfully learned in the past few 
years. The autoconf code may be ugly, but the tons of platform differences are 
ugly, to. I want to work on the binding itself mainly, not on the build 
system, which currently works. To repeat myself: Patches are happily accepted, 
but I propose incremental changes and heavy testing on various platforms.

 * Most of the tasks my autoconf scripts perform are not specific to OpenGL at 
all. I guess that most bindings for non-trivial C libraries face the same 
challenges (Where are my libs? Where are my headers? What are my types?) 
Having good Cabal support for these would be very nice.

Cheers,
   S.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] How to install HOpenGL to Windows?

2009-04-26 Thread Sven Panne
Am Donnerstag, 9. April 2009 00:28:35 schrieb Peter Verswyvelen:
 Yes I totally agree that it is overkill. Ideally I would like every package
 to install on Windows without requiring MinGW. But I was just explaining
 the situation as it is right now.

Well, I don't like using autoconf, either, but currently I don't see an 
alternative. If you look at the configure.ac of the OpenGL package, you can 
see that autoconf has to figure out the following:

   * How to link programs using OpenGL

   * The Haskell types corresponding to the OpenGL types

   * To do the former: How to find the OpenGL C headers

   * The library calling convention

   * How to load OpenGL extensions

The build process in itself is purely Cabal-based, it is only the 
configuration above which done via autoconf. So in theory you could write the 
few output files of the configure run by hand and then use Cabal, without any 
MinGW/MSYS or cygwin.

I don't see how Cabal could help here even further, the tests above are quite 
OpenGL-specific, but I am open for suggestions.

Cheers,
  S.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Inter-module links with Haddock broken?

2009-04-25 Thread Sven Panne
Currently I am unable to make inter-module links (of the form 'Foo.Bar.baz') 
work with the Haddock shipped with GHC 6.10.2. The library documentation on 
haskell.org has the same problem, see e.g. the last paragraphs of

   http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-
Exception-Base.html#v:catch

This doesn't work for a few releases now, so I guess this is a known bug, but 
I can't find a ticket for it. Are there workarounds for this? A new syntax?

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


Re: [Haskell-cafe] Linker Errors For OpenGL / GLUT 'Hello World' Program.

2008-10-09 Thread Sven Panne
On Saturday 20 September 2008 19:13:43 Donnie Jones wrote:
 [...]
  checking GL/gl.h usability... yes
  checking GL/gl.h presence... yes
  checking for GL/gl.h... yes
  checking OpenGL/gl.h usability... no
  checking OpenGL/gl.h presence... no
  checking for OpenGL/gl.h... no
  checking GL/glu.h usability... yes
  checking GL/glu.h presence... yes
  checking for GL/glu.h... yes
  checking OpenGL/glu.h usability... no
  checking OpenGL/glu.h presence... no
  checking for OpenGL/glu.h... no
 
  That looks like to me that the gl.h and glu.h header files were found and
  are usable (in some cases).  I am able to build

That's correct, but that's a transcript of configure in the OpenGL package, 
not the GLUT package. The OpenGL package contains the bindings for the GL and 
GLU libraries, the GLUT package contains the binding for the, well, GLUT 
library.

 [...]
 ### Relevant lines that include -lGL or -lGLU in config.log ###
 [...]

This test is again OK, it first checks if we have to link against glu32 (for 
Windows) or GLU (for the rest of the world) to use GLU features. But again, 
this excerpt is from the config.log of the OpenGL package, not the GLUT 
package.

 It seems like the OpenGL and GLUT libraries are found (after -lglu32 fails,
 I am using Debian Linux).  I am not sure what to try now.

What you have posted so far indicates that the GL and GLU headers and 
libraries have been found, but for GLUT only the header has been found. Could 
you please post the relevant part of the config.log in the GLUT package, i.e. 
the part for checking for GLUT library... no? Where is the GLUT library on 
your system located?

Does anybody else have a similar problem?

Cheers,
   S.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Win32 Open GL / Glut Applications

2007-09-23 Thread Sven Panne
On Friday 21 September 2007 20:19, Ronald Guida wrote:
 John Wicket wrote:
   yea, that is probably what I need.  Can you post in a step-by-step way.

 Here is a set of instructions for what I had to do to get FreeGLUT
 working with GHCi [...].

Oh dear, a long a sad story... :-(

 [...]  Although I just don't understand why freeglut, the
 Haskell GLUT library, and GHCi won't work together in the first place.

That statement is not correct, they *do* work together. The problem you are 
experiencing is that the GLUT version used to build the GHC installer/binary 
distro is obviously not freeglut, but classic GLUT. As long as you only 
use classic GLUT features, this is OK. Things get really hairy when you 
want to use freeglut-only features and still have a GHC installer/binary 
distro which is guaranteed to run with classic GLUT as well (with 
restricted features in the latter case, of course). To do this properly, the 
GLUT package has to resolve freeglut-only API entries dynamically, but 
glutGetProcAddress is not contained in lots of GLUT DLLs out in the wild 
(it's in GLUT API version 5 plus freeglut). This is really a pity and a big 
design flaw in GLUT IMHO, but there is not much one can do about that.The 
only thing left is to load the GLUT/freeglut dynamic library, 
well, dynamically and resolve the freeglut API entries by hand. Doing this 
is not hard, but a little bit tricky to get right portably: Use dlopen/dlsym 
on most *nices, LoadLibrary/GetProcAddress on Windoze, something else on Mac 
OS, take care of possible leading underscores, etc. etc. I really wanted to 
avoid doing this, but it looks like there is no way around it. Given the 
current time frame for the GHC 6.8.1 release, I don't think that it is 
feasible to get this into that release, because I would need feedback from 
lots of platforms to be sure things work.

 [...] darcs-1.0.9
   http://darcs.net/darcs-1.0.9.tar.gz [...]

There are darcs binaries for Windows, so there is no need to build it and the 
libraries it needs:

http://wiki.darcs.net/DarcsWiki/CategoryBinaries#head-c7910dd98302946c671cf63cb62712589b392074

Furthermore, darcs itself is not needed for what you want to do.

 [...] Freeglut-2.4.0
   http://freeglut.sourceforge.net/index.php#download [...]

The freeglut project currently doesn't provide prebuilt binaries, so this is 
hardly the GLUT package's fault. ;-) Furthermore, the official way to build 
the project on Windows is via MSVC, and there are projects files for this. 
Building a DLL via MinGW/MSYS would be nice, too, so perhaps you could post 
your patches in the freeglut-developer mailing list. I think that there will 
be a new freeglut release soon, perhaps I can push people to make at least a 
simple ZIP file with the binaries for Windows available on the project pages.

 GLUT-2.1.1
   You need to use darcs to download GLUT-2.1.1.
 [...]
Locate the line start starts with build-depends: and remove
the dependencies array and containers

Now you enter the great world of Cabal versionits and the Big Library Splitup 
(tm). ;-) If you want to use a bleeding edge version of GLUT, you need a 
bleeding edge version of GHC and the libraries coming with it. A released 
version is available via hackage.haskell.org.

   [...] 6. Modify GLUT-2.1.1/Graphics/UI/GLUT/Extensions.hs as follows:

Look at the last two lines:

 foreign import ccall unsafe hs_GLUT_getProcAddress hs_GLUT_getProcAddress

:: CString - IO (FunPtr a)

Change hs_GLUT_getProcAddress to glutGetProcAddress

   7. Modify GLUT-2.1.1/cbits/HsGLUT.c as follows:

Look for void* hs_GLUT_getProcAddress(char *procName) and
remove the whole function.

Huh? If you *really* compile against the freeglut header, these steps are 
unnecessary. What is the reason for this change?

 {...]
   11. In GHC's directory, there is a file named package.conf.  This
   file contains one extremely long line.  You need to find an
   editor that will let you insert some text into this line without
   introducing any line breaks.  Emacs can do this.

   You need to locate the text  pkgName = GLUT  and then you
   need to locate  hsLibraries = [HSGLUT-2.1.1]  to the right
   of there.  The very next thing to the right of hsLibraries
   should be  extraLibraries = [] .  You need to change it to
extraLibraries = [freeglut] .

This is unnecessary if you install the freeglut DLL correctly. What is the 
output of ghc-pkg describe GLUT before this modification?

   13. If you want to /compile/ with GHCi, then you'll need to copy the
   freeglut.dll file into the same directory as your newly-compiled
   program.exe file.  I haven't tried static linking yet; that
   would require recompiling freeglut as a static library instead
   of a DLL.

The traditional way is to put the DLL as glut32.dll into your 
WINDOWS/system32, just next to opengl32.dll. :-P I don't know what the 
Vista-approved 

Re: [Haskell-cafe] Library Process (was Building production stable software in Haskell)

2007-09-23 Thread Sven Panne
On Thursday 20 September 2007 16:33, David Menendez wrote:
 Does RPM, etc., deal with the fact that Haskell library installations
 are specific to a particular platform?

It depends what you mean with deal: If it is only making sure that a given 
binary library RPM matches the installed Haskell system, yes.

 If I install GHC and some library, and later install Hugs or a later
 GHC, how easy is it to make sure the library is available to the new
 installations?

This is asking for much more, and the general answer for all mature packaging 
systems I know is: This will never be the case for *binary* packages. The 
simple reason is that for rebuilding packages (this is basically what you are 
asking for), you have different (and typically *many*) more dependencies. 
This is why e.g. RPM differentiates between Requires (i.e. normal runtime 
dependecies) and Build-Requires (dependencies for building an RPM).

Although this situation is far from perfect, it is a direct consequence of the 
fact that there is no such thing as a standard Haskell ABI which is shared 
between all implementations and versions of them. The situation in C is much 
better (because it is much easier there), but even C++ suffered from ABI 
problems for several years on most platforms.

Cheers,
   S.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Library Process (was Building production stable software in Haskell)

2007-09-18 Thread Sven Panne
On Tuesday 18 September 2007 09:44, Dominic Steinitz wrote:
 This discussion has sparked a question in my mind:

 What is the process for the inclusion of modules / packages in ghc, hugs
 and other compilers  interpreters?

Personal interest of the people working on GHC et. al. ;-)

 I thought the master plan was that less would come with the compiler /
 interpreter and the user would install packages using cabal. [...]

Although this statement might be a bit heretical on this list, I'll have to 
repeat myself again that Cabal, cabal-install, cabal-whatever will *never* be 
the right tool for the end user to install Haskell packages on platforms with 
their own packaging systems like RPM (the same holds for other systems, I 
just use RPM as an example here). This packaging system, and nothing else, 
will write into my /usr, otherwise chaos and versioning hell will threaten 
the system integrity. Cabal is a very fine tool to be used from RPM .spec 
files and to develop below one's own home directory, but it is not the tool 
of choice for the final installation. There are various reasons for this:

   * Imagine you want to find out to which package in which version a given 
file belongs. Impossible, if RPM is bypassed.

   * RPM offers functionality to verify the integrity of the installed SW, it 
can tell me which files are documentation, which ones are configuration 
files, etc. All this meta information has to be in a single system.

   * YaST, yum, etc. already have the notion of repositories, trust (via 
standard cryptographic methods) and resolving transitive dependencies, so we 
would re-implement things which are already there, well maintained and 
well-known to end users.

   * Imagine every language would force their end users to use specific tools 
for installation, this would be ridiculous. Personally I don't care at all 
about the details how Perl modules, some PHP/Python/... libraries etc. are 
installed on my system. This knowledge belongs to the packager who builds a 
nice RPM, mentioning all dependencies, so my favourite RPM tool can 
transitively resolve, download and install everything, offering a nice GUI if 
I like. No need to remember how to do this for Perl/PHP/Python/etc.

Regarding the pros and cons of small, separate packages: In general I agree 
that this is the right direction, and this is what other languages do as 
well. There are e.g. tons of Perl/PHP/Python/Ruby RPMs available for my 
system, each offering a specific library, while the RPMs containing the 
interpreters/compilers are rather small. But: IMHO we are not there yet, 
because we still have to remove quite a few rough edges until we can smoothly 
offer e.g. an RPM repository with lots of small library RPMs (Cabal 
versionitis, updating the Haddock documentation index, etc.). Therefore, I'll 
continue to offer only Sumo-style RPMs for GHC + boot-libs + extra-libs for 
now, but I hope I can change this in the future.

Another point: Although this is hard to believe nowadays, ;-) people are not 
always online, so simply installing what is missing might not always be an 
option. Great, I'd really need the foobar-2.1 package now, but I'm currently 
1 feet above the Atlantic ocean... The right way to tackle this problem 
is using meta packages, basically referencing lots of bundled small packages. 
RPM offers such a feature, and I guess other systems, too. On a laptop, such 
a meta package leading to the installation of tons of libraries is the right 
approach, on a fixed workstation the story might be different.

Cheers,
   S.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: compiling on solaris 9

2007-09-15 Thread 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

2007-09-15 Thread 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: [Haskell-cafe] Data.Binary Endianness

2007-09-15 Thread Sven Panne
On Tuesday 11 September 2007 09:17, Don Stewart wrote:
 Just in case people didn't see, the `binary' package lives on

   http://darcs.haskell.org/binary/

 However, Lennart Kolmodin, Duncan and I are actively maintaining and
 reviewing patches, so send them to one (or all) of us for review.

Is there any deep reason why binary is not below packages like almost all 
other packages? The toplevel directory is already a complete mess, so a 
little bit more structure would be good. So I propose the following: 
Move binary to packages/binary, update any references to the old URL and 
use a symlink on darcs.haskell.org for backwards compatibility (this should 
be nuked in a few months or so).

Cheers,
   S.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Data.Binary Endianness

2007-09-15 Thread Sven Panne
On Saturday 15 September 2007 20:09, Stefan O'Rear wrote:
 packages is only for those libraries that are shipped with GHC.

First of all, this fact would be new to me, furthermore this would be a highly 
volatile categorization. Should URLs change when a package suddenly gets into 
or was thrown out of boot-/extra-packages? I don't think so. The fact what is 
shipped and what not is explicit in the ghc/libraries/{boot,extra}-libraries, 
not in the structure of darcs.haskell.org. Packages which are hosted there 
should be below, well, packages. The toplevel directory is currently a bit 
crowded and unstructured...

Cheers,
   S.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: Bug: wrong ghc location in package.conf

2007-09-11 Thread Sven Panne
On Tuesday 11 September 2007 05:58, Conal Elliott wrote:
 In ghc-6.8 20070909, my package.conf contains some strange and incorrect
 paths, such as

 haddockInterfaces =
 [/usr/local/doc/ghc/libraries\\html\\containers\\containers.haddock],
 haddockHTMLs = [/usr/local/doc/ghc/libraries\\html\\containers]

 In fact, the installation location is c:/ghc/ghc-6.8.20070909/, not
 /usr/local.  I do have a failed partial ghc build (from darcs HEAD) at
 /usr/local from last week.  Perhaps there's some sticky info somewhere.
 [...]

There was some confusion regarding build paths vs. installation paths in GHC's 
build system. I think I've fixed most of this in the last few days, at least 
I get a nice RPM on Linux now. Could you try to update to the bleeding edge 
and rebuild? It would be good to have some Windows feedback.

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


Re: [Haskell-cafe] Re: Data.Binary Endianness

2007-09-11 Thread Sven Panne
On Monday 10 September 2007 21:02, apfelmus wrote:
 [...]
class Put a endian where
  put :: endian - a - Put
 [...]
 Oh, and the 8,16,32 and 64 are good candidates for phantom
 type/associated data types, too.

I think that using any non-H98 feature like MPTC or associated data types for 
such a generally useful and basic package would be a *big* mistake.  Let's 
follow the KISS principle here. Everybody is free to make a nicer, but 
non-portable wrapper...

Cheers,
   S.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Data.Binary Endianness

2007-09-11 Thread Sven Panne
On Monday 10 September 2007 19:50, Thomas Schilling wrote:
 [...]
 instance Binary MP3 where
   get = MP3 $ getHeader * getData -- [*]
 where getHeader = do magic - getWord32le
case magic of
...

Of course this works in the sense that it compiles, but Binary is 
conceptually the wrong class to use.

 to read a (IEEE) double you use

   do x - (get :: Double); ...

:Where is IEEE mentioned in the docs? Does it use LE/BE/host order? Plain 
get/put on Float/Double are useless for reading IEEE floating numbers.

Cheers,
   S.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Data.Binary Endianness

2007-09-11 Thread Sven Panne
On Tuesday 11 September 2007 08:14, Don Stewart wrote:
 sven.panne:
  On Monday 10 September 2007 19:50, Thomas Schilling wrote:
   [...]
   instance Binary MP3 where
 get = MP3 $ getHeader * getData -- [*]
   where getHeader = do magic - getWord32le
  case magic of
  ...
 
  Of course this works in the sense that it compiles, but Binary is
  conceptually the wrong class to use.

 I wouldn't go as far as saying `wrong', for protocol-specific data types it
 seems reasonable for the Haskell serialisation to use an agreed-upon
 external format, via a Binary instance.

The question is: What is the *human reader* suggested when he sees a signature 
like foo :: Binary a = ... - a - ...? This should probably mean foo is 
using some portable (de-)serialization, but doesn't care about the actual 
representation, at least this is how I understand Binary's contract from the 
Haddock docs. The example above means something completely different, so I 
propose to add another class (e.g. ExternalBinary, better name needed) to 
the binary package for such uses. This class wouldn't have any instances in 
the package itself, but at least it would set a standard, so things are 
crystal clear when one sees a signature like blah :: ExternalBinary a 
= ... - a - 

This situation is very similar to the OO-world, where class inheritance is 
often overused, just because it looks so handy when written initially and 
delegation/aggregation/... would be the conceptually right way (i.e. 
implementation hierarchy vs. interface hierarchy).

Cheers,
   S.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Data.Binary Endianness

2007-09-11 Thread Sven Panne
On Monday 10 September 2007 19:26, Don Stewart wrote:
 Yep, just send a patch. Or suggest what needs to happen.

OK, I'll see what I can do next weekend, currently I'm busy with 
packaging/fixing GHC. I have similar code lying around in various places, and 
it would be nice if there was a more officially sanctioned place to put this.

Cheers,
   S.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Tiny documentation request

2007-09-10 Thread Sven Panne
On Sunday 09 September 2007 18:41, Andrew Coppin wrote:
 [...]
 Well, if I could collapse it with a single click, it would be much
 easier to scroll past it and get to the thing I'm looking for. I didn't
 say remove it, just give me the option to hide it. ;-)

OK, that shouldn't be too hard to implement.

 Oh goodie... So it's there to keep the machines happy?

No, it's there to keep *me* happy when I'm looking for a module. ;-)

 It's just tedious that every single time I load up this page, I have to
 spend 30 seconds manually collapsing everything so I can get to the
 module I actually want to look at. (The alternative is to manually
 scroll the 13-page list my hand. Not very funny...)

I still fail to understand why you have to scroll or collapse manually, every 
browser I know of has a search facility. And there is the index page, where 
you have an incremental search facility even when your poor browser (guess 
which one I mean? :-) doesn't have it, at least when the index has been 
generated by a recent Haddock.

 OK, so... can we add a pair of expand all/collapse all buttons then?

Again, this should be rather easy to add.

Cheers,
   S.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Data.Binary Endianness

2007-09-10 Thread Sven Panne
On Monday 10 September 2007 17:17, Jules Bean wrote:
 On the documentation page:

 http://www.cse.unsw.edu.au/~dons/binary/Data-Binary.html
 [...]

Just a small hint: That page seems to be out of date compared to:

   http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-0.3

The library looks quite nice, but I'm missing support for reading/writing 
Int{8,16,32,64} and Float/Double (in IEEE format, currently *the* binary 
representation in most formats I know) in LE/BE/host byte order. Have I 
overlooked something? Using unsafeCoerce# and friend there are probably 
workarounds for this, but having it in the official API would be quite 
helpful for I/O of real-world formats.

Cheers,
   S.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


  1   2   3   4   5   6   >