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
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
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
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 t
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
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
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
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/1
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 wra
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 co
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
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 r
2016-07-08 9:09 GMT+02:00 Joachim Breitner :
> 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! T
[ 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 recor
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
ti
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 war
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 se
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 que
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 b
>
> [...] 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
2015-07-24 9:59 GMT+02:00 Christian Maeder :
> 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/librari
2015-07-07 13:30 GMT+02:00 Thomas Miedema :
>
>
> On Tue, Jul 7, 2015 at 10:54 AM, Sven Panne 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/ticke
2015-07-07 7:26 GMT+02:00 Mark Lentczner :
> 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):
---
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:
2015-05-06 16:21 GMT+02:00 Bardur Arantsson :
> +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 h
2015-05-02 12:01 GMT+02:00 Paolino :
> 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
2015-01-25 11:18 GMT+01:00 harry :
> [..] 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-sr
2014-11-25 20:46 GMT+01:00 Austin Seipp :
> 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
2014-04-25 22:26 GMT+02:00 Malcolm Wallace :
> [...] 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
2014-03-17 14:22 GMT+01:00 Brandon Allbery :
> On Mon, Mar 17, 2014 at 9:08 AM, Edward Kmett 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, altho
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 GH
On Monday 17 September 2007 18:14, skaller wrote:
> [...] The algorithm I presented (crudely) goes further.
> What you're doing is enough for a language that doesn't have to
> bind to C and/or C++. [...]
I think this is an exaggeration, we do bind to C and do this quite
successfully. As long as C
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 not
On Saturday 15 September 2007 13:58, skaller wrote:
> The RIGHT way to do this is rather messy .. but there is only
> one right way to do it. [...]
IMHO things are not that black or white: I think we have a tradeoff between
almost 100% fool-proofness (which is basically the approach you describe)
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
On Friday 14 September 2007 15:42, Ian Lynagh wrote:
> On Fri, Sep 14, 2007 at 12:20:20PM +0200, Philip K.F. Hölzenspies wrote:
> [...]
> > /usr/share/aclocal/progsreiserfs.m4:13: warning: underquoted
> > definition of AC_CHECK_LIBREISERFS
> > run info '(automake)Extending aclocal'
> > or see
>
On Tuesday 01 May 2007 13:02, Claus Reinke wrote:
> [...] would it be possible
> to have a "configuration package" with nothing but the common checks? then
> every package, and ghc itself, could depend on that package being there,
> and every package configure could modularly use the information fr
[ Sorry for the late reply, but I'm just digging through 2-3 months of
emails... ]
On Saturday 21 April 2007 12:13, Tristan Allwood wrote:
> [...] I now have a shiny new, all extralib (-opengl) ghc 6.6 all working :)
Is there no OpenGL support on the PS3 platform you are compiling on or is it
j
On Thursday 15 March 2007 15:50, I wrote:
> [...] Same question for runhugs, as the corresponding executable is called
> hugs98. [...]
Oops, I mixed up the RPM package name and the executable name. The former is
hugs98, the latter simply hugs, so runhugs is totally OK.
Cheers,
S.
On Thursday 15 March 2007 15:27, Malcolm Wallace wrote:
> Sven Panne <[EMAIL PROTECTED]> wrote:
> > And 'runhs' is actually not a very good name to run nhc98,
> > runnhc or runnhc98 would be much better IMHO.
>
> Well, I chose 'runhs', because i
On Thursday 15 March 2007 10:56, Malcolm Wallace wrote:
> [...] If you install hmake, and change 'runhaskell' to runhs, it works.
This reminds me of something, at least for the Linux world: No Haskell
compiler/interpreter should directly install 'runhaskell'. Instead of that,
it should only dire
Am Freitag, 8. Dezember 2006 21:08 schrieb Ian Lynagh:
> This will probably have been made with whatever OpenGL was in darcs when
> the build was done (the binary distributions come from the nightly
> builds). [...]
OK, so in a nutshell: Everything is fine with the binary releases, it can just
be
Am Donnerstag, 7. Dezember 2006 11:37 schrieb Christian Maeder:
> The archive
> http://www.haskell.org/ghc/dist/6.6/ghc-6.6-src-extralibs.tar.bz2
> does not contain the files ControlPoint.hs and Domain.hs from directory
> libraries/OpenGL/Graphics/Rendering/OpenGL/GL/
If I see things correctly, th
Am Mittwoch, 29. November 2006 19:29 schrieb Joe Jones:
> [...] Anyone know of any issues with the current HOpenGL on Intel? [...]
The Haskell versions of the NeHe tutorials work for me on x86_64 openSUSE 10.1
(GHC 6.6 and bleeding edge GHC from darcs repo, perhaps a few weeks old), so
I guess t
Am Samstag, 28. Oktober 2006 19:41 schrieb Deborah Goldsmith:
> [...] Since it failed at the gcc stage rather than the ghc stage, I don't
> think that it's that the package wasn't installed. I think something
> about the way the distribution was put together is wrong. [...]
The diff you've sent ea
Am Mittwoch, 23. August 2006 15:23 schrieb Bulat Ziganshin:
> [...]
> i think that better way is to supply non-core libs in source form and
> just recompile them in this case. so, [...]
Nice theory, but this doesn't work at all in practice: The majority of the
packages mentioned so far are not pu
Am Donnerstag, 24. August 2006 11:29 schrieb Juan Rodríguez Hortalá:
> [...]
> And the later is about HOpenAL. Some information is found in
> http://www.haskell.org/HOpenGL/newAPI/index.html , on the entry for
> Sound, but I wonder if there is some tutorial or additional
> documentation anywhere. [
Am Freitag, 5. Mai 2006 09:13 schrieb Simon Peyton-Jones:
> The most straightforward thing to do is not to build the OpenAL package.
> I'm sure Sven is working on fixing it, but meanwhile it's entirely
> inessential. Simply edit the libraries/Makefile.
I've already fixed the ALUT package, but I'd
Am Sonntag, 30. April 2006 10:15 schrieb Bulat Ziganshin:
> may be it's not too late to just rerelease GHC? especially if hooks
> interface in current cabal version don't planned to change in
> foreseeable future. having common cabal interface for 6.4.2 and 6.6
> will be a great thing
I think that
I thought the new version handled
> compatibility with different versions of the OpenAL library better
> (indeed that's why it was updated), but it appears not. I'm hoping Sven
> Panne, the author of OpenAL, will be able to shed some light.
*sigh* It looks like if the OpenAL packa
Am Montag, 27. März 2006 20:56 schrieb Wolfgang Thaller:
> >C -> adjustor -> stub -> Haskell -> stub -> adjustor -> C
> >
> > It could be the case that the adjustor tail-jumps to the stub, but
> > this is not
> > guaranteed to be the case for all platforms.
>
> Hmmm, I thought it was.
> [...]
>
Am Montag, 27. März 2006 14:27 schrieb Brian Hulley:
> [...] For example, in:
>
>foreign import ccall "wrapper" mkIO :: IO () -> IO (FunPtr (IO ()))
>foreign import ccall set_callback :: FunPtr (IO ()) -> IO ()
>foreign import ccall run :: IO ()
>
>foo1 :: IO ()
>foo1 = do
>
Am Samstag, 25. März 2006 20:00 schrieb Brian Hulley:
> I've found a workaround to the problem below: instead of trying to use
> hs_free_fun_ptr, I instead pass a FunPtr to the Haskell function
> freeHaskellFunPtr into my DLL, and use this to free everything, finally
> using it to free itself (!) w
Am Mittwoch, 15. März 2006 18:16 schrieb Duncan Coutts:
> On Wed, 2006-03-15 at 17:01 +, Brian Hulley wrote:
> > The above two things were what I was expecting the compiler to do for me
> > instead of me having to manually write a wrapper function in Haskell
> > using withForeignPtr for each wr
Am Donnerstag, 9. März 2006 08:46 schrieb Bulat Ziganshin:
> Thursday, March 9, 2006, 2:20:00 AM, you wrote:
> >> foreign import ccall duma_init :: Int -> IO Int
>
> MQK> HsInt duma_init(HsInt arg);
> MQK> Or use int on the C side and CInt on the Haskell side.
> MQK> fromIntegral can be used for co
Am Freitag, 16. Dezember 2005 12:20 schrieb Malcolm Wallace:
> I've been looking at the cvs configuration file CVSROOT/modules.
> I /think/ the procedure is something like changing this:
>
> nhc98src-d nhc98 nhc98
> nhc98libraries -d nhc98/src/libraries fptools/libraries
Am Dienstag, 6. Dezember 2005 17:42 schrieb Simon Marlow:
> [...]
> Developers with an account on cvs.haskell.org: please add yourselves as
> users on the Trac, so I can give out permissions to edit tickets. You
> create a user like this:
>
> - log in to cvs.haskell.org
> - htpasswd /srv/trac/
Am Samstag, 3. Dezember 2005 15:17 schrieb Lennart Augustsson:
> And on many platforms (well, at least a few years ago) a "shared"
> library doesn't have to be PIC. The dynamic loader can do relocation
> when it loads the file. (Then it can't be shared.)
>
> But this was a few years ago on Solari
Am Samstag, 3. Dezember 2005 14:48 schrieb Lennart Augustsson:
> Can't you unpack the ar library and then link the object files
> into a shared library?
On most platforms the code in a *.a library is not shared library code, e.g.
it is not PIC or something like that. Nevertheless, I think that th
Am Freitag, 25. November 2005 14:38 schrieb Simon Marlow:
>[...] If you want to make it clearer, then add new CPP symbols
>
> WIN32_UNICODE_FILENAMES
> WIN32_64BIT_OFFSETS
>
> these can be set based on mingw32_HOST_OS for now, but it leaves the
> possibility of using autoconf later. [...]
Perf
Am Montag, 21. November 2005 13:01 schrieb Bulat Ziganshin:
> [...]
> #ifdef mingw32_HOST_OS
> type CFilePath = LPCTSTR
> type CFileOffset = Int64
> withCFilePath = withTString
> peekCFilePath = peekTString
> #else
> type CFilePath = CString
> type CFileOffset = COff
> withCFilePath = withCString
>
Am Freitag, 14. Oktober 2005 11:28 schrieb Duncan Coutts:
>[...]
> Well for the special case of the SOE library I have a re-implementation
> of it based on Gtk+/cairo which should work on all platforms. [...]
Which additional stuff would one have to install on an e.g. off-the-shelf SuSE
Linux dis
Am Sonntag, 4. September 2005 16:26 schrieb Dominic Steinitz:
> Can anyone tell me why ghci has this problem whereas ghc itself doesn't and
> how I fix it.
>
> Thanks, Dominic.
>
> [EMAIL PROTECTED] LAMH]$ ghci -package hsql-mysql
>___ ___ _
> / _ \ /\ /\/ __(_)
> / /_\// /_/ / / |
[ redirecting to the hopengl list... ]
Am Dienstag, 12. Juli 2005 14:32 schrieb Felix Breuer:
> What is the recommended way to render fonts (i.e. text) using GHC and
> OpenGL?
>
> I know about libraries/GLUT/examples/RedBook/Font.hs, but I do not want
> to define the font's letter by hand. So, my
Ian Lynagh wrote:
[...] Is there an equivalent of this (the no-OpenGL bit):
$(MAKE) prefix=`pwd`/debian/tmp/usr install GhcLibsWithOpenGL=NO
GhcLibsWithGLUT=NO
that still works or do I have to do it by hand?
The OpenGL/GLUT/OpenAL packages (and a few others) are enabled automatically
if the ri
Wolfgang Thaller wrote:
[...] *) static constructors/destructors
Sometimes there are pieces of code that expect to be called before
main() or at program termination. The GHCi Linker doesn't support this,
so some code may crash because things haven't been initialised properly.
This will definitely
Simon Marlow wrote:
They don't look too bad to me... a bit far to the right, perhaps, but
not too bad. Perhaps some lines in that table would help, or
alternating grey/white background for the rows? [...]
What I mean with "drunk" can be seen here:
https://aedion.de/haskell/haddock.png
It's slig
Simon Marlow wrote:
On 22 February 2005 19:37, Duncan Coutts wrote:
Excellent! Thanks a lot.
Any hint as to when the next Haddock release will be?
Maybe when I've got this GHC release out of the way and my hair has
grown back :-S
Before we do a release, I think two issues should be solved IMHO:
Akos Korosmezey wrote:
When I compile a simple code importing Control.Monad.State with
ghc-6.4.20050217 on Linux I get linking errors: [...]
You have to use "-package mtl" when "--make" is not used, because mtl (where
Control.Monad.State resides) is not an auto package, for more details see:
h
Remi Turk wrote:
[...] When using the following command-line
CC=gcc3 CXX=g++3 nice ./configure --enable-hopengl --prefix=/var/tmp/ghc
--with-gcc=/usr/local/bin/gcc3
[...]
Slightly off-topic: You don't need --enable-hopengl anymore when compiling
GHC 6.4 or the
CVS HEAD, the OpenGL/GLUT/OpenAL pac
This should be fixed now. The fastest way to a working installation is to
simply update the toplevel "mk" directory, remove all "package.conf.installed"
files, and do a "make install".
Cheers,
S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-u
Alson Kemp wrote:
[...] I'm trying to build cvs-HEAD and am having problems. The build
completes just
fine, but the built GHC 6.3 does not include the "-I" include directories
option for GCC. [...]
I've just stumbled over exactly the same problem in this second, and I'm
already investigating wha
[EMAIL PROTECTED] wrote:
Okay, I've tried to follow the directions, and ran into a couple minor issues I
was able to work through, but I got stuck at the "cd H/libraries && make boot &&
make" stage. The host system is redhat enterprise linux 3, the target is hp-ux
11.11, the output is below: [...]
Peter Simons wrote:
[...] It might be good to remove the file in the "clean" or
"distclean" targets, IMHO. I also noticed that
ghc/utils/ghc-pkg/.cvsignore lists it as an ignorable file,
which is why "cvs update" didn't show anything.
Hmmm, removing countably infinite files which don't belong to th
Peter Simons wrote:
When building the current CVS HEAD with ghc-6.2.2 on
Linux/x86, I get this error:
[...]
It seems that ParsePkgConfLite.hs omits the "Distribution"
part when importing Distribution.Package.
Hmmm, there is no ParsePkgConfLite.hs in the HEAD anymore. Perhaps you have
some old cruf
Simon Marlow wrote:
[...] I doubt it'll be trivial - probably lots of
#ifdef mingw32_TARGET_OS
will need to change to
#if defined(mingw32_TARGET_OS) || defined(cygwin_TARGET_OS)
[...]
Hmmm, having some fragile OS-dependent #ifdefs is not the way to go.
While you are there, every
#ifdef
Keean Schupke wrote:
Nope there are some unix resources that c exit routines do not free
like semaphores.
Which library/OS calls do you mean exactly? I always thought that files
are the only resources surviving process termination.
Cheers,
S.
___
Glasg
Abraham Egnor wrote:
I've found that when writing an interface to a C library that requires
resource management, it's much better to use the withX (see
Control.Exception.bracket) style of function than to use finalizers -
programs are much easier to reason about and debug.
... and have a much more
Keean Schupke wrote:
[...]
Whatever happens I think it must make sure all system resources allocated
by a program are freed on exit - otherwise the machine will have a resource
leak and will need rebooting eventually.
That's an OS task IMHO, not really the task of an RTS. Looks like you're
working
Peter Simons wrote:
Linux x86, I configure my build with the script:
| #! /bin/sh --
|
| GHC="ghc-6.2.2"
| SUBDIRS="alex ghc haddock happy hslibs libraries"
|
| for n in ${SUBDIRS} .; do
| echo >$n/mk/build.mk "XMLDocWays := html"
| done
|
| autoreconf -i
| ./configure --prefix=/usr/lo
Duncan Coutts wrote:
[...] The advantage of doing this is that it makes things easier for the
package managers. Each individual file can belong to the appropriate
package and so instead of having to execute registration/unregistration
actions on install/uninstall it's just another file to add/remov
Peter Simons wrote:
And some more information on the issue. When I run the
configure script, I see this error message on the screen
(which probably won't make it into the config.log output):
| checking for xmllint... /usr/bin/xmllint
| checking for DocBook DTD... ok
| checking for xsltproc... /u
l) when x does not correspond
to a
real number.
| -----Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Sven Panne
| Sent: 08 August 2004 17:02
| To: Hal Daume III
| Cc: GHC Users Mailing List; Malcom Wallace
| Subject: Re: Double -
Peter Simons wrote:
The CVS version of the libraries tree comes with all kinds
of neat and dangerously unstable code I'd like to use,
particularly the "arrows" subdirectory. Now I wonder: Is
there some "build.mk" magic I could perform to tell GHC to
build these libraries as part of my normal build?
Gregory Wright wrote:
Did the file ghc-6.2.2.tar.bz2 get changed without the version number being
changed? The md5 sum of the files has changed, breaking the darwinports
and presumably the *BSD ports builds as well.
I didn't see any notice to the list, so I'm not sure if the change is
intentional,
Tom Davie wrote:
The darwin ports version appears not to be too happy just now...
[...]
/var/tmp//ccjMNPay.s: No space left on device
[...]
It looks like it's your disk which isn't too happy... :-)
Cheers,
S.
___
Glasgow-haskell-users mailing list
[EMA
Glynn Clements wrote:
Peter Simons wrote:
When I create a CString with Foreign.C.String.newCString, do
I have to 'free' it after I don't need it anymore? Or is
there some RTS magic taking place?
How about Foreign.Marshal.Utils.new and all those other
newXYZ functions?
Yes. The new* functions alloc
Peter Simons wrote:
I have some trouble building ghc from CVS HEAD. I'm not sure
whether this applies to the release candidate version, too,
Nope...
but I figured I'd better report it anyway, just in case.
Fine, we like to hear about bugs... :-}
1) The build fails:
My fault, already fixed.
2) "m
Hal Daume III wrote:
[...]
Prelude Foreign.C> (0 :: CDouble) / 0
NaN
Prelude Foreign.C> (0 :: Double) / 0
NaN
Prelude Foreign.C> realToFrac ((0 :: Double) / 0) :: CDouble
-Infinity
yikes! the NaN got turned into a -Infinity!!!
aside from manually checking for 'strange' Double/CDouble values and
w
MR K P SCHUPKE wrote:
[...] It just tidies up a few long instances.
... and results in far better documentation when Haddock is used. That's just
another use for the oh-so-ugly cpp. :-] A small excerpt from my OpenGL
binding:
-- OpenGL/include/HsOpenGLTypes.h
Carsten Schultz wrote:
Wouldn't that make
getSocketOption :: Socket -> SocketOption -> IO Int
a bit strange? How would you propose to change it?
Possible, but also possibly overkill, would be:
newtype Debug = Debug Bool
newtype SendBuffer = SendBuffer (Maybe Int)
[...]
class SocketOption a where [
Simon Peyton-Jones wrote:
We've no idea what to do here. In your case it'd be possible to just
ignore the script, but presumably not so in general. [...]
I've just made a quick test on my SuSE 9.1 Linux and it seems to be the
case that an explicit "-lpthread" is not necessary anymore, even for
pro
Stefan Reich wrote:
[...] The program crashes every time I run it (Windows XP this time, but
I assume that doesn't make a difference).
Hmmm, it works with GHC 6.2.1 and the one from the HEAD on my x86 Linux box.
Perhaps something WinDoze-related, I don't know => SimonM...
Cheers,
S.
[ I'm cross-posting this, perhaps some kind soul has binary snapshots available. ]
Yann Morvan wrote:
[...] I recently installed the last version of GHC (6.2.1) that comes
with the new OpenGL binding. I was just starting to port my code to it,
but I have trouble finding some basic functionnalities
Duncan Coutts wrote:
On Mon, 2004-04-26 at 18:49, David Brown wrote: [...]
toUTF :: String -> String
Hmmm, "String -> [Word8]" would be nicer...
fromUTF :: String -> String
... and here: "[Word8] -> String" or "[Word8] -> Maybe String".
Furthermore, UTF-8 is not restricted to a maximum of 3 bytes
Jan Christiansen wrote:
[...] Sadly defining the dependencies didn't solve the problem. I get
this error message:
Preprocess/PhilsLine.o(.text+0x13e): In function `s2We_entry':
: undefined reference to `CHDziBaseTypes_CodePosition_con_info'
Preprocess/PhilsLine.o(.text+0x25e): In function `s2W6_ent
Jan Christiansen wrote:
I try to generate a package out of some haskell sources. Everything looks to
work fine but when I try to compile a program using this package I get a
linking error. It reports "undefined reference" to seemingly everything that
is accessible form outside the package. I'm u
Stefan Reich wrote:
Problem 1: -hr crashes in some circumstances. [...]
No idea about this one...
Problem 2: hp2ps doesn't work at all. [...]
That's a little bit harsh. :-) First of all it's not hp2ps, but GHC's RTS
which has a buglet. Furthermore, it only has this problem in some locales.
As a wo
Hans Nikolaus Beck wrote:
[...] I've readed tha writeIORef (and readIoRef etc) is used to write directly
to memory places fo implementing variables, as in example in HOpenGL used. Is
this also Haskell standard ?
Huh? I'm not sure what you mean exactly, but with the help of unsafePerformIO
and a pra
Just a short note from my side: I've tested both the branch (not the
.tar.bz2) on x86 Linux and the .msi on Win2k. Both seem to work fine...
Cheers,
S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/gla
1 - 100 of 214 matches
Mail list logo
