Re: ghci and ghc -threaded broken with pipes forking
On Thu, Mar 1, 2007 at 5:21 PM, Simon Marlow [EMAIL PROTECTED] wrote: In fact you should think of the non-threaded RTS as deprecated. It isn't Haskell'-compliant, for one thing (assuming that Haskell' will probably require non-blocking foreign calls). I'm hesitant to actually deprecate it, for a few reasons: the threaded RTS is so much more complicated, it might have some adverse performance impliciations, and there are still people who want to run everything in a single OS thread, for whatever reason. But having multiple variants of the RTS is a maintenance and testing headache. Had you deprecated the non-threaded RTS, we would probably have no problems described in ticket #2848 :-/ I think you'll have to deprecate it anyway, because it will be more and more difficult to maintain two versions of code, especially if one of them will be much less used and tested. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 RC debugger only breaking on first evaluation of a function
On Tue, Sep 18, 2007 at 02:26:38PM -0400, Olivier Boudry wrote: Hi all, I just tried the new GHCi debugger. A great new feature of GHCi 6.8.1. When debugging a function, as for example the qsort function given as an example in the 3.5 The GHCi Debugger documentation page, the debugger will only break on first function evaluation. As haskell is pure and lazy it's probably a normal behavior (reuse last result instead of recompute) but it's not very practical in a debugger. I tried to reload (:r) but it doesn't seems to help. Is there a way to force the function to be re-evalutated without quitting, starting, loading prog and setting breakpoints again, other than making the function part of the IO monad. ;-) If you don't find a better solution, then at least you can make it easier to perform the above sequence: $ cat ~/.ghci :def . readFile $ cat script :l Module :b 236 $ ghci GHCi, version 6.8.20070912: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude :. script [1 of 1] Compiling Module ( Module.hs, interpreted ) Ok, modules loaded: Module. Breakpoint 0 activated at Module.hs:236:20-45 *Module _ It should be quite easy to go a step further and generate breakpoint locations from markers in comments in the source file. Best regards Tomek ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.8.1 Release Candidate
On Thu, Sep 13, 2007 at 01:07:18AM +0100, Ian Lynagh wrote: We are pleased to announce the Release Candidate phase for GHC 6.8.1. Snapshots beginning with 6.8.20070909 are release candidates for 6.8.1 You can download snapshots from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.20070912-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.20070912-src-extralibs.tar.bz2 Seems there is a missing do in compiler/main/InteractiveEval.hs on line 334. Best regards Tomek ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GADT + Newtype deriving = Erroneous errors
On Mon, Mar 26, 2007 at 09:18:34PM -0700, Stefan O'Rear wrote:
[EMAIL PROTECTED]:/tmp$ cat A.lhs
{-# OPTIONS_GHC -fglasgow-exts #-}
data IsIntT x where IsIntT :: IsIntT Int
class IsIntC a where isInt :: IsIntT a
instance IsIntC Int where isInt = IsIntT
newtype Foo = Foo Int deriving(IsIntC)
I think newtype deriving should be rejected in this case. Maybe this is
the real problem here?
Best regards
Tomek
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Network.Socket endian problem?
On Thu, Dec 14, 2006 at 05:22:43PM +0100, Ferenc Wagner wrote: Tomasz Zielonka [EMAIL PROTECTED] writes: On Wed, Dec 13, 2006 at 03:54:59PM -0600, Mark Hills wrote: It does expect the address to be in network byte order instead of host byte order, which is usually done using htons and htonl. This seems to do what you want (running SUSE 10.1 on an Intel box): Who agrees with me that it would be nice if network libraries used host byte order in their interface? Or at least they could use an abstract data type, whose byte order would be unobservable. Why is this trapdoor present in the C library? I don't know. Maybe for efficiency? Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Network.Socket endian problem?
On Wed, Dec 13, 2006 at 03:54:59PM -0600, Mark Hills wrote: It does expect the address to be in network byte order instead of host byte order, which is usually done using htons and htonl. This seems to do what you want (running SUSE 10.1 on an Intel box): Who agrees with me that it would be nice if network libraries used host byte order in their interface? Or at least they could use an abstract data type, whose byte order would be unobservable. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bang patterns give fundamentally new capabilities?
On Thu, Nov 30, 2006 at 08:13:13PM -0800, John Meacham wrote: I was recently presented with the problem of writing a function like so seqInt__ :: forall a . a - Int# - Int# seqInt__ x y = x `seq` y which seems fine, except 'seq' of type forall a b . a - b - b cannot be applied to an unboxed value. I could not think of a way to actually get the behavior How about something like this: seqInt__ :: forall a . a - Int# - Int# seqInt__ x y = case x `seq` (I# y) of (I# y') - y' The question is: will GHC optimize out the unneccesary boxing and unboxing? Looking at the output from ghc -O2 -ddump-simpl makes me think the answer is yes. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: higher rank polymorphism
On Wed, Nov 15, 2006 at 01:20:43PM +0100, Jan Christiansen wrote: I want to use a rank 2 data type and end up in typ problems that I don't understand. I would really appreciate any hints to the presented cases or pointers to interesting papers that address the background of these problems. I define the following datatype and a simple function that checks whether the list is empty. data Test = Test (forall a . [a - a]) I would work, if you used existential quantification, but I am don't know if it would be what you want: data Test = forall a . Test [a - a] I don't know why you current code doesn't work - sorry. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Major type-class overhaul
On Fri, Nov 10, 2006 at 02:34:15PM +, Simon Peyton-Jones wrote: For some time I have been promising an overhaul of GHC's type inference machinery to fix the interactions between type classes and GADTs. I've just completed it (or at least I hope so). This message is just to summarise the programmer-visible changes, and to encourage you to give them a whirl. Of course, you'll need to compile the HEAD to do this; or get a nightly-build snapshot in a day or two's time. Simon, you are my hero! Seriously! :-) I am experimenting with this new improvement - it allows me to remove some ugly workarounds. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.FiniteMap
On Wed, Sep 20, 2006 at 02:54:57PM +0200, Christian Maeder wrote: This patch does not have the functions: foldFM_GE, fmToList_GE, keysFM_GE, eltsFM_GE, foldFM_LE, fmToList_LE, keysFM_LE, eltsFM_LE, It should be quite easy to do with split or splitLookup. Best regards Tomasz ___ 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 Tue, Sep 19, 2006 at 02:33:46PM +0400, Bulat Ziganshin wrote: 3. ghc 6.6 includes smart relinking capability which don't relink exe file if it already exists and .hs source files was not changed. that's great but ignores other .o files that can be also linked to program, for example those that was compiled from C sources: gcc -c -o a.o a.c ghc --make Main.hs a.o this command incorrectly don't relinks executable if a.c was changed but Main.hs wasn't The is another similar problem. Let's say I have an up-to-date compiled program and I want to recompile it with profiling turned on. In older ghc version adding -prof option caused all modules to be recompiled and the whole application relinked. Now I have to manually delete the application binary to force recompilation or use -fno-recomp. BTW. The -fno-recomp option has a very unintuitive name, at least for me. When I see -fno-recomp, my brain thinks no recompilation, meaning no unneccesary recompilation, which is what --make does by default. Using -fno-recomp causes all modules to be recompiled, whether they changed or not. I think one of -frecomp or -fno-recomp-checking would be much clearer. But it's probably too late to change that... Best regards Tomasz ___ 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 Tue, Sep 19, 2006 at 09:13:56PM +0200, Rene de Visser wrote: I would suggest -fforce-recomp for force recompilation. I like it. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.6 Release Candidate
On Fri, Sep 01, 2006 at 11:03:09AM +0100, Simon Marlow wrote: Please test as much as possible, bugs are much cheaper if we find them before the release! I was playing with impredicativity, when I got this strange error message: Prelude :l Imp [1 of 1] Compiling Imp ( Imp.hs, interpreted ) Imp.hs:15:17: Couldn't match expected type `forall a. (Show a) = a - String' against inferred type `a - String' Expected type: forall a1. (Show a1) = a1 - String Inferred type: forall a1. (Show a1) = a1 - String In the second argument of `putMVar', namely `(show :: forall a. (Show a) = a - String)' In the expression: putMVar var (show :: forall a. (Show a) = a - String) Failed, modules loaded: none. I am still trying to understand this extension, so my code probably makes not much sense, but it's alarming that the compiler cannot unify two types that are even equal. Maybe the bug is in the error message? Here is the code: module Imp where import Control.Concurrent main = do var - newEmptyMVar :: IO (MVar (forall a. Show a = a - String)) let thread x = do forkIO $ sequence_ $ repeat $ do f - takeMVar var putStrLn (f x) threadDelay 10 thread (1 :: Integer) thread abcdef putMVar var (show :: forall a. Show a = a - String) threadDelay 1000 I am using ghc-6.5.20060831 with -fglasgow-exts Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC-6.4.1 on FreeBSD-amd64 port progress
On Wed, Oct 26, 2005 at 06:57:50PM +, Wilhelm B. Kloke wrote: I am able to make the unregisterised .hc-bundle available on the net for other users wanting to install ghc on freebsd-amd64. I would be very grateful if you could make it available. Or is ist better to generate a new registerised .hc-bundle? Right now I simply want to build darcs, so an unregisterised should suffice. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: import prefers module in package over local module
On Wed, May 03, 2006 at 11:53:19AM +0100, Simon Marlow wrote: I'm afraid I don't understand: there's no Pretty module in the standard libraries, only Text.PrettyPrint. There is a Pretty module in the text package. It seems that Michael uses ghc -package text. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: IORefs and garbage collection
On Wed, Apr 19, 2006 at 01:56:25PM +0400, Bulat Ziganshin wrote: generational GC (at least one used in GHC) is better suited for functional (immutable) data. this conception by itself based on that new allocated data can contain references to old ones but not vice versa. minor GC algorithms scans only new data, if they don't contain any references to some data cell (in new data), then all the heap don't contain references to this cell and it can be freed. most of the data in normal Haskell program are immutable so this works fine. But most of the data is also lazy, and laziness in GHC is implemented with mutation. I wonder how does GHC's GC handle thunk update. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Getting GHC to print Done when it's finished linking?
On Tue, Mar 07, 2006 at 06:45:52PM -, Brian Hulley wrote: Is there any flag to get ghc or the ghc linker to print Done or something when it's finished? In unix you could wrap ghc in a script that would print Done if ghc finished successfully. I am sure you can do it somehow in windows. Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) (Linux || FreeBSD || math) for work in Warsaw, Poland ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to find out the C type signature corresponding to a Haskell function type in FFI?
On Tue, Mar 07, 2006 at 04:35:27PM -, Brian Hulley wrote: A third point is, how would I pass an arbitrary monad instead of just using IO? What for? IO is the monad that most closely matches the imperative, C semantics. That's why FFI only supports the IO monad (and pure functions). Other monads (you say arbitrary) may use rather complicated machinery to implement their semantics (HOFs, laziness, algebraic data types). I don't think it's a good idea to try implementing their actions in C (if that's what you want). Why do you need that? Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) (Linux || FreeBSD || math) for work in Warsaw, Poland ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Getting GHC to print Done when it's finished linking?
On Tue, Mar 07, 2006 at 06:54:50PM +, Neil Mitchell wrote: In unix you could wrap ghc in a script that would print Done if ghc finished successfully. I am sure you can do it somehow in windows. ghc --make Whatever if errorfail 1 goto failed echo Success :-) goto end :failed echo Failure :-( :end In unix/sh: #!/bin/sh ghc $@ echo Done Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) (Linux || FreeBSD || math) for work in Warsaw, Poland ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: optimistic evaluation
On Tue, Feb 07, 2006 at 08:28:51PM +, Frederik Eaton wrote: What is the status of Rob Ennals' optimistic evaluation work? I'm told that it has been removed from GHC. This is extremely depressing to me. Without such a feature available, it becomes very difficult to write programs that process large amounts of data in Haskell. In many such applications, strictness annotations become not just important for performance, but necessary to get a program to function at all. With optimistic evaluation, GHC and Haskell would have been at least potential candidates for my programming work in machine learning; without it I fear that this is no longer the case. Will optimistic evaluation ever be present in GHC again? What is its priority, compared to other features which are being implemented? What was the last (if any) version of GHC with optimistic evaluation present? I am not sure this is similar to optimistic evaluation, but I was wondering if it would be possible to find space-leaks at runtime and try to reduce them. There's also a related idea to decrease the priority of garbage producing threads (and/or increase for garbage reducing threads). This way it would be possible to make the idiomatic Haskell 'wc' (word count) implementation space efficient with some simple 'par' annotations: main = do cs - getContents let nChars = length cs nWords = length (words cs) nLines = length (lines cs) (nChars `par` nWords `par` nLines) `seq` return () print (nChars, nWords, nLines) (I am not sure I used par correctly, but I hope you know what I mean). Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) (Linux || FreeBSD || math) for work in Warsaw, Poland ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: optimistic evaluation
On Tue, Feb 07, 2006 at 09:52:49PM +0100, Tomasz Zielonka wrote: There's also a related idea to decrease the priority of garbage producing threads (and/or increase for garbage reducing threads). This way it would be possible to make the idiomatic Haskell 'wc' (word count) implementation space efficient with some simple 'par' annotations: main = do cs - getContents let nChars = length cs nWords = length (words cs) nLines = length (lines cs) (nChars `par` nWords `par` nLines) `seq` return () print (nChars, nWords, nLines) (I am not sure I used par correctly, but I hope you know what I mean). Intuitively, the three threads computing nChars, nWords and nLines would chase each other on the cs list. The thread that is causing bigger memory residency would get his priority lowered. At last it would be stopped and other threads would have a chance to consume what was produced. Thus longer and longer prefixes of cs could be reclaimed. But I am not sure it's possible to implement. One question is how to measure thread's impact on memory use. Counting allocations seems to be not enough. In our example, the nWords threads consuming what was produced by the nChars thread, would probably allocate at the same speed as nChars thread (it creates the word list), but it should get a higher priority. Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) (Linux || FreeBSD || math) for work in Warsaw, Poland ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: optimistic evaluation
On Tue, Feb 07, 2006 at 09:52:49PM +0100, Tomasz Zielonka wrote: ... I was wondering if it would be possible ... There's also a related idea ... I've heard that the implementation of optimistic evaluation was rather complex, which was the main reason not to include it in GHC (yet). That's why I wonder if there is some other low hanging fruit. Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) (Linux || FreeBSD || math) for work in Warsaw, Poland ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [STM] Better name for waitUntil?
On Fri, Dec 23, 2005 at 03:45:54PM -, Simon Marlow wrote: How about retryIfEarlierThan / retryIfLaterThan retryIfBefore / retryIfAfter I like making it clear that the operation behaves like retry given certain conditions. I like these proposals! Thanks! I think I prefer the retryIfBefore/retryIfBefore version. In a private email Simon Peyton-Jones proposed retryBefore / retryAfter. It's interesting that you think so similarly ;-) This also convinces me that these are the best names. I was going to release a cabal package with these functions a week ago, but life didn't allow me to. Stay tuned ;-) Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[STM] Better name for waitUntil?
Hello! I am finishing my waitUntil implementation for STM. It's a new STM action that will allow to wait for a given time point. waitUntil :: UTCTime - STM () (UTCTime is from Ashley Yakeley's Time library.) The intended semantics is that waitUntil t will succeed as soon as time passes t, or more precisely when (now = t). Right now I am to find a better name for waitUntil. Maybe it should be more declarative, like itsAfter or timeAfter? I am not a native english speaker, so I am probably missing many options. Any ideas? I also think about adding something like itsBefore, which would mean (now t). How about it'sAfter ? Maybe only after, without it's ? Thanks in advance for your help. PS. I imagine that it would be possible to implement waitUntil more efficiently in GHC's RTS, but my implementation can be a nice showcase for STM's expressivity, and it's still quite efficient (I used some (quite elegant :) hacks to implement subsecond precision waitUntil efficiently). Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [STM] Better name for waitUntil?
On Mon, Dec 19, 2005 at 09:34:19AM -, Simon Peyton-Jones wrote: waitUntil sounds like a plausible name. But how do I name itsBefore? dontWaitUntil? ;-) Better than itsAfter or timeAfter. But perhaps sleepUntil would be better, because it's a variant of sleep? Well yes, but an STM compatible one, so you can simultaneously waitUntil and try to read from channel, and you get whatever happens first. Also, the interface is entirely in STM - no need to initialize the timer in IO. Simon Marlow gave a nice example for usefulness of this: Interesting. You could use that do wait for idle time, for example: atomically $ do t - readTVar last_mouse_click waitUntil (t+1000) ... so this transaction only completes when some idle time has passed since the last mouse click. Let's assume I am going to implement itsBefore (seems to be quite straightforward), so I want a pair of opposite names. Some variations: itsAfter / itsBefore guardTimeAfter / guardTimeBefore waitUntil / ??? Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Optimizations for mutable structures?
On Wed, Dec 07, 2005 at 04:45:52PM +, Tony Finch wrote: The following paper seems relevant to this thread. Although it's written in the context of C and C++, it's relevant to any language that combines pre-emptive threads and imperative features. http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf I haven't read the whole paper yet, but I am not sure it applies to Concurrent Haskell. The paper is about introducing concurrency as a library to an imperative language. It seems to assume that the threads will communicate through ordinary variables modified in critical sections. But in Concurrent Haskell we don't modify ordinary variables (mutable variables don't exist in Haskell 98), but those supplied by the library. Citing the Concurrent Haskell paper: We give a semantics for Concurrent Haskell that is clearly stratified into a deterministic layer and a concurrency layer (Section 6). Existing reasoning techniques can be retained unmodified; for example, program transformations that preserve the correctness of a sequential Haskell program also preserve correctness of a Concurrent Haskell program. This is an unusual feature: more commonly, the non-determinism that arises from concurrency pervades the entire language. But can Concurrent Haskell be seen as a library? Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] GHC ignores RTS options
On Wed, Nov 16, 2005 at 01:09:07PM -, Simon Marlow wrote: BTW - it would be nice if it was easier to override the default RTS options when compiling the program. Perhaps a nice task for a newbie GHC developer? Already possible, see: http://www.haskell.org/ghc/docs/latest/html/users_guide/runtime-control. html#rts-hooks I was aware of this, and I should write about it. Admittedly it's a bit more fiddly than a command-line flag to GHC, though. And because of this I wrote that it would be nice if it was easier :-) I've bitten several times by the default values of RTS options, especially the stack size limit (-K). But it was always easier to set GHCRTS or use +RTS -RTS, so I never used the rts-hooks. Do you think I could do this? I am not sure how difficult it would be. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposal: Improved error message of Error in array index
On Tue, Nov 08, 2005 at 02:43:47PM +, Malcolm Wallace wrote: Of course, there is the old stand-by C pre-processor trick: #define superError(s) error (s++\nin file ++__FILE__ \ ++ at line ++__LINE__) There is a nice trick I saw in darcs' code to make this even more Haskellish: #define superError (\s - error (s++\nin file ++ __FILE__ \ ++ at line ++ show (__LINE__ :: Int))) so you can simply write: superError message Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Default name of target executable
On 10/14/05, Tomasz Zielonka [EMAIL PROTECTED] wrote: On 10/14/05, Simon Peyton-Jones [EMAIL PROTECTED] wrote: HEAD definitely. We don't change the specification of STABLE, only fix bugs. Great, I have the initial implementation, but I'll try to make it prettier. Here is the patch. Some notes: - I am not sure if it's OK to modify Session in this place. Perhaps my code should be called from DriverPipeline.staticLink, but it has no access to module graph, and I didn't want to make such a big change - I wanted to add .exe suffix on Windows, but if I think that GHC relies on mingw32 tools to add it when necessary. - There is some documentatin in separate_compilation.xml. I wrote about the ability to put Main in file other than Main.hs, but I couldn't find documentation for this feature. Tell me if there are other places where this feature should be mentioned. - I didn't check that docs are properly generated after my changes. Besides, the language can be incorrect. Best regards Tomasz patch Description: Binary data ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Default name of target executable
On 10/24/05, Tomasz Zielonka [EMAIL PROTECTED] wrote: Here is the patch. Again, with a small bugfix in docs. Best regards Tomasz patch Description: Binary data ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Cross-Compiling with GHC?
On 10/18/05, Rich Fought [EMAIL PROTECTED] wrote: GHC noob here, trying to compile a small app for a Linux/PPC target from a Linux/x86 host. If all else fails, try running PPC-Linux on Qemu on your Linux/x86 host. Who knows, this might even be the best solution? (I didn't try it though) Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Default name of target executable
On 10/11/05, Tomasz Zielonka [EMAIL PROTECTED] wrote: On 10/11/05, Simon Marlow [EMAIL PROTECTED] wrote: Ok, let's close this bikeshed. Someone want to send us a patch? I will try to do this On which branch of GHC should I be working? There are some differences between HEAD and STABLE in the relevant areas. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Default name of target executable
On 10/11/05, Simon Marlow [EMAIL PROTECTED] wrote: Ok, let's close this bikeshed. Someone want to send us a patch? I will try to do this, but I don't have a working PC at home at the moment. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Default name of target executable
On 10/10/05, Ketil Malde [EMAIL PROTECTED] wrote: Tomasz Zielonka [EMAIL PROTECTED] writes: Because of this long syntax and comand-line completion I've even once lost the source code. I forgot to remove the .hs at the end of line: $ ghc --make Prog -o Prog.hsIf you want, I can tell you about this great version control systemI'm using :-) It was before I acquired the habit to put even the smallest programs in darcs. And even if I did use darcs - I usually at least try to compile the new code before recording it. Anyway, this is not the biggest reason for my request. What bothers me more is typing the redundant command over and over again. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Default name of target executable
On 10/10/05, Simon Marlow [EMAIL PROTECTED] wrote: There's no really deep reason for this choice, other than it being what GHC does normally - i.e. the default binary has always been a.out (main.exe on Windows) unless -o is given. I don't see enough of a compelling reason to change it, sorry. It's not broken, just slightly inconvenient. It wasn't meant to be a bug report, only a feature request ;-) Actually, I was mostly interested if anyone would mind if GHC chose the name based on the top-level module. Would you accept the patch? Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Default name of target executable
On 10/10/05, Stephane Bortzmeyer [EMAIL PROTECTED] wrote: On Mon, Oct 10, 2005 at 11:40:21AM +0200, Wolfgang Jeltsch [EMAIL PROTECTED] wrote a message of 28 lines which said: Why don't you use a small shell script for this? Or better, a rule in the Makefile, with suffixes: %: %.hs ghc --make -o $@ $^ How about module dependencies? You would have to handle them in the Makefile (ghc -M?). I'm not saying it's difficult, but it's enough hassle that in case of small scripts I would still prefer to use ghc --make directly. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Default name of target executable
On 10/10/05, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Montag, 10. Oktober 2005 11:55 schrieb Niklas Broberg: [...] Using a shell script is a possible work-around, but certainly not *the* solution. If there is no real reason for ghc to spit out a.out files, then surely choosing the exe name from the main input file would simplify a programmer's life. And for applications that desperately want a.out, well, there's still the -o flag, right? Maybe the makers of GHC wanted GHC to be GCC compatible. With --make it could be more make compatible, ie $ ghc --make Prog woud be similar to $ make Prog Also, ghc --make Prog is not GCC compatible. Try running 'gcc Prog' when the source is in Prog.c Perhaps the new behaviour should be enabled when using Prog without the .hs suffix. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Default name of target executable
Hello! When I work on a program which is going to be named LongProgramName, I usually put the Main module in file LongProgramName.hs. It would be nice if I could build it with --make like this: $ ghc --make LongProgramName instead of $ ghc --make LongProgramName -o LongProgramName Does anyone rely on the first one producing a.out? Because of this long syntax and comand-line completion I've even once lost the source code. I forgot to remove the .hs at the end of line: $ ghc --make Prog -o Prog.hs Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: progress on Freebsd-amd64 (Was: .hc files for building ghc-6.4.1 on amd64 ?)
On 9/21/05, Wilhelm B. Kloke [EMAIL PROTECTED] wrote: Now I have an unregisterised ghc-inplace. What is the fastest way to testits usability? Great! Could you put it somewhere on the web? I have FreeBSD 5.4 here, and you? Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.4.1
On 9/19/05, Simon Marlow [EMAIL PROTECTED] wrote: The GHC Team is pleased to announce a new patchlevel release of GHC.This release contains a significant number of bugfixes relative to6.4, so we recommend upgrading.No library APIs have changed, so codethat was working with 6.4 should continue to work with 6.4.1. Good job! The program I was working on today runs 24% faster with 6.4.1 compared to 6.4 :-) Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: foldr f (head xs) xs is not the same as foldr1 f xs
On Sun, May 08, 2005 at 08:14:30PM +0200, David Sabel wrote: Hi! Subject: foldr f (head xs) xs is not the same as foldr1 f xs I think you forgot about tail: foldr f (head xs) (tail xs) Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: limited-scope retry?
On Thu, Apr 21, 2005 at 10:47:27AM -0400, Abraham Egnor wrote: Used in isolation, i.e. atomically $ writeTChan chan () atomically $ flush chan it works fine. However, when composed (atomically $ writeTChan chan () flush chan), it causes a race condition, usually resulting in deadlock, as the retry in flush replays the call to writeTChan as well. As long as you are in this transaction nobody will get from chan the element you just put there. Before the transaction commits, for the outside world it's like you've never called writeTChan. But inside the transaction you see a chan with an element that you've just written there. So within this transaction the chan has no chance to be emptied (unless you emptied it yourself). No point in waiting. As you say, it works in isolation. Use it this way. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Size of UArrays
On Wed, Mar 30, 2005 at 06:41:02PM +0200, Andreas Marth wrote: Hallo! I would like to know how big an UArray (100,100) Double is (approximately) in Bytes. I guess you mean: (accumArray const 0.0 ((1, 1), (100, 100)) []) :: UArray (Int, Int) Double It should take about 100 * 100 * 8 = 8 bytes . And how much heap will the program consume for it. (I mean does the garbage collector need this size, or double the size, or what?) About the same. I just checked that GHC allocates it as a big object, so the array isn't copied during GC. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static linking with ghc
On Sat, Mar 26, 2005 at 03:11:43PM +0100, Patrick Scheibe wrote: Is it possible to tell ghc to take all stuff out of the .so libs and compile my source to a all-including executable? I know that ghc just calls the linker which is doing this part. The --static flag for the linker just says: take the static library if possible for linking But I don't have a static version of these libs and I don't want to recompile all libraries. I often build my applications with ghc -optl-static, which works for me most of the time, but: - You need to have static (.a) versions of libraries, which you don't have - At least on linux the NSS (name service switch) libraries are linked in dynamically even in statically linked programs. If you have incompatible nss libraries, your programs may crash. The workaround is to compile glibc with --enable-static-nss - There are some licensing issues with GMP Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Haskell on Red Hat Enterprise...
On Thu, Mar 17, 2005 at 10:02:56AM -0500, Francois Meehan wrote: Hi all, I need Haskell to be installed on a Red advance server 3. Could not find RPM's for it. Tried compiling for tar file, won't pass the ./configure, giving me configure: error: GHC is required unless bootstrapping from .hc files. error. Could someone give me some pointers on how to do this? I was installing GHC 6.2.2 on RH AS r3 on x86 recently and the generic binary distribution for Generic Linux with glibc 2.3 worked fine. Just download it from the website, configure, make in-place, and you have a working GHC in 5 minutes. You can use this GHC to compile another, newer versions. There is a generic binary x86/Linux glibc 2.3 version of GHC 6.4 on the website too. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How can I make a counter without Monad?
On Wed, Mar 16, 2005 at 10:51:08AM +0100, Nicolas Oury wrote: Thanks for your help. Are there other ways to implement a counter in Haskell? Using a State monad? If I use your example on : test = let Node x l = enumeratedTree ( Node 'a' [undefined, Node 'b' []]) in tail l GHCI answers [Node (*** Exception: Prelude.undefined A monadic counter imposes an order of evaluation. In my program, I don't care about the order of the numbers. I only want them to be all different. I think a monad is too restrictive for what I need. OK, I understand. In this situation you probably want either splittable name supply. Let me get back to your first post... Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How can I make a counter without Monad?
On Wed, Mar 16, 2005 at 01:17:51AM +0100, Nicolas Oury wrote: * linear implicit parameters instance Splittable Int where split n = (2*n,2*n+1) But I have a problem : the counter value increases exponentially. (I can only count up to 32 elements...) Is there another way to split Int? You could use unbounded Integers, or forget about numbers and use lists of bits. newtype BitString = BitString [Bool] instance Splittable BitString where split (BitString bs) = (BitString (False : bs), BitString (True : bs)) Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How can I make a counter without Monad?
On Wed, Mar 16, 2005 at 01:17:51AM +0100, Nicolas Oury wrote: Greetings, In a program, I want to give a unique name to some structures. As it is the only imperative thing I need, I don't want to use a monad. You don't want to use the IO monad. Why not use some other monad? I have played with two solutions and have some questions : * unsafePerformIO : This is asking for trouble. You are using an IO monad in an unsafe way. Don't do it. * linear implicit parameters [...] Are there other ways to implement a counter in Haskell? Using a State monad? From some of my code: let enumeratedTree = (`evalState` (0::Int)) $ (`mapTreeM` t) $ \x - do n - next return (n, x) next = do a - get; put $! succ a; return a where mapTreeM :: Monad m = (a - m b) - Tree a - m (Tree b) mapTreeM f (Node a ts) = do b - f a ts' - mapM (mapTreeM f) ts return (Node b ts') (which could also be an instance of a popular non-standard FunctorM class) Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: environment variables for ghc
On Wed, Mar 09, 2005 at 10:01:40AM -0800, Frederik Eaton wrote: On Wed, Mar 09, 2005 at 05:19:18PM -, Simon Marlow wrote: On 09 March 2005 08:29, Frederik Eaton wrote: Oh, is that the only reason? That's a terrible reason to not have a feature. :) You could just write a 'ghcbug' script which includes all information automatically. See the output of 'perlbug -d' for example. I guess I could write a wrapper to add the options myself ... but is everybody supposed to do this who has a package.conf in their home directory, or some common set of utility modules somewhere? It seems like a fairly common use case that should be well-supported in a standard way out of the box. I was complaing (only to myself) that rsync doesn't allow to put some common options in ~/.rsyncrc or an environment variable. Then I simply added an alias in my .bash_profile: alias rsync='rsync -v --progress' Unfortunately, this is still something that developers would like to know when facing a bug report :) Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: environment variables for ghc
On Wed, Mar 09, 2005 at 10:27:28AM -0800, Frederik Eaton wrote: On Wed, Mar 09, 2005 at 07:03:38PM +0100, Tomasz Zielonka wrote: I was complaing (only to myself) that rsync doesn't allow to put some common options in ~/.rsyncrc or an environment variable. Then I simply added an alias in my .bash_profile: alias rsync='rsync -v --progress' Unfortunately, this is still something that developers would like to know when facing a bug report :) Right. Well, to get it to work from makefiles etc., I'd need to create a script in my path, something like #!/bin/sh ghc -i$HSPATH -package-conf $HSPKGCONF $@ And I'd call it ghc. The thing is, I'm arguing that enough people would do this that we should standardize on the environment variable names. Plus, yeah, as you point out, I could just as well forget to mention in a bug report that 'ghc' is my own special script. Why not simply do: #!/bin/bash /usr/.../ghc $GHCOPTS $@ ? I am still not convinced that it is a good idea to add such functionality to GHC. Do you want to persuade developers of every program you use to add similar feature? For the simple case of providing the same options everytime shell script wrappers and aliases are the way to go. There are more complicated case which justify extending a program in such way. For example, it is common that VCS's (like CVS, subversion and darcs) have a single executable with many sub-commands. You them in this way: $ cvs get ... $ cvs update ... $ cvs status ... You may want to provide different default options for different sub-commands. Possible to do with a shell script, but much, much more difficult. That's why at least darcs has a mechanism for setting default options for different sub-commands (~/.darcs/defaults or _darcs/prefs/defaults in a repo). Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: environment variables for ghc
On Wed, Mar 09, 2005 at 11:55:11AM -0800, Frederik Eaton wrote: I am still not convinced that it is a good idea to add such functionality to GHC. Do you want to persuade developers of every program you use to add similar feature? Is the perceived difficulty of that task an argument against improving ghc? No, it's about avoiding unneccesary complexity. I agree that the case you're presenting is indeed more difficult, but I don't think you're doing the estimations right for the one at hand. The cost and annoyance of perhaps tens of thousands of people adding and remembering to maintain wrappers named 'ghc' somewhere in their path to accomplish this simple task (after scrounging in the documentation to find that ghc for some reason fails to be like many other compilers, a nontrivial cost in itself since the lack of environment variables isn't specifically documented) - or simply not doing so, and typing in -package-conf hundreds of times as I have done, because they may not have write access to the main package.conf - I think outweighs the cost of one person, once, adding central support for environment variables, a bit of documentation in the man page, perhaps a ghcbug program if we want super-detailed bug reports... Are you volunteering to be that person? ;-) Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: environment variables for ghc
On Wed, Mar 09, 2005 at 01:12:49PM -0800, Frederik Eaton wrote: Are you volunteering to be that person? ;-) Are you saying that a patch would be accepted? I am not the one to decide. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Download stats
On Wed, Feb 09, 2005 at 01:11:34PM -, Simon Marlow wrote: Hi folks, For the forthcoming 6.4 release, we'd like to get a rough idea of download statistics, at least from haskell.org. Both Simon I are too busy/lazy (delete as applicable) to do this ourselves, and we don't know the best tools to use (grep|wc on the access_log is a bit too crude - we want to exclude things like partial downloads except when the download was completed later, etc.). Of course, if we can get or estimate download statistics for other sources of GHC too, that would be great. Any volunteers? Why not ask GHC users to fill some web form with additional information, like how they use GHC, where they use it, for what, etc? I can make a suitable web form in WASH, if you want. Best regards Tomasz -- Szukamy programisty C++ i Haskell'a: http://tinyurl.com/5mw4e ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Waiting on Sockets or File Descriptors
On Wed, Feb 02, 2005 at 05:58:58AM -0800, Peter Simons wrote: Tomasz Zielonka writes: threadWaitRead :: Int - IO () threadWaitWrite :: Int - IO () Thanks for the pointer! Am I correct in assuming that there is no more high-level mechanism for scheduling more than one file descriptor? This is the most high-level mechanism I can imagine. Like select(2) or poll(2) would do? You seem to what something low-level. I guess, I could implement it on top of those functions with some clever forkIO'ing, but I wonder whether that's particularly efficient? This translates to select() (or poll()), but yes, you'll pay some price for creating and scheduling Haskell threads. Best regards, Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Waiting on Sockets or File Descriptors
On Tue, Feb 01, 2005 at 03:16:44PM -0800, Peter Simons wrote: Hi, I have the following problem: I use an external library through the foreign function interface which gives me _several_ sockets and expects me to call it again when any of those sockets becomes readable or writable. Since I know that the Haskell run-time system has all the required functionality in place, I wonder whether there is any way to register these sockets in the internal scheduler and have it call an 'IO ()' function in case of such an event? What makes matters more complicated is that the _library_ owns these sockets -- not me. So I cannot really touch them or lift them into a 'Handle'. Any ideas? In GHC you can try with these functions from GHC.Conc: threadWaitRead :: Int - IO () threadWaitWrite :: Int - IO () Best regards, Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: recursive group context bug?
On Mon, Jan 17, 2005 at 09:52:18AM +, Keean Schupke wrote:
You cannot sequence two operations from different monads...
Note that this compiles:
module Bug where
{
p :: IO ();
p = q = id;
q :: (Monad m) = m (IO ());
q = return (return ()); -- the only change is in this line
}
Best regards,
Tomasz
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using Haskell with Java
On Fri, Jan 07, 2005 at 04:56:14PM +0100, Dmitri Pissarenko wrote: I would like to know whether it is possible to write algorithmic (let's call them back-end) parts of a system in Haskell and user interface in Java? If all else fails, you can simply split the program in two separate, communicating processes. Best regards, Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Emitting java bytecode?
Hello! Would be possible for GHC to emit Java bytecode? There seems to be some code in GHC's sources (in ghc/compiler/javaGen/) suggesting that it was anticipated. I suppose most of the work would be in making a java RTS and libraries. I am mainly interested in making GHC more portable. Haskell is a great application programming language, but there are some concerns about portability of applications. Perhaps I shouldn't be looking at java bytecode for a solution... Is it possible that a C-- backend will make GHC more portable? Best regards, Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Emitting java bytecode?
On Tue, Dec 21, 2004 at 10:41:01PM +0100, Arjan van IJzendoorn wrote: Hello Tomasz, I am mainly interested in making GHC more portable. Haskell is a great application programming language, but there are some concerns about portability of applications. What kind of concerns? 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. Best regards, Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: reading text files
On Mon, Oct 04, 2004 at 08:34:42PM +0200, Peter Simons wrote: hGetContents is fine, although you have to be aware that the function does not implement any timeouts. Meaning, if you don't receive the data you need, your program will hang. Whether your application is fast or not doesn't really depend on how you read the data, but on how you _process_ it. Simply counting the number of characters in input using getContents can be 6 times slower than doing the same thing using hGetArray (still doing unsafeRead for every character, even if it's not necessary for this particular task). So, hGetContents may not be the best solution if you care about performance, at least in GHC 6.2.1. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Bools are not unboxed
Hello! I was playing with monadic looping a'la replicateM_ and I created this function: for :: Int - IO () - IO () for 0 _ = return () for n x = x for (n - 1) x Compiled with -O2, it is really fast and makes no unnecessary allocations. Tested with this main main = for 1000 (return ()) it gives the following stats ghc: 1024 bytes, 0 GCs, 0/0 avg/max bytes residency (0 samples), 1M in use, 0,00 INIT (0,00 elapsed), 0,33 MUT (0,33 elapsed), 0,00 GC (0,00 elapsed) :ghc Cool! ( this is still 10 times slower than g++ -O3, but a similar pure function is only 3 times slower, and I am satisfied with such results (at this moment ;) ) Unfortunately, the program I was playing with could call 'for' with negative n, for which it was supposed to make 0 iterations, and this version definitely makes too many iterations. So I made another version: for :: Int - IO () - IO () for n x | n 0 = x for (n - 1) x | otherwise = return () To my surprise, it was much slower and made many allocations: ghc: 240927488 bytes, 920 GCs, 1036/1036 avg/max bytes residency (1 samples), 1M in use, 0,00 INIT (0,00 elapsed), 2,48 MUT (2,50 elapsed), 0,04 GC (0,05 elapsed) :ghc I checked in -ddump-simpl that Ints are getting unboxed in both versions. Then I noticed the cause: GHC.Prim.# returns a boxed, heap allocated Bool, and so do other primitive comparison operators. Would it be difficult to add Bool unboxing to GHC? Maybe it would suffice to use preallocated False and True? Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bools are not unboxed
On Sun, Oct 03, 2004 at 03:07:01PM +0200, Tomasz Zielonka wrote: Then I noticed the cause: GHC.Prim.# returns a boxed, heap allocated Bool, and so do other primitive comparison operators. Would it be difficult to add Bool unboxing to GHC? Maybe it would suffice to use preallocated False and True? I forgot about some questions: Do you think that many applications could benefit from such an improvement? IMO, yes, for example, there are many Int comparisons waiting for this optimisation in io, networking and posix libraries. But I am not sure how big would that benefit be in a non-toy application. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bools are not unboxed
On Sun, Oct 03, 2004 at 04:03:55PM +0200, Carsten Schultz wrote: Hi Tomasz! Hi Carsten! To my surprise, it was much slower and made many allocations: [... Then I noticed the cause: GHC.Prim.# returns a boxed, heap allocated Bool, and so do other primitive comparison operators. I should have asked one fundamental question first: am I right? ;) That's not really the cause. A function returning a boxed value does not necessarily have to allocate it, it is just a vectored return afaik. I haven't heard about 'vectored return' before. I will try to find more information about it. Maybe you can recommend something for me to read? (Notice that $wfor again take three arguments, the last one being the state.) Hmmm, I noticed that the number of arguments differed, there were even some quiet alarm bells in my head, but I ignored it. for4 :: Int - IO () - IO () for4 n x = if n `gt` 0 == 0 then return () else x (for4 (n-1) x) gt :: Int - Int - Int gt x y = if x y then 1 else 0 If you test it, it should be fast. It is even slightly faster than my fastest version :) BTW, although counting upwards (and not solving the problem generally), the following is ok too: for2 :: Int - IO () - IO () for2 n x = sequence_ [x | i - [1..n]] This one is amazing. It's 3 times faster than the previous one in spite of being written in high level style. I guess it's worth checking idiomatic Haskell style first, because there is a big chance that GHC was optimised for it :) However, it would be nice if all versions were as efficient... Playing with the code generated by ghc is a great way to waste time for me. Well, but you seem to be very good at it. Maybe it won't be such a waste of time in the long term :) Wait until you have found the RULES-pragma :-) I've already found it some time ago. I even tried to use them to optimise vector/matrix expressions (to eliminate intermediate vectors), but I remember that sometimes the rules didn't fire and I didn't understand why. Have fun, Carsten Hope this will teach me to avoid premature conclusions :-/ Thanks, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is there a non-blocking version of hGetArray?
On Fri, Oct 01, 2004 at 09:34:36PM +0100, Simon Marlow wrote:
Not currently, but I could probably implement the equivalent
(hGetArrayNonBlocking).
It is perhaps not closely related, but could we also have Network.Socket
recvFrom / sendTo working on raw buffers?
I've attached a proposed implementation. It moves most of code to
recvBufFrom and sendBufTo, and changes recvFrom / sendTo to use the
*Buf* functions.
It would be nice if these functions could be used to implement efficient
recvFromArray / sendToArray (without copying), but I don't know if it's
possible to get the pointer from MutableByteArray. Is there a danger
that GC invalidates the pointer?
Best regards,
Tom
--
.signature: Too many levels of symbolic links
--- libraries/network/Network/Socket.hsc2003-10-20 13:18:30.0 +0200
+++ Socket.hsc 2004-10-02 13:53:40.0 +0200
@@ -74,7 +74,10 @@
socketToHandle,-- :: Socket - IOMode - IO Handle
sendTo,-- :: Socket - String - SockAddr - IO Int
+sendBufTo, -- :: Socket - Ptr CChar - Int - SockAddr - IO Int
+
recvFrom, -- :: Socket - Int - IO (String, Int, SockAddr)
+recvBufFrom,-- :: Socket - Int - Ptr CChar - IO (Int, SockAddr)
send, -- :: Socket - String - IO Int
recv, -- :: Socket - Int- IO String
@@ -626,22 +629,36 @@
- SockAddr
- IO Int -- Number of Bytes sent
-sendTo (MkSocket s _family _stype _protocol status) xs addr = do
- withSockAddr addr $ \p_addr sz - do
+sendTo sock xs addr = do
withCString xs $ \str - do
+ sendBufTo sock str (length xs) addr
+
+sendBufTo :: Socket -- (possibly) bound/connected Socket
+ - Ptr CChar - Int -- Data to send
+ - SockAddr
+ - IO Int -- Number of Bytes sent
+
+sendBufTo (MkSocket s _family _stype _protocol status) ptr nbytes addr = do
+ withSockAddr addr $ \p_addr sz - do
liftM fromIntegral $
#if !defined(__HUGS__)
throwErrnoIfMinus1Retry_repeatOnBlock sendTo
(threadWaitWrite (fromIntegral s)) $
#endif
- c_sendto s str (fromIntegral $ length xs) 0{-flags-}
+ c_sendto s ptr (fromIntegral $ nbytes) 0{-flags-}
p_addr (fromIntegral sz)
recvFrom :: Socket - Int - IO (String, Int, SockAddr)
-recvFrom sock@(MkSocket s _family _stype _protocol status) nbytes
+recvFrom sock nbytes =
+ allocaBytes nbytes $ \ptr - do
+(len, sockaddr) - recvBufFrom sock nbytes ptr
+str - peekCStringLen (ptr, len)
+return (str, len, sockaddr)
+
+recvBufFrom :: Socket - Int - Ptr CChar - IO (Int, SockAddr)
+recvBufFrom sock@(MkSocket s _family _stype _protocol status) nbytes ptr
| nbytes = 0 = ioError (mkInvalidRecvArgError Network.Socket.recvFrom)
| otherwise =
- allocaBytes nbytes $ \ptr - do
withNewSockAddr AF_INET $ \ptr_addr sz - do
alloca $ \ptr_len - do
poke ptr_len (fromIntegral sz)
@@ -665,8 +682,7 @@
getPeerName sock
else
peekSockAddr ptr_addr
- str - peekCStringLen (ptr,len')
- return (str, len', sockaddr)
+ return (len', sockaddr)
-
-- send recv
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is there a non-blocking version of hGetArray?
On Sat, Oct 02, 2004 at 02:04:19PM +0200, Tomasz Zielonka wrote:
It is perhaps not closely related, but could we also have Network.Socket
recvFrom / sendTo working on raw buffers?
I've attached a proposed implementation. It moves most of code to
recvBufFrom and sendBufTo, and changes recvFrom / sendTo to use the
*Buf* functions.
I reversed the order of ptr and nbytes parameters to recvFromBuf to
match the order used by hGetBuf and hPutBuf.
Best regards,
Tom
--
.signature: Too many levels of symbolic links
--- libraries/network/Network/Socket.hsc2003-10-20 13:18:30.0 +0200
+++ Socket.hsc 2004-10-02 14:04:19.0 +0200
@@ -74,7 +74,10 @@
socketToHandle,-- :: Socket - IOMode - IO Handle
sendTo,-- :: Socket - String - SockAddr - IO Int
+sendBufTo, -- :: Socket - Ptr CChar - Int - SockAddr - IO Int
+
recvFrom, -- :: Socket - Int - IO (String, Int, SockAddr)
+recvBufFrom,-- :: Socket - Ptr CChar - Int - IO (Int, SockAddr)
send, -- :: Socket - String - IO Int
recv, -- :: Socket - Int- IO String
@@ -626,22 +629,36 @@
- SockAddr
- IO Int -- Number of Bytes sent
-sendTo (MkSocket s _family _stype _protocol status) xs addr = do
- withSockAddr addr $ \p_addr sz - do
+sendTo sock xs addr = do
withCString xs $ \str - do
+ sendBufTo sock str (length xs) addr
+
+sendBufTo :: Socket -- (possibly) bound/connected Socket
+ - Ptr CChar - Int -- Data to send
+ - SockAddr
+ - IO Int -- Number of Bytes sent
+
+sendBufTo (MkSocket s _family _stype _protocol status) ptr nbytes addr = do
+ withSockAddr addr $ \p_addr sz - do
liftM fromIntegral $
#if !defined(__HUGS__)
throwErrnoIfMinus1Retry_repeatOnBlock sendTo
(threadWaitWrite (fromIntegral s)) $
#endif
- c_sendto s str (fromIntegral $ length xs) 0{-flags-}
+ c_sendto s ptr (fromIntegral $ nbytes) 0{-flags-}
p_addr (fromIntegral sz)
recvFrom :: Socket - Int - IO (String, Int, SockAddr)
-recvFrom sock@(MkSocket s _family _stype _protocol status) nbytes
+recvFrom sock nbytes =
+ allocaBytes nbytes $ \ptr - do
+(len, sockaddr) - recvBufFrom sock ptr nbytes
+str - peekCStringLen (ptr, len)
+return (str, len, sockaddr)
+
+recvBufFrom :: Socket - Ptr CChar - Int - IO (Int, SockAddr)
+recvBufFrom sock@(MkSocket s _family _stype _protocol status) ptr nbytes
| nbytes = 0 = ioError (mkInvalidRecvArgError Network.Socket.recvFrom)
| otherwise =
- allocaBytes nbytes $ \ptr - do
withNewSockAddr AF_INET $ \ptr_addr sz - do
alloca $ \ptr_len - do
poke ptr_len (fromIntegral sz)
@@ -665,8 +682,7 @@
getPeerName sock
else
peekSockAddr ptr_addr
- str - peekCStringLen (ptr,len')
- return (str, len', sockaddr)
+ return (len', sockaddr)
-
-- send recv
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Haddock: how to disable the JavaScript menus?
On Tue, Sep 28, 2004 at 04:05:59PM +0100, Malcolm Wallace wrote: On the theme of improving Haddock, do you think it could be fixed to generate valid HTML? Maybe it would be a good idea to use Peter Thiemann's WASH/HTML library? Dependence on external library is one obvious (small?) problem that comes to mind. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is it possible to load bindings into ghci
On Wed, Aug 25, 2004 at 09:09:40AM +0100, Simon Marlow wrote: On 24 August 2004 12:47, Andreas Marth wrote: At the moment it happens that I use an unfinished program with ghci. And each time I start GHCi, I have to introduce the same bindings aka 'cont - readFile myFile' ... Is there a way to define them once in a File and then point GHCi to it? (I need somme of the functions in the unfinished program so it has to be after reading the program file.) Like the '.' command in /bin/sh? Yes, we ought to have something like that. I'll get around to it at some point, unless anyone gets there first. Dirty hack - you can put such bindings in ~/.ghci :) Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is it possible to load bindings into ghci
On Wed, Aug 25, 2004 at 09:09:40AM +0100, Simon Marlow wrote: On 24 August 2004 12:47, Andreas Marth wrote: At the moment it happens that I use an unfinished program with ghci. And each time I start GHCi, I have to introduce the same bindings aka 'cont - readFile myFile' ... Is there a way to define them once in a File and then point GHCi to it? (I need somme of the functions in the unfinished program so it has to be after reading the program file.) Like the '.' command in /bin/sh? Yes, we ought to have something like that. I'll get around to it at some point, unless anyone gets there first. How about this: :def . readFile :. C.hs I guess I got there first ;) Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is it possible to load bindings into ghci
On Wed, Aug 25, 2004 at 04:05:39PM +0200, Andreas Marth wrote: Tomasz Z. wrote: Dirty hack - you can put such bindings in ~/.ghci :) I tried that before posting the mail, but it does not work because the .ghci is read before going to the submitted file which contains the functions I need. (And ghci discards the bindings.) (I can read the contents of a file. Even print it, manipulate it (but only with what is supplied with package base). Quit good already!) You could :load your modules in .ghci, but that would be inconvenient. That works great! And you can even put the :def . readFile in the .ghci File! Thaks a lot, Andreas Thanks to you too. I wanted such functionality many times before, but it was after your question that I actually tried to do this :) Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: overzealous defaulting?
On Tue, Aug 24, 2004 at 08:55:00AM +0100, Simon Peyton-Jones wrote: | For some reason GHC defaults to Integer, even when monomorphism | restriction doesn't come into play. This is all quite reasonable. The defaulting rule says precisely what should happen. When there is an ambiguous constraint, (Show a, Read a) in this case, the defaulting rules say to try Integer and then Int (unless you have a default declaration). In this case Integer works. Forgive me, I ask questions which are answered very clearly in the report (modulo the extended defaulting mechanism in GHC, but that was already explained in your previous message). Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: overzealous defaulting?
On Mon, Aug 23, 2004 at 05:14:32PM +0100, Simon Peyton-Jones wrote: The binding let t = printQ falls under the monomorphism restriction. The Haskell Report would not default (Show a), so you might think you'd get an ambiguous type variable error. But it's so annoying to get this error for ghci show [] that GHCi is a bit more eager about defaulting ambiguous types: it'll apply defaulting if all the constrained classes are standard, and at least one of them is numeric *or* is Show, Eq or Ord. The *or* part is the non-standard bit. I feel that it must be somewhat related to this behaviour: Prelude :t show . read show . read :: String - String Prelude (show . read) 13213 13213 Prelude (show . read) 0x1 65536 Prelude (show . read) 1.0 *** Exception: Prelude.read: no parse For some reason GHC defaults to Integer, even when monomorphism restriction doesn't come into play. Hugs chooses this funny, but IMHO more correct, type: Prelude :t show . read show . read :: (Read a, Show a) = [Char] - [Char] Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Lazy type-class resolution
On Fri, Aug 13, 2004 at 09:03:53AM +0100, Simon Peyton-Jones wrote: Yes, when *inferring* types GHC defers context reduction as long as possible. Reason: the call site of the function may see more instance declarations (e.g. in particular, overlapping ones), so doing reduction later may yield a different answer. Thanks for explanation. Besides overlapping instances, what are the other mechanisms that could change the decision later? I can't think of any, are they only hypotetical? Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Lazy type-class resolution
Hello! Recently I was trying to write a variadic function composition operator in Haskell. I managed to produce a version with such an interface: runF (compose f1 f2 f3 ... fn) == f1 . f2 . f3 . ... . fn I believe it is impossible to remove 'runF' without loosing generality and introducing ambiguities. But that's not my question. I noticed that Hugs can instantly infer the nice type for result of composition, but GHC keeps the huge typeclass context to the last moment. __ __ __ __ ___ _ || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2003 ||---|| ___|| World Wide Web: http://haskell.org/hugs || || Report bugs to: [EMAIL PROTECTED] || || Version: November 2003 _ Hugs mode: Restart with command line option +98 for Haskell 98 mode Type :? for help Prelude :l Comp Comp :t runF (compose succ (+ 1) succ read) runF (compose succ (flip (+) 1) succ read) :: (Num a, Enum a, Read a) = [Char] - a Comp :t runF (compose id id id id) runF (compose id id id id) :: a - a ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.2.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Prelude :l Comp Compiling Comp( Comp.hs, interpreted ) Ok, modules loaded: Comp. *Comp :t runF (compose succ (+ 1) succ read) runF (compose succ (+ 1) succ read) :: forall a b a1 a2 a3 a4. (MkComp (a1 - a1) ((a2 - a2) - (a3 - a3) - (String - a4) - F a b), Enum a1, Num a2, Enum a3, Read a4) = a - b *Comp runF (compose succ (+ 1) succ read) 13123 :: Int 13126 *Comp :t runF (compose id id id id) runF (compose id id id id) :: forall a b a1 a2 a3 a4. (MkComp (a1 - a1) ((a2 - a2) - (a3 - a3) - (a4 - a4) - F a b)) = a - b *Comp let f = runF (compose id id id id) *Comp :t f f :: forall b. b - b Is this a known feature of GHC ? Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Lazy type-class resolution
I forgot to attach the code. Here it is.
Tom
--
.signature: Too many levels of symbolic links
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-undecidable-instances #-}
module Comp where
newtype F a b = F { runF :: a - b }
class Fun f a b | f - a, f - b where
apply :: f - a - b
instance Fun (a - b) a b where
apply f x = f x
class MatchFun a b f | f - a, f - b where
wrapF :: f - F a b
instance MatchFun a b (a - b) where
wrapF f = F f
class MkComp a b where
compose :: a - b
instance MatchFun a b f = MkComp f (F a b) where
compose f = wrapF f
instance ( Compose r f a b
, MkComp (a - b) t
, Fun r b1 b
, Fun f a b1 ) = MkComp r (f - t)
where
compose r f = compose (comp r f)
class Compose t f a b | t f - a, t f - b where
comp :: t - f - a - b
instance (Fun t b c, Fun f a b) = Compose t f a c where
comp t f x = apply t (apply f x)
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCI/FFI/GMP/Me madness
On Sun, Aug 08, 2004 at 07:34:04AM -0700, Sigbjorn Finne wrote: Hi, please be aware that the RTS uses GMP as well, and upon initialisation it sets GMP's 'memory functions' to allocate memory from the RTS' heap. What about linking Haskell programs with C libraries that use GMP internally? Can it cause similar problems? Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How do I specify the source search path?
On Wed, Jun 30, 2004 at 04:27:35PM +0100, Jorge Adriano Aires wrote: Using the -i flag. Unfortunatly relative paths (using '~') don't seem to work, so you have to type the full path: ghci -i/home/user/HAppS/ Thats because GHCi insists that there be no space between -i and the path, and shell tilde expansion won't work it such situation. -i$HOME/HAppS/ should work. Hint: you can put this in your .ghci :set -i/full/path/to/homedir/HAppS/ Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Understanding strictness of ghc output
On Tue, Jun 22, 2004 at 01:52:44PM +0100, Malcolm Wallace wrote: Same again. Try addHeight h E= h `seq` h which, although it looks bizarre, actually forces the evaluation of h, whilst simply returning it does not. That contradicts my intution for seq. I would read it as h is forced before h is forced, and I would think that (h `seq` h) is equivalent to h. Were I am wrong? Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Understanding strictness of ghc output
On Tue, Jun 22, 2004 at 02:28:21PM +0100, Simon Peyton-Jones wrote: | That contradicts my intution for seq. I would read it as h is forced | before h is forced, and I would think that (h `seq` h) is equivalent | to h. | | Were I am wrong? You're not wrong -- Malcolm is. The function is certainly strict in h, and GHC finds it. I will only add that I am aware that my wording is imprecise. It's more like Forcing (a `seq` b) forces a, then forces b, and then returns the value of b, unless a is bottom or b is bottom - in which case it returns bottom. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Prelude/main magicks?
On Sun, May 09, 2004 at 06:54:27PM +, Niklas Broberg wrote: I am currently co-developing a language[1] as an extension to Haskell, by means of a preprocessor to GHC. In this language we want to supply the programmer with a number of functions by default, as with the functions in the GHC Prelude. Is there some simple way to make GHC treat our own base library in the same magic way as the Prelude, so that it is always implicitly available? Perhaps your preprocessor could just place a suitable 'import' in the generated Haskell module? And while I'm asking about magicks; In our language we have a special function, called page, that we require be present in executable modules, much like a main-function. Once again, is there some way of tweaking GHC to check this for us? Along the same lines: put something like this in the generated module requirePage :: () requirePage = f page where f :: PageType - () f _ = () IIRC if you use a name beginning with underscore, GHC won't warn that it is unused. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Prelude/main magicks?
On Sun, May 09, 2004 at 09:45:32PM +0200, Tomasz Zielonka wrote: requirePage :: () requirePage = f page where f :: PageType - () f _ = () Or simpler: _requirePage :: PageType _requirePage = page Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: sizeFM type
On Sun, Apr 25, 2004 at 04:12:25PM -0400, David Roundy wrote: On the other hand, since they are still 32 bit computers, any given application can still only access 4G of memory. This issue will only be a problem on 64 bit platforms which have a 32 bit Int. Here is a funny program that gives wrong result because of length returning Int on a 32-bit computer. import Data.List main = print (length (genericTake 50 (repeat ( Running it shows $ ./A 705032704 But this is a strange piece of code and I agree that it will hardly be a problem on a 32 bit platform. I believe it's impossible to write similarly behaving program for Data.FiniteMap with current compilers and libraries. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: turn off let floating
On Thu, Apr 15, 2004 at 01:52:38PM +1000, Bernard James POPE wrote: However, if you have any suggestions about how to make a FAST global counter I would be very glad to hear it. From profiling it seems like this code is a little expensive (also it is called quite frequently). Well, I'm not Simon, but I would suggest to change the line with writeIORef to: writeIORef count $! newCount Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Random number generator
On Thu, Jan 15, 2004 at 11:00:24PM +0100, Stefan Reich wrote: How many ints do you want to generate? I don't think it is possible to generate an infinite lazy list in this case because this interferes with monad semantics. If you want a fixed number of random ints, try this: drawInts :: Int - Int - Int - IO [Int] drawInts num x y = sequence (replicate num (getStdRandom (randomR (x,y Sure you can. You can 'split' the random generator getting two new generators. One is used to update the global generator, and you use the second one to generate infinite list of pseudo-random values. drawInts :: Int - Int - IO [Int] drawInts x y = getStdRandom split = (return . randomR (x, y)) Actually, if you relax the type signature you get a function that's missing from Random module: randomRIOs :: (Random a) = (a, a) - IO [a] randomRIOs r = getStdRandom split = (return . randomRs r) Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: POpen, opening lots of processes
On Sat, Jan 10, 2004 at 04:50:28PM -0500, Mark Carroll wrote: Tomasz, Your code looks great, Thanks :) It was written in haste for a particular purpose and then tweaked a bit, so I would be pleasantly surprised if it didn't contain any bugs (besides the one mentioned in code). It isn't suitable for exchanging bigger amounts of data between processes. but where do you find the library documentation, like what the arguments for executeFile are all about? (I'd guessed the Maybe thing was an environment, but what's the Bool?) That was about a month ago, so I don't remember exactly, but knowing me I guess I must have looked into the source code. You can find some good, but sometimes not haddockised, comments there. Glynn Clements already cited some relevant code, but I think I was rather looking at libraries/unix/System/Posix/Process.hsc which is the one I used in my code, probably more recent. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: POpen, opening lots of processes
On Thu, Jan 08, 2004 at 09:33:29AM -0800, Hal Daume III wrote: Hi, I'm using POpen to shell out to a command several hundreds or thousands of times per call (none of them simultaneous, though, this is completely serial). After running my program for a while, I get: Fail: resource exhausted Action: forkProcess Reason: Resource temporarily unavailable which basically seems to be telling me that the program hasn't been closing the old processes, even though they're definitely not in use anymore. Does anyone have any suggestions how to get around this? I had a similar problem, and finally I created my own solution that doesn't leave zombies and doesn't block when the launched process writes too much to stderr. I tested it in GHC 6.0. For 6.2 you'd have to change the use of forkProcess. Usage: launch :: String - [String] - String - IO (ProcessStatus, String, String) (status, out, err) - launch prog args progInput Example: *Shell (status, out, err) - launch tr [a-z, A-Z] (unlines (replicate 1 Haskell)) *Shell status Exited ExitSuccess *Shell length out 8 *Shell mapM_ putStrLn (take 10 (lines out)) HASKELL HASKELL HASKELL HASKELL HASKELL HASKELL HASKELL HASKELL HASKELL HASKELL Best regards, Tom -- .signature: Too many levels of symbolic links module Shell where import System.Posix.Process import System.Posix.IO import Control.Concurrent import IO launch :: String - [String] - String - IO (ProcessStatus, String, String) launch prog args inputStr = do (childIn, parentIn) - createPipe (parentOut, childOut) - createPipe (parentErr, childErr) - createPipe forkProcess = \pid - case pid of Nothing - do -- child closeFd parentIn closeFd parentOut closeFd parentErr closeFd 0 -- FIXME: What if some of 0,1,2 are already closed? closeFd 1 closeFd 2 childIn `dupTo` 0 childOut `dupTo` 1 childErr `dupTo` 2 closeFd childIn closeFd childOut closeFd childErr executeFile prog True args Nothing fail launch: executeFile failed Just child - do -- parent closeFd childIn closeFd childOut closeFd childErr input - fdToHandle parentIn output - fdToHandle parentOut err - fdToHandle parentErr outputCS - hGetContents output errCS - hGetContents err outputMV - newEmptyMVar errMV - newEmptyMVar inputMV - newEmptyMVar forkIO $ hPutStr input inputStr hClose input putMVar inputMV () forkIO $ foldr seq () outputCS `seq` hClose output putMVar outputMV () forkIO $ foldr seq () errCS `seq` hClose err putMVar errMV () takeMVar outputMV takeMVar errMV takeMVar inputMV mStatus - getProcessStatus True False child case mStatus of Nothing - fail launch: can't get child process status Just stat - return (stat, outputCS, errCS) ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Running a final finaliser
On Mon, Dec 22, 2003 at 10:13:42AM -, Simon Marlow wrote: performGC doesn't do anything that you can rely on :-) In practice, it probably starts all the finalizers that are ready to run, but it certainly doesn't wait for their termination. Moreover, it is not guaranteed that performGC will trigger a full GC. Most often it will reclaim only the 0th generation. I think it would be useful to have something like performFullGC. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Running a final finaliser
On Mon, Dec 22, 2003 at 11:34:14AM +0100, Tomasz Zielonka wrote: Moreover, it is not guaranteed that performGC will trigger a full GC. Most often it will reclaim only the 0th generation. I think it would be useful to have something like performFullGC. Or rather performMajorGC :) It seems that in GHC it suffices to foreign import ccall performMajorGC :: IO () Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: forkProcess type changed?
On Thu, Dec 11, 2003 at 04:44:37PM +0100, George Russell wrote: In 6.0.1 it has type IO () - IO (Maybe System.Posix.Types.ProcessID). Isn't it rather IO (Maybe System.Posix.Types.ProcessID) ? Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Making implicit parameters explicit
On Wed, Nov 05, 2003 at 09:13:12PM +0100, Stefan Reich wrote: Hi, I discovered implicit parameters today and I'm very excited about them because they allow to express certain code constructs more elegantly. However, I stumbled upon a problem. Suppose I have these definitions (the definition of Request is irrelevant): type Controller = (?req :: Request) = String controller1 :: Controller controller2 :: Controller controllerList = [controller1, controller2] GHC complains with: Unbound implicit parameter (?req :: Request) arising from use of `controller1' In the list element: controller1 In the definition of `controllerList': controllerList = [controller1, controller2] You have just been bitten by monomorphism restriction. Write a type signature for controllerList and it should work: controllerList :: (?req :: Request) = [String] Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Making implicit parameters explicit
On Thu, Nov 06, 2003 at 10:02:26PM +0100, Tomasz Zielonka wrote: GHC complains with: Unbound implicit parameter (?req :: Request) arising from use of `controller1' In the list element: controller1 In the definition of `controllerList': controllerList = [controller1, controller2] You have just been bitten by monomorphism restriction. Write a type signature for controllerList and it should work: controllerList :: (?req :: Request) = [String] Maybe in such situation GHC could suggest that the problem can be caused by monomorphism restriction ? Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.Tree.Tree Show instance
On Tue, Aug 12, 2003 at 12:30:27PM +0200, Johannes Waldmann wrote: On Mon, 11 Aug 2003, Tomasz Zielonka wrote: The Tree datatype in new Data.Tree module has a Show instance ... [...] On the other hand, it is my opinion that for a clean program design, you should normally define your own `data' (or `newtype') types, rather than use exisiting ones by `type' synonyms. this may lead to somewhat larger program texts, but you'll find that they are more readable, and extendable. (Compare adding another component to a tuple, and to a record). this also gives you the opportunity to define class instances in any way you want. I agree with you. I often define my own types using 'data' and 'newtype', even for things like IP adresses and numeric identifiers, because I don't need and don't want many operations that integral types provide but are meaningles in these applications. I also find datatypes with named fields convenient. And I rarely define type synonyms, probably only for some involved combinations of monad transformers. However, I think that there are some types so generic, that they deserve including in standard libraries. One example is a list - how often do you define your own list type? But lists form a subset of trees, and trees form a subset of graphs, so it would be nice to have them delivered with GHC even if they would only be used in toy applications. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Data.Tree.Tree Show instance
Hi! The Tree datatype in new Data.Tree module has a Show instance that works like shown below: Prelude Data.Tree print (Node 'a' [Node 'b' [], Node 'c' []]) - 'a' -+- 'b' | `- 'c' I use a similar module for Trees in conjunction with WASH for generating web pages. WASH session management relies on the ability to read back previously showed values. Writing a Read instance for such Show would be a weird thing to do. I think it would be better to derive Show instance for Tree instead of providing a pretty printing one. Then it would be possible to have a complementing Read instance. The pretty printing function could be provided under a different name (eg. drawTree). The other tiny problem is that the current instance is not recursion-proof: Prelude Data.Tree let f x = Node x [Node x [], Node x []] Prelude Data.Tree print (f (f 1)) - - 1 -+- 1 | `- 1 -+- - 1 -+- 1 | `- 1 | `- - 1 -+- 1 | `- 1 Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RTS options in binaries
On Mon, Jun 02, 2003 at 09:53:57AM +0100, Simon Marlow wrote: Is there an easy way to hardcode RTS options in binaries produced by GHC? I know I can make a shell script but an option in GHC could be nicer. See: http://www.haskell.org/ghc/docs/latest/html/users_guide/runtime-control.html#RTS-HOOKS Oh, I've missed that part. It looks reasonable. Thanks! Cheers, Simon Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
