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
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
[email protected]
http://www.haskell.org
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
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
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-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
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
[email protected]
http:
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):
---
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-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
>
> [...] 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
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 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
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
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
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
[ 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-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
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-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-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
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
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-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
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
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
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
Am Fr., 31. Aug. 2018 um 11:11 Uhr schrieb Sam Halliday <
[email protected]>:
> [...] 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
Am Fr., 31. Aug. 2018 um 18:52 Uhr schrieb Ben Franksen <
[email protected]>:
> Am 31.08.2018 um 11:57 schrieb Sven Panne:
> > Am Fr., 31. Aug. 2018 um 11:11 Uhr schrieb Sam Halliday <
> > [email protected]>:
> >
> >> [...] It would make
Am Fr., 31. Aug. 2018 um 21:17 Uhr schrieb Brandon Allbery <
[email protected]>:
> 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
[ 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 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
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 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 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 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 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
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
Simon Marlow wrote:
Generating a single unified index is entirely possible, given all the
.haddock files for the relevant packages. I'll try to get this into the
next version of Haddock.
But only as an option and/or addition, I hope...
2. Remove the split between "type/class index" and
"function
John Meacham wrote:
[...] ;ghc -W -fglasgow-exts Foo.hs
The current HEAD version (no idea about the release branch) of ghc correctly
says:
Foo.hs:1:
Warning: Module `List' is imported, but nothing from it is used
(except perhaps instances visible in `List')
Foo.hs:7: Warning: Defi
Jeremy Shaw wrote:
I attempted to build cvs head but it died with the following error:
/usr/bin/ghc6 -H16m -O -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/specialise -istag
Volker Wysk wrote:
I've put together a minimal program which reproduces the problem. Save the
three attachments in a new directroy and type "make". I'ts just as
described earlier. The trivial program compiles with GHC5, but not GHC6. [...]
Hmmm, it looks like GHC is reversing the order of files in
Ashley Yakeley wrote:
Any word on whether this has been/will be fixed? [...]
Well, it's fixed in CVS for quite a while, but it's up to Simon^2 when a
new GHC release comes out.
Personally I'd favour tossing this "feature" altogether, [...]
Me too... :-P * * *
Cheers,
S.
___
John Meacham wrote:
I was wondering if:
case x of
"foo" -> Foo
"bar" -> Bar
"fuzz" -> Fuzz
"fuzo" -> Fuzo
x -> other .. thing
would optimize to
let z = other .. thing in
case x of
('f':x) -> case x of
('u':'z': x) ->
John Meacham wrote:
[...]
also, it would be good if config.h could be renamed to something like
ghc-config.h, because otherwise the conflict between the names can hide
bugs where you get the incorrect config.h or make it tricky to get at
the GHC one if it is actually the one you want.
That's defini
Any chance of a *.msi for the release candidate? A nightly *.msi would
be even better...
Cheers,
S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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
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
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
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
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
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.
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
[ 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
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
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 [
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
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
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
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
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
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,
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?
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:
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
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:
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
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
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:
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
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
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
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
[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: [...]
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
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
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
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
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:
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
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
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
[ 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
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
>___ ___ _
> / _ \ /\ /\/ __(_)
> / /_\// /_/ / / |
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 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, 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 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 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 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 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 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 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 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 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 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.
> [...]
>
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 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
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 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. [
1 - 100 of 214 matches
Mail list logo
