Re: ghc-6.6 candidate Win32 installer
On 14.10 10:20, Ross Paterson wrote: > On Fri, Oct 13, 2006 at 04:05:49PM -0700, Sigbjorn Finne wrote: > > Afraid I have to disappoint you (again :-( ) wrt OpenAL/ALUT. A bit > > too late, but _if_ there's a wider agreement that including a > > package such as this would be generally useful, I'd be happy to > > do something about it the next time around. > > > > cabal-get + hackage.haskell.org really ought to be the distribution > > channel for not-quite(-yet?)-mainstream packages though. > > That would be fine for pure Haskell packages (when hackage is ready), > but Cabal can't handle packages that require non-trivial configuration > (like OpenAL and ALUT) on Windows without MSYS. If people are interested I have NSIS scripts that make it trivial to create windows binary installers for many Haskell packages (for GHC). I would be interested in creating a repository of windows binary packages but I lack the space for hosting such a thing. - Einar Karttunen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: small errors in ghc 6.6
On 19.09 21:28, Tomasz Zielonka wrote: > On Tue, Sep 19, 2006 at 09:13:56PM +0200, Rene de Visser wrote: > > I would suggest -fforce-recomp for force recompilation. > -frecompile-all - Einar Karttunen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Replacement for GMP: Update
On 10.08 11:16, Peter Tanski wrote: > Paragraph 6 of the OpenSSL (1998-2005) license states that: > > * 6. Redistributions of any form whatsoever must retain the following > *acknowledgment: > *"This product includes software developed by the OpenSSL Project > *for use in the OpenSSL Toolkit (http://www.openssl.org/)". > > All developers would have to do is include the acknowledgment stated > above. I think this is not bad for specific applications, but forcing this upon all code compiled by GHC would be bad. I think the compiler should not link applications by default to things that force license related things. I think this is one reason GMP is being replaced. ps. personally I don't think the advertising clause is bad, but I think it is bad to force it on other users. - Einar Karttunen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building ghc-6.4 on Solaris x86
On 29.04 17:47, Georg Sauthoff wrote: > Hi, > > I am trying to build ghc-6.4.2 under solaris x86 (10.0). Hello A few months ago physrules ported GHC 6.4.1 to solaris x86. There were a few problems (and the tarball does not have the install target fixed), but the binary should work. Hopefully this can help you further. No guarantees. http://www.cs.helsinki.fi/u/ekarttun/physrules/ghc-6.4.1-i386-unknown-solaris2.tar.bz2 - Einar Karttunen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC6.5 + TH + Profiling
Hello I am having problems combining TH and profiling with ghc-6.5.20060420. GHC seems to die when loading the object file for TH execution and failing to notice that it should load profiling symbols. The exact error is: Loading package base-1.0 ... linking ... done. Loading package template-haskell-1.0 ... linking ... done. Loading package mtl-1.0 ... linking ... done. Loading package stm-1.0 ... linking ... done. ghc-6.5.20060420: .haskell_cache/http_searchpath.org-default.map.cache//HAppS/Util/StdMain/StartStateTH.o: unknown symbol `entering_PAP' I can create a simpler example of this if needed. - Einar Karttunen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: using ghc with make
On 20.04 12:06, Bulat Ziganshin wrote: > my Streams library mainly consists of two parts - Streams and > AltBinary. The streams part implements Handle-like interface > (including such functions as vGetChar, vGetByte, vPutBuf, vSeek and so > on) for various data sources - files, memory buffers, pipes, strings. > m/m files support is planned but now has just preliminary > implementation Having these as separate would be very nice. I think that a separately packaged AltBinary would be much easier to use for many people rather than force a dependency on the rest of Streams. - Einar Karttunen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.5 error? Illegal polymorphic or qualified type
Hello Here is a short example of the GHC 6.5 problem: type AnyE a = forall err. Either err a foo :: Monad m => AnyE (m t) foo = undefined Works with older versions of GHC 6.5, but newer versions fail with the: Illegal polymorphic or qualified type: forall err. Either err (m t) In the type signature for `foo': foo :: (Monad m) => AnyE (m t) - Einar Karttunen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: new i/o library
On 27.01 13:10, Bulat Ziganshin wrote: > i'm now write some sort of new i/o library. one area where i currently > lacks in comparision to the existing Handles implementation in GHC, is > the asynchronous i/o operations. can you please briefly describe how > this is done in GHC and partially - why the multiple buffers are used? One simple optimization is that you can omit all buffering with unbuffered operation. Then simply add the buffer (which is ok because Handles are mutable) if the user ever calls hLookAhead. > moreover, i have an idea how to implement async i/o without complex > burecreacy: use mmapped files, may be together with miltiple buffers. > for example, we can allocate four 16kb buffers. when one buffer is > filled with written data, the program unmaps it and switches to use > the next buffer. i don't tested it, but OS can guess that unmapped > buffer now should be asynchronously written to disk. the same for > reading - when we completely read one buffer, we can unmap it, switch > to the second buffer and map the third so that the OS can > asynchronously fill the third buffer while we are reading second. > should this work, at least on the main desktop OSes? Please no. There are multiple reasons to avoid mmapped files. 1) They make very few performance guarantees for reading (i.e. a Haskell thread touches memory which has not yet been read from the file causing IO and all the other Haskell threads are blocked too) 2) The time of writes is unpredictable making implementing a hFlush harder? (not sure about this) 3) Not all file descriptors will support it - i.e. we will need the read/write path in any case. 4) Mmap cannot be used for random access for arbitrary files since they may be larger than the address space. This means some kind of window needs to be implemented - and this is easily done with read/write. - Einar Karttunen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: storing highly shared data structures
On 22.12 14:43, Christian Maeder wrote: > How can I detect this sharing in order to avoid traversing the very > same symbol table for every symbol? By using System.Mem.StableName SerTH (http://cs.helsinki.fi/u/ekarttun/SerTH/) implements this, so you can look at the source for pointers. > I've tried to use a "Map (Ptr ()) ShATerm". So before traversing an > object I look up its address and check if is was traversed before (if > not I traverse it and store it in my map for future lookups). GHC can move the objects in memory. > 2.) A single "Map (Ptr ()) ShATerm" does not work! It seems that > sometimes objects are shared that have different types (as tests > revealed). This seems obvious for newtypes but also happens (I think) > without newtype declarations. Yes, this is quite evil. For example the empty list can be shared across type boundaries. Also phantom types can share the same address. In addition you have to worry about libraries using unsafeCoerce# > So, I'm now thinking if I should try using the type of my data as key > as well, i.e. using "Map (TypeRep, Ptr ()) ShATerm" to avoid duplicate > traversals. TypeRep is not Ord iirc, which makes this harder. Of course you can show it and then use that. - Einar ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Preferred way of submitting patches
Hello What is the preferred way of submitting patches at the moment? I tried using Trac but it seems that users without an account on haskell.org cannot attach files... Is using Trac and linking to the patch hosted externally the way to go? - Einar Karttunen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-6.4.1: panic - Prelude.last: empty list
Hello I am having problems with GHC 6.4.1 dying with the message: ghc-6.4.1: panic! (the `impossible' happened, GHC version 6.4.1): Prelude.last: empty list The source is nontrivial and contains template haskell. The error seems to appear after byte code generation. The log of the compile with -v9 is at the address below: http://cs.helsinki.fi/u/ekarttun/haskell/log.txt Is there anything else I should do to isolate the error better? - Einar Karttunen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in placing _stub.o files with HEAD
"Simon Marlow" <[EMAIL PROTECTED]> writes: > I thought I fixed this in CVS recently (rev. 1.54 of > Distribution.Simple.Build to be exact). Are you running Cabal from CVS, > or some other version? Cabal from CVS. The versions are GHC 6.5.20050728 and Cabal-1.1.2. I created a small Cabal package to demonstrate the problem. http://www.cs.helsinki.fi/u/ekarttun/haskell/test-hs-source-dirs-w-fexp.tar.gz The _stub.o file is not added into the static library. - Einar Karttunen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Bug in placing _stub.o files with HEAD
Hello I noticed the following behaviour using GHC 6.5.20050728: If compiling a Cabal package containing hs-source-dirs it places the _stub.o under dist/build//path/to/Module when Cabal expects it in dist/build/path/to/Module. Things appear to work without hs-source-dirs. For example with "hs-source-dirs: src" Network/GnuTLS/IOWrap.hs contains foreign export declarations. runnning Setup build creates the files: dist/build/src/Network/GnuTLS/IOWrap_stub.o src/Network/GnuTLS/IOWrap_stub.h src/Network/GnuTLS/IOWrap_stub.c But Cabal fails to include the IOWrap_stub.o as it is expected as dist/build/Network/GnuTLS/IOWrap_stub.o - Einar Karttunen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: schedule: re-entered unsafely - with heavy concurrent load
"Simon Marlow" <[EMAIL PROTECTED]> writes: > I fixed a bug that might cause this in the last couple of days. Could > you try again with a fresh build and let us know if the problem still > occurs? Seems to work without problems on 6.4.20050218. GHC seems to improve faster than one can spot problems :-) - Einar Karttunen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
schedule: re-entered unsafely - with heavy concurrent load
Hello
I am having problems with the threaded rts (6.5.20050207)
dying with 'schedule: re-entered unsafely'. The same code
seems to work with 6.2.2 with threaded rts.
The exact error message is:
"foo: schedule: re-entered unsafely.
Perhaps a 'foreign import unsafe' should be 'safe'?"
I originally notices the problem with networking code which
didn't use any of Network (nor threadWaitX). However the error
appeared even with the standard libraries tipping in the direction
of a bug in the rts.
The code works most of the time, but has a small probability of
failing when load is high. The test case implements a dummy web
server which can be tried with e.g. apache benchmark (ab),
/usr/sbin/ab2 -c 1000 -n 5000 127.0.0.1:8080/foo
usually crashes the code when run a few times.
The code should be compiled and run as
ghc --make -threaded foo.hs -o foo && ./foo 8080
import Network
import Control.Concurrent
import qualified Control.Exception as E
import System
import System.IO
main = do [port] <- getArgs
server port
server port = do
s <- listenOn $ PortNumber $ fromIntegral $ read port
acceptLoop s
acceptLoop sock = do
(csock,_,_) <- accept sock
forkIO (handle csock `E.catch` print)
acceptLoop sock
handle sock = do
hPutStr sock "HTTP/1.0 200 OK\r\nContent-Type: text/plain\r\n\r\n"
hPutStr sock ("This is the body for the request to\n"++"hope you like
this.\n\nnow garbage:\n")
hClose sock
- Einar Karttunen
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Newbie question
Dmitri Pissarenko <[EMAIL PROTECTED]> writes: > a) asking the user to enter several numbers (while the end of the sequence is > indicated by entering 0) > b) calculate the sum of those numbers. > > ... > Here is a corrected version: > module Main where > > import IO Delete this. > main = do > hSetBuffering stdin LineBuffering This is extraneous - stdin should be line buffered by default. > words <- askForNumbers > printWords words > map read words > putStrLn "The sum is" > foldl (+) 0 words Here you map read over words and discard the result. Then you wold over the words and produce an interger, whereas you should produce an IO value from the do block. Here is a complete implementation (untested): main = do words <- askForNumbers mapM_ putStrLn words putStrLn "EOL" let nums = map read words print nums putStrLn "The sum is" print (foldl (+) 0 nums) - Einar Karttunen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Emitting java bytecode?
Tomasz Zielonka <[EMAIL PROTECTED]> writes: > For example, some darcs users complain about problems with building > darcs on some exotic platforms (ie not Linux, OS X, Windows, FreeBSD). It > would > be nice if it was possible to distribute a .jar file for all such > platforms. Perhaps making -keep-hc-files a bit more documented would be one solution. Adding a feature to Cabal for building a tarball of .hc files generated from the haskell sources and a shell script for building the the library/executables from those. This could be faster and easier to implement than creating a version of the RTS running under the JVM. - Einar Karttunen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Terminal does not reset correctly with System.Console.SimpleLineEditor
Hello It appears that the console is not reset correctly with System.Console.SimpleLineEditor. The terminal does not echo characters until it is reset. The following program demonstrates it: import System.Console.SimpleLineEditor main = initialise >> getLineEdited "prompt> " >>= print >> restore This occurs with the Debian ghc package version 6.2.1 and the binary cvs snapshot of 20041017, both on i386 linux and in an xterm. - Einar Karttunen ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
