Re: [Haskell] Guidelines for respectful communication
Hi On 10.12.18 12:12, Alex Silva wrote: On 10/12/2018 12:06, Jerzy Karczmarczuk wrote: The intelligence is crucial here. It is not democratically distributed [[my goodness, am I already insulting people?!]], so we will always need Constitutions, Catechisms, sportmanship rules, etc., even without the accompanying "criminal codes". The text of Simon is NOT a proposal to introduce Haskell Inquisition. You are assuming that intelligent people cannot act in bad faith, which is neither true in this community or in general. That is your interpretation, he could also assume that intelligent people usually know better than to behave badly in technical forums --- and elsewhere. Regards, Jean-Marie -- Bunkyo-Ku-Straße 1a 67663 Kaiserslautern j...@gaillourdet.net +49 176 10 6321 04 ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: [Haskell-cafe] ANN: combinatorics
Hi,
On 29.01.2012, at 23:30, wren ng thornton wrote:
On 1/29/12 5:48 AM, Roman Cheplyaka wrote:
* wren ng thorntonw...@freegeek.org [2012-01-28 23:06:08-0500]
Why not to make it more pure? That is, return a lazy list of Ints (but
not a CAF), which user can throw away by the usual GC means?
The functions from the other modules that use primes would have to be
put in a Reader monad. That would make it a little bit more awkward to
use, but personally I'd prefer that over memory leaks.
I'd also prefer a more pure solution, but I don't think that the Reader monad
is the right tool here. I played around with that approach, but it requires
extremely invasive changes to client code, obfuscating what should be simple
mathematical formulae. And, it's too fragile, exposing the implementation in
a way that breaks client code should I change a non-prime-using algorithm to
a prime-using one, or vice versa. The fragility could be partially avoided by
providing both prime-using and non-prime-using algorithms, but then that
forces users to decide which one they want--- and if their only concern is
performance, then they'd have to go through the code-breaking refactoring
anyways, just to determine which is faster for their application.
One alternative I'm exploring is, rather than (only) making the primes not a
CAF, instead make the prime-using functions non-CAFs as well. That is,
provide a makePrimeUsingFunctions function which returns a record/tuple of
all the functions, sharing a stream of primes. This way, after allocating the
functions, they can be used purely just as in the current model; and when the
client wants the primes to be GCed, they can drop their references to the
allocated functions which use those primes (allocating new functions later,
if necessary).
A slight variation on that approach is to use implicit parameters to
parameterize your functions by the primes. Something allong the following lines:
{-# LANGUAGE ImplicitParams, Rank2Types #-}
data PrimeTable -- abstract
withPrimes :: ((?primes :: PrimeTable) = a) - a
withPrimes e = e
where
?primes = ...
factorial :: (?primes :: PrimeTable) = Integer - Integer
factorial = ...
example = withPrimes $ ... factorial n ….
This has the advantage that the user doesn't have to bring all the elemnts of
your tuple/record into scope.
And you can have two modules with an almost identical content, one uses the
implicit primes argument and the other uses a global CAF for its primes. A user
would only have to change his type signatures and strategically add/remove a
call to withPrimes when switching.
Cheers,
Jean
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TCP Server
On 28.01.2012, at 12:56, Felipe Almeida Lessa wrote: I find it funny that conduit is said to be an iteratee library since it has no iteratees! We've had more than one iteratee library since at least 1.5 years with the iteratee (Mar 2009) and enumerator (Aug 2010) packages, and AFAIK now we have four iteratee libraries: those two, iterIO (May 2011) and pipes (Jan 2012). However, conduit is not the fifth since it has no iteratees, no enumerators, no enumeratees... it's a different concept, not a different implementation. But it does try to solve the problem, doesn't it? Obviously conduit is an alternative to the iteratee-like packages. Why else would Yesod replace enumerator by conduit? That is the reason why I added it into my list of iteratee-like packages. Jean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TCP Server
Hello, On 27.01.2012, at 00:47, Alexander V Vershilov wrote: Recently I asked about tcp server libraries [1] and there was only one answer haskell-scallable-server [2], but in that package there was some dependencies and server logic that are not good for my task. A simple search for server on Hackage turned up the following packages for somewhat generic server infrastructure: http://hackage.haskell.org/package/iterio-server http://hackage.haskell.org/package/generic-server http://hackage.haskell.org/package/c10k http://hackage.haskell.org/package/network-server In issue 19 of The Monad Reader is an article discussing the design of the following web server: http://hackage.haskell.org/package/mighttpd2 This links might be relevant to your original question. So I decided to make a library with skeletons for different types of tcp servers and a basic library to make server [3]. Now there is only warp based (simplified) tcp server. Main logic is: * handle new connection and start iteratee green thread * enumerator (library side) reads socket and send data into enumeratee (application side) * enumeratee consumes input and produces server command (now simply output) and push it into iteratee (server side) * iteratee server side reads command and performs action (now simply output command) It gives application possibility to store state in enumerator. My questions to community: 1). can you help to make code better ;) maybe there are some stupid mistakes 2). is there any ideas what thing can be add to the server to make it reusable I think there is still no consensus on which iteratee library is the one to use. There are at least iteratee, enumerator, iterIO, conduit, and pipes. The reusability of your libary depends on the choice of iteratee-style library you select. Jean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] where to put general-purpose utility functions
Hi, On 21.01.2012, at 21:20, Joey Hess wrote: My problem now is that as I start new projects, I want to have my haskell utility functions available, and copying them around is not ideal. So, put them on hackage. But where, exactly? It already has several grab bag utility libraries. The only one with much traction is MissingH. Using the others makes a program have an unusual dependency, which while only a cabal install away, would make work for distributions that want to package the program. I've ruled out using a couple on that basis. Doesn't encourage me to add another one. My 2000+ lines of reusable code are a grab-bag of generic utility functions. Looking them over (see Appendix), I could try to get portions into existing libraries on hackage, but it's unlikely I'd find a home for most of them, so I'm still left with this problem of what to do. I wonder if the model used for xmonad-contrib, of a big library package, that is very open to additions from contributors, would be helpful here? John, any interest in moving MissingH in this direction? I get the impression it's not otherwise changing much lately, and parts of it are becoming naturally obsolete, maybe this could inject some life into it. Any other thoughts you have on grab-bag utility libraries on hackage also appreciated. Personally, I've always been avoiding those grab-bags of functionality like MissingH and other libraries. Not because I think they don't provide anything useful. But, because their level of maintenance is not clear to me. A rather large library of utility functions tends to need many dependencies on other hackage packages. That makes the question of maintenance even more important. As others have pointed out some of your functions may already exist in some widely used package. And other might be easy to be replaced by some idiom. Don't underestimate the depth of Haskell and it's well thought libraries. I am regularly amazed by finding some new way to combine seemingly trivial functions to do some non-trivial task. Every time that happens I can remove some of my utility functions. Therefore, I would reuse my own collection of utility code as a separate repository to be included as a sub repository in other projects. Mercurial and Git support that very well, I am not sure about darcs' support for that. This approach allows you to avoid copypaste reuse and it allows you to evolve your personal collection at your speed without worrying for backwards compatibility or API changes. Publishing a library on hackage comes --- at least in an ideal world --- with some commitment to document it, keep it compiling and working with a set of compiler and library permutations, fix bugs and so on. In short it comes with a commitment to maintain it. At least for some time. If you would just like to drop some pile of code in hope someone will find it useful. Do that, but perhaps there might be better places for that than hackage. Cheers, Jean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] partial type annotations
Hi, On 20.01.2012, at 09:30, Paul R wrote: Hi, x :: Integer - instruction1 -- Require ScopedTypeVariables This is still enabled by the PatternSignatures extensions. Indeed, that does require ScopedTypeVariables to be enabled, but this basic use case is not clearly covered in the ScopedTypeVariables documentation. http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensions.html#pattern-type-sigs Also, it is not clear to me why ScopedTypeVariables is required at all here, as Integer is a literal type and not a signature-bound type variable. In current GHC version PatternSignatures is deprecated and instead integrated into ScopedTypeVariables. Jean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] named pipe interface
Hi, On 14.01.2012, at 12:11, Serge D. Mechveliani wrote: On Fri, Jan 13, 2012 at 12:19:34PM -0800, Donn Cave wrote: Quoth Serge D. Mechveliani mech...@botik.ru, ... Initially, I did the example by the Foreign Function Interface for C. But then, I thought But this is unnatural! Use plainly the standard Haskell IO, it has everything. So, your advice is return to FFI ? Well, it turns out that the I/O system functions in System.Posix.IO may work for your purposes. I was able to get your example to work with these functions, which correspond to open(2), read(2), write(2). I would also use these functions in C, as you did in your C program. Haskell I/O functions like hGetLine are analogous to C library I/O like fgets(3) - in particular, they're buffered, and I would guess that's why they don't work for you here. Specifically, openFile toA WriteOnly Nothing defaultFileFlags openFile fromA ReadOnly Nothing defaultFileFlags fdWrite toA str (str, len) - fdRead fromA 64 return str Great! Thank you very much. As I find, Posix.IO is not of the standard, but it is of GHC. Anyway, it fits my purpose. By openFile you, probably, mean openFd. Another point is the number of open files, for a long loop. I put toA_IO = openFd toA WriteOnly Nothing defaultFileFlags fromA_IO = openFd fromA ReadOnly Nothing defaultFileFlags axiomIO :: String - IO String axiomIO str = do toA - toA_IO fromA - fromA_IO fdWrite toA str (str, _len) - fdRead fromA 64 return str When applying axiomIO in a loop of 9000 strings, it breaks: too many open files. I do not understand why it is so, because toA_IO and fromA_IO are global constants (I have not any experience with `do'). Anyway, I have changed this to toA = unsafePerformIO toA_IO fromA = unsafePerformIO fromA_IO axiomIO :: String - IO String axiomIO str = do fdWrite toA str (str, _len) - fdRead fromA 64 return str And now, it works in loong loops too (I need to understand further whether my usage of unsafePerformIO really damages the project). I'd say this use of unsafePerformIO is *not* safe. E.g. a Haskell compiler is allowed to evaluate the right hand side of toA and fromA multiple times. If you aren't 100% sure that it is ok to use unsafePerformIO, don't use it! Try something like the following: initIO = do to - toA_IO from - fromA_IO return (to, from) axiomIO (to,from) str = do fdWrite to str (str, _len) - fdRead from 64 return str main = do fds - initIO … res - axiomIO fds … Obviously I didn't compile and test this code. Its performance is 9/10 of the C - C performance (ghc -O, gcc -O, Linux Debian). It is still slow: 12 small strings/second on a 2 GHz machine. But this is something to start with. I was able to get your example to work with these functions, which correspond to open(2), read(2), write(2). I would also use these functions in C, as you did in your C program. Haskell I/O functions like hGetLine are analogous to C library I/O like fgets(3) - in particular, they're buffered, and I would guess that's why they don't work for you here. Indeed. Initially, I tried C - C, and used fgets, fputs, fflush. And it did not work, it required to open/close files inside a loop; I failed with attempts. Again, do not understand, why (do they wait till the buffer is full?). Then, I tried read/write, as it is in fifoFromA.c which I posted. And it works. Now, Haskell - C gives a hope. Nice. Thanks, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list glasgow-haskell-us...@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHCi with wxhaskell-dev
Hi, On 10.01.2012, at 19:05, Dave Tapley wrote: I'm working on a dev branch of wxHaskell [1] and one of the new features is that you can use wxHaskell in GHCi (again), but I seem to have broken something in the process: Firstly: wxHaskell works in GHCi insomuch as: You can load the hello world sample [2] in GHCi, do main, see the window spawn, close it and be returned to the GHCi prompt. What I'm interested in is the case where you call wxHaskell's start function [3] from GHCi. The result is becoming stuck with no way back to the GHCi prompt without resorting to sending kill signals. I made a screen cast to illustrate my findings [4]: 1. Once you've done start $ return () you can press ^C all you want, there's no way back to the GHCi prompt. 2. If you send three (less has no effect) kills to the GHCi process it will exit, but it will exit GHCi as well (instead of putting you back at the GHCi prompt). 3. If you do start $ return () but *do not* try and ^C, you can send a single kill to GHCi and be returned to the GHCi prompt. My questions: 1. Why doesn't GHCi respond to the ^C? 2a. Why does entering ^C from within GHCi then prevent you from getting back to the GHCi prompt? 2b. Why doesn't any other input (i.e. entering anything but ^C) cause this behaviour? 3. If you have sent ^C from GHCi, why do you then have to kill three times to get out of GHCi? Feel free to pull the repo [1] and try it out, you'll need the latest dev release of wxWidgets [5] installed. I didn't try to reproduce your problem, but are you aware of the -fno-ghci-sandbox flag? E.g. it helps with GLUT based programs on OS X. Cheers, Jean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] indentation blues
Hello, On 13.12.2011, at 08:51, Adrien Haxaire wrote: Hello, I don't know how the indent.hs file works for the vim mode, but as you are asking for another indent.hs file, here is the link to the indent.hs file in emacs haskell-mode: https://github.com/jwiegley/haskell-mode/blob/8067b7547f047352c41af2374e3246b5504c7741/indent.hs Maybe you can use it in the vim mode ? If not, the emacs haskell mode is nice, and coming from vim you wouldn't spend much time learning emacs. there is also a vi emulator I think, though I haven't tested it. On Mon, 12 Dec 2011 16:50:24 -0800, Martin DeMello wrote: The vim autoindent for haskell is really bad :( Is there a better indent.hs file floating around somewhere? Alternatively, is the emacs haskell mode better enough that it's worth my time learning my way around emacs and evil? Yes, the haskell-emacs is nice. It provides two separate implementations of indentation engines: haskell-indent and haskell-indentation. And you can use emacs default indentation. I use haskell-indent because it considers the right indentation candidates for my coding style [1]. Regarding, your question whether this is worth switching from vim to emacs. I've been using both editors for some years and I very much doubt, that you wouldn't spend much time learning emacs. If you are comfortable with vim, stick with it, unless you are interested in Emacs or one of its really great modes: org and auctex/reftex. Regarding, the vi emulations, I'd say they are nice should you ever be forced to use emacs for some time. But I don't recommend them, I've tried them all. They are not the real thing. Most of them are vi not vim emulators. And they always feel like second class citizens in emacs land. YMMW. [1]: But I am not able to configure it to place where where I like it, indented by half the normal indentation width. Cheers, Jean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] indentation blues
On 13.12.2011, at 11:43, Martin DeMello wrote: On Tue, Dec 13, 2011 at 2:34 AM, Adrien Haxaire adr...@haxaire.org wrote: Regarding, your question whether this is worth switching from vim to emacs. I've been using both editors for some years and I very much doubt, that you wouldn't spend much time learning emacs. If you are comfortable with vim, stick with it, unless you are interested in Emacs or one of its really great modes: org and auctex/reftex. Regarding, the vi emulations, I'd say they are nice should you ever be forced to use emacs for some time. But I don't recommend them, I've tried them all. They are not the real thing. Most of them are vi not vim emulators. And they always feel like second class citizens in emacs land. YMMW. Thanks for your feedback. I've never tried vim so I couldn't tell precisely. I thought the emulations were nice enough to save time learning emacs. If they are second class citizens, I agree it would be wiser to stick with vim then. yeah, i was assuming the emulations were nice enough to support my vim habits too. if they aren't, not even a good haskell mode would make emacs comfortable enough to use given my years of ingrained vim. I am not saying they are bad, but when I returned to emacs after two years of using vim, I was disappointed by their functionality and especially by the integration between third-party emacs-modes and the vi emulations. Though, I believe there is some work on new vim emulators. I am not sure on their status. They are probably no non-brainer option, yet. What I really liked about Claus Reinke's haskell-mode for vim was the ability to insert update statements with one command. Cheers, Jean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Platform 64 bit
Hi, On 26.11.2011, at 01:29, Philippe Sismondi wrote: I just tried to install the Haskell Platform 64-bit on OS X Snow Leopard 10.6.8. The install fails with an error. This is all I see in /var/log/install.log: 11-11-25 6:22:01 PM Installer[53992]The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance. Is it known to be broken? I find something in haskell-cafe archives from last spring about a such a problem, but I don't know where to look for anything more recent. I may be blind, but I cannot see anything in the tickets under known problems. just for your information. Currently I am using Lion, and the Haskell Platform 64-bit installer worked fine for me. I am pretty sure it worked on Snow Leopard for me as well. But I can't tell anymore, since I don't have any Snow Leopard machines around. Cheers, Jean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Way to expose BLACKHOLES through an API?
Hi, On 16.11.2011, at 10:43, Duncan Coutts wrote: On Tue, 2011-11-08 at 15:43 +, Simon Marlow wrote: Hmm, but there is something you could do. Suppose a thread could be in a mode in which instead of blocking on a BLACKHOLE it would just throw an asynchronous exception WouldBlock. Any computation in progress would be safely abandoned via the usual asynchronous exception mechanism, and you could catch the exception to implement your evaluateNonBlocking operation. I'm not sure this would actually be useful in practice, but it's certainly doable. The linux kernel folks have been discussing a similar idea on and off for the last few years. The idea is to return in another thread if the initial system call blocks. Perhaps there's an equivalent here. We have an evaluateThingy function and when the scheduler notices that thread is going to block for some reason (either any reason or some specific reason) we return from evaluateThingy with some info about the blocked thread. The thing that the kernel folks could never decide on was to do with thread identity: if it was the original thread that blocked and we return in a new thread, or if the original thread returns and a clone is the one that blocks. The difference between the requirements of the Linux kernel folks and the OP is that in the Linux kernel the evaluation has to continue, while in the Haskell case we know that the BLACKHOLE is already evaluated by someone else. I am obviously no expert on the GHC internals, but that is what I understood by reading the papers about the runtime system. So, in GHC I'd say it would make sense to stay in the original thread and throw the exception as Simon Marlow said. Just my 2 eurocents. Cheers, Jean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: behaviour change in getDirectoryContents in GHC 7.2?
Hi, On 01.11.2011, at 19:43, Max Bolingbroke wrote: As I pointed out earlier in the thread you can recover the old behaviour if you really want it by manually reencoding the strings, so I would dispute the claim that it is impossible to fix within the given API. As far as I know, not all encodings are reversable. I.e. there are byte sequences which are invalid utf-8. Therefore, decoding and re-encoding might not return the exact same byte sequence. Cheers, Jean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?
Hi Eugene,
did you try using the SPECIALIZE pragma? It is part of the Haskell 98 and
Haskell 2010 specifications.
On 02.11.2011, at 12:14, Eugene Kirpichov wrote:
Yay!!!
I made a small change in Types.chs and got my original cairo-binding-based
program to be just as blazing fast. The only problem I have with this is that
I used multiparameter type classes.
Dear gtk2hs team! Is it possible to incorporate my changes? I'm pretty sure
people will be happy by an order-of-magnitude speedup. Probably the stuff
could be wrapped in #define's for those who aren't using GHC and can't use
multiparameter type classes?
I am pretty sure I could have done the same with rewrite rules, but I tried
for a while and to no avail.
FAILED SOLUTION: rewrite rules
cFloatConv :: (RealFloat a, RealFloat b) = a - b
cFloatConv = realToFrac
{-# NOINLINE cFloatConv #-}
{-# RULES cFloatConv/float2Double cFloatConv = float2Double #-}
{-# RULES cFloatConv/double2Float cFloatConv = double2Float #-}
{-# RULES cFloatConv/self cFloatConv = id #-}
See [1] in GHC User Guide.
cFloatConv :: (RealFloat a, RealFloat b) = a - b
cFloatConv = realToFrac -- or try fromRational . toRational
{-# SPECIALIZE cFloatConv :: Float - Double #-}
{-# SPECIALIZE cFloatConv :: Double - Float #-}
I did not try to compile or even benchmark this code. But I think it might help
in your case.
Cheers,
Jean
[1]:
http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#specialize-pragma
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: vector-bytestring-0.0.0.0
Hi, On 17.10.2011, at 12:14, Bas van Dijk wrote: On 17 October 2011 10:18, Christian Maeder christian.mae...@dfki.de wrote: My idea is that when vector-bytestring is as fast as bytestring, it can replace it. When that happens it doesn't matter if users use the vector interface. I would even recommend it over using the bytestring interface so that bytestring can eventually be deprecated in favor of vector. What about lazy bytestrings? I wasn't aware that vector also supports huge logical array which are suitable for very large io streams. I'd be glad if vector is also suitable for such applications. But if not, then there is still a need for the bytestring package in order to support streaming gigabytes of data in a small constant sized heap. Cheers, Jean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is this a concurrency bug in base?
Hi,
I've continued my search for a proper workaround. Again, I did find some
unexpected results. See below.
On 09.10.2011, at 17:56, wagne...@seas.upenn.edu wrote:
Quoting Jean-Marie Gaillourdet j...@gaillourdet.net:
That sounds plausible. Do you see any workaround? Perhaps repeatedly
evaluating typeOf?
If there's a concurrency bug, surely the workaround is to protect calls to
the non-thread-safe function with a lock.
typeOfWorkaround lock v = do
() - takeMVar lock
x - evaluate (typeOf v)
putMVar lock ()
return x
~d
This is my previous program with your workaround, it is also attached as
TypeRepEqLock.hs
import Control.Concurrent
import Control.Exception
import Control.Monad
import Data.Typeable
import System.IO.Unsafe
main :: IO ()
main =
do { fin1 - newEmptyMVar
; fin2 - newEmptyMVar
; forkIO $ typeOf' () = putMVar fin1
; forkIO $ typeOf' () = putMVar fin2
; t1 - takeMVar fin1
; t2 - takeMVar fin2
; if (t1 /= t2)
then putStrLn $ typeOf ++ show t1 ++ /= typeOf ++ show t2
else putStrLn Ok
}
{-# NOINLINE lock #-}
lock :: MVar ()
lock = unsafePerformIO $ newMVar ()
-- Ugly workaround to http://hackage.haskell.org/trac/ghc/ticket/5540
typeOf' :: Typeable a = a - IO TypeRep
typeOf' x =
do { () - takeMVar lock
; t - evaluate $ typeOf x
; putMVar lock ()
; return t
}
Compile and execute:
$ ghc-7.0.3 -threaded -rtsopts TypeRepEqLock.hs
snip
$ while true ; do ./TypeRepEqLock +RTS -N ; done
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
TypeRepEqLock: thread blocked indefinitely in an MVar operation
Ok
Ok
Ok
^C^C
I'm sorry but I don't see how this program could ever deadlock, unless there is
some more locking in typeOf and (==) on TypeReps.
On the other side, my admittedly ugly workaround works fine for hours and hours.
import Control.Concurrent
import Control.Exception
import Control.Monad
import Data.Typeable
main :: IO ()
main =
do { fin1 - newEmptyMVar
; fin2 - newEmptyMVar
; forkIO $ return (typeOf' ()) = evaluate = putMVar fin1
; forkIO $ return (typeOf' ()) = evaluate = putMVar fin2
; t1 - takeMVar fin1
; t2 - takeMVar fin2
; if (t1 /= t2)
then putStrLn $ typeOf ++ show t1 ++ /= typeOf ++ show t2
else putStrLn Ok
}
typeOf' val
| t1 == t2 = t1
| otherwise = typeOf' val
where
t1 = typeOf'' val
t2 = typeOf''' val
{-# NOINLINE typeOf' #-}
typeOf'' x = typeOf x
{-# NOINLINE typeOf'' #-}
typeOf''' x = typeOf x
{-# NOINLINE typeOf''' #-}
$ ghc-7.0.3 -threaded -rtsopts TypeRepEq.hs
snip
$ while true ; do ./TypeRepEq +RTS -N ; done
Ok
Ok
Ok
Ok
Ok
Ok
…
Any hints how to avoid the thread blocked indefinitely in an MVar operation
exception?
Cheers,
Jean
TypeRepEqLock.hs
Description: Binary data
TypeRepEq.hs
Description: Binary data
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
Hi Simon, On 12.10.2011, at 10:34, Simon Peyton-Jones wrote: Did you try 7.2? As I mentioned, the issue should have gone away entirely because there is no shared cache any more Yes, I did test it with GHC 7.2. And yes, with GHC 7.2 typeOf is fine. I continued to look into that issue because I am interested in a practically working solution running with GHC 6.12 and 7.0. I am sorry if I didn't make that clear enough. Cheers, Jean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
Hi Bertram,
On 12.10.2011, at 13:24, Bertram Felgenhauer wrote:
This has nothing to do with Data.Typeable though - it appears to be some
interaction between unsaferPerformIO and MVars that I do not understand.
The following program occasionally terminates with thread blocked
indefinitely in an MVar operation, too (tested on ghc 7.0.3 and 7.2.1):
import Control.Concurrent
import Control.Exception
import Control.Monad
import System.IO.Unsafe
main :: IO ()
main = do
-- evaluate lock -- adding this line fixes the problem
fin1 - newEmptyMVar
fin2 - newEmptyMVar
forkIO $ ping = putMVar fin1
forkIO $ ping = putMVar fin2
takeMVar fin1
takeMVar fin2
{-# NOINLINE lock #-}
lock :: MVar ()
lock = unsafePerformIO $ newMVar ()
ping = do
() - takeMVar lock
putMVar lock ()
Since I don't yet understand why this blocks, I cannot say whether it
should work or not.
I've seen blocks with GHC 6.12.1, but I never got one with 7.0.3 and 7.2.1.
Probably, bad luck on my side. ;-)
Cheers,
Jean
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] ANN: global-variables-1.0
Hi, I am pleased to announce the first public release of global-variables. A package providing a global namespace for IORefs, MVars, and TVars. Hackage URL: http://hackage.haskell.org/package/global-variables-1.0 Source: http://bitbucket.org/jmg/global-variables/ Description: 'Data.Global' provides a global namespace of 'IORef's, 'MVar's and 'TVar's. This namespace may be accessed in pure code. Yet reading and writing to those 'IORef's, 'MVar's and 'TVar's happens still in their respective monads. 'Data.Global' is designed to meet the following use cases: * Simplify the declaration of top-level mutable variables, by avoiding any pragmas as well as 'unsafePerformIO'. * Avoid having to pass references explicitly throughout the program in order to let distant parts communicate. * Enable a communication by convention scheme, where e.g. different libraries may communicate without code dependencies. * Simplify the configuration problem - at least for code in the IO monad. Note, that this library does not encourage sloppy software design by re-introducing all bad effects of global variables. Nevertheless, sometimes global variables are a suitable solution to a problem. In that case Data.Global simplifies and extends their handling significantly. Example: - module Main where import Data.Global import Data.IORef counter :: IORef Int counter = declareIORef Main.counter 0 main :: IO () main = do counter `writeIORef` 1 readIORef counter = print Note absence of pragmas and of unsafePerformIO! Future Plans: -- * Support discovery/traversal of existing variables * TemplateHaskell support to generate private and unique variable names. Regards, Jean ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] ANN: global-variables-1.0
Hi, I am pleased to announce the first public release of global-variables. A package providing a global namespace for IORefs, MVars, and TVars. Hackage URL: http://hackage.haskell.org/package/global-variables-1.0 Source: http://bitbucket.org/jmg/global-variables/ Description: 'Data.Global' provides a global namespace of 'IORef's, 'MVar's and 'TVar's. This namespace may be accessed in pure code. Yet reading and writing to those 'IORef's, 'MVar's and 'TVar's happens still in their respective monads. 'Data.Global' is designed to meet the following use cases: * Simplify the declaration of top-level mutable variables, by avoiding any pragmas as well as 'unsafePerformIO'. * Avoid having to pass references explicitly throughout the program in order to let distant parts communicate. * Enable a communication by convention scheme, where e.g. different libraries may communicate without code dependencies. * Simplify the configuration problem - at least for code in the IO monad. Note, that this library does not encourage sloppy software design by re-introducing all bad effects of global variables. Nevertheless, sometimes global variables are a suitable solution to a problem. In that case Data.Global simplifies and extends their handling significantly. Example: - module Main where import Data.Global import Data.IORef counter :: IORef Int counter = declareIORef Main.counter 0 main :: IO () main = do counter `writeIORef` 1 readIORef counter = print Note absence of pragmas and of unsafePerformIO! Future Plans: -- * Support discovery/traversal of existing variables * TemplateHaskell support to generate private and unique variable names. Regards, Jean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: [Haskell] ANN: global-variables-1.0
Begin forwarded message: From: Jean-Marie Gaillourdet j...@gaillourdet.net Subject: Re: [Haskell] ANN: global-variables-1.0 Date: 12. Oktober 2011 20:27:16 MESZ To: Henning Thielemann lemm...@henning-thielemann.de Hi, On 12.10.2011, at 20:20, Henning Thielemann wrote: On Wed, 12 Oct 2011, Jean-Marie Gaillourdet wrote: * Simplify the configuration problem - at least for code in the IO monad. Note, that this library does not encourage sloppy software design by re-introducing all bad effects of global variables. But isn't this kind of solution for the configuration problem an example for sloppy software design? If a global configuration would be passed around, then you could easily use the program functions with different configurations simultaneously. In contrast to that, with the global IORef this is not possible. Well, the question whether using a carefully documented set of global configuration variables which, e.g. only affect the verbosity of logging, is sloppy or not is a question I don't want to answer. But I am convinced there are good reasons to use global-variables *sometimes*. If only for a temporary debugging aid. In any case, an additional possibility to express design intents never hurts. Note, that I wrote simplify not solve the configuration problem :-) Cheers, Jean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Is this a concurrency bug in base?
Hi,
I am working on a library I'd like to release to hackage very soon, but I've
found a problem with supporting GHC 6.12 and GHC 7.0.
Consider the following program:
import Control.Concurrent
import Data.Typeable
main :: IO ()
main =
do { fin1 - newEmptyMVar
; fin2 - newEmptyMVar
; forkIO $ typeRepKey (typeOf ()) = print putMVar fin1 ()
; forkIO $ typeRepKey (typeOf ()) = print putMVar fin2 ()
; () - takeMVar fin1
; () - takeMVar fin2
; putStrLn ---
; return ()
}
When compiled with GHC 7.0.x or GHC 6.12.x, it should print two identical
numbers. Sometimes it does not.
To reproduce this compile and execute as follows:
$ ghc-7.0.3 -rtsopts -threaded TypeRepKey.hs -o TypeRepKey
$ while true ; do ./TypeRepKey +RTS -N ; done
0
0
---
0
0
---
0
0
---
0
1
---
0
0
---
…
Ideally you should get an infinite number of zeros but once in a while you have
a single(!) one in between. The two numbers of one program run should be
identical, but their values may be arbitrary. But it should not be possible to
have single outliers.
This only happens when executed with more than one thread. I've also a somewhat
larger program which seems to indicate that fromDynamic fails occasionally. I
can post it as well if it helps. This seems to be a Heisenbug as it is
extremely fragile, when adding a | grep 1 to the while loop it seems to
disappears. At least on my computers.
All this was done on several Macs running the latest OS X Lion with ghc 7.0.3
from the binary distribution on the GHC download page.
Actually, I am trying to find a method to use a type as key in a map which
works before GHC 7.2. I'd be glad to get any ideas on how to achieve that,
given that typeRepKey seems to buggy.
I'd be happy to get any comments on this matter.
Regards,
Jean
TypeRepKey.hs
Description: Binary data
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
Hi Daniel, On 09.10.2011, at 14:45, Daniel Fischer wrote: On Sunday 09 October 2011, 13:52:47, Jean-Marie Gaillourdet wrote: This seems to be a Heisenbug as it is extremely fragile, when adding a | grep 1 to the while loop it seems to disappears. At least on my computers. Still produces 1s here with a grep. Well, it may have been bad luck on my site. All this was done on several Macs running the latest OS X Lion with ghc 7.0.3 from the binary distribution on the GHC download page. linux x86_64, ghc-7.0.4, 7.0.2 and 6.12.3. Indeed 6.12.3 goes so far to sometimes produce 0 0 --- 10 --- 0 0 --- 01 --- i.e. it switches threads during print. Thanks, for reproducing it. I failed to see it on Linux so far. So I guess a bug report is in order? Or are bug reports to old versions not welcome? Jean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
Hi,
the Eq instance of TypeRep shows the same non-deterministic behavior:
import Control.Concurrent
import Control.Exception
import Control.Monad
import Data.Typeable
main :: IO ()
main =
do { fin1 - newEmptyMVar
; fin2 - newEmptyMVar
; forkIO $ return (typeOf ()) = evaluate = putMVar fin1
; forkIO $ return (typeOf ()) = evaluate = putMVar fin2
; t1 - takeMVar fin1
; t2 - takeMVar fin2
; when (t1 /= t2) $
putStrLn $ typeOf ++ show t1 ++ /= typeOf ++ show t2
}
$ ghc-7.0.3 -threaded -rtsopts TypeRepEq.hs
snip
$ while true ; do ./TypeRepEq +RTS -N ; done
typeOf () /= typeOf ()
typeOf () /= typeOf ()
^C^C
$
On 09.10.2011, at 16:04, David Brown wrote:
The program below will occasionally print 1 /= 0 or 0 /= 1 on
x86_64 linux with the Debian testing 7.0.4 ghc.
$ ghc bug -rtsopts -threaded
$ while true; do ./bug +RTS -N; done
module Main where
import Control.Monad
import Control.Concurrent
import Data.Typeable
main :: IO ()
main = do
fin1 - newEmptyMVar
fin2 - newEmptyMVar
forkIO $ child fin1
forkIO $ child fin2
a - takeMVar fin1
b - takeMVar fin2
when (a /= b) $
putStrLn $ show a ++ /= ++ show b
child :: MVar Int - IO ()
child var = do
key - typeRepKey (typeOf ())
putMVar var key
Thanks again for reproducing it.
Jean
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
Hi Daniel, On 09.10.2011, at 16:24, Daniel Fischer wrote: On Sunday 09 October 2011, 15:30:20, Jean-Marie Gaillourdet wrote: Hi Daniel, On 09.10.2011, at 14:45, Daniel Fischer wrote: On Sunday 09 October 2011, 13:52:47, Jean-Marie Gaillourdet wrote: This seems to be a Heisenbug as it is extremely fragile, when adding a | grep 1 to the while loop it seems to disappears. At least on my computers. Still produces 1s here with a grep. Well, it may have been bad luck on my site. Or maybe Macs behave differently. Thanks, for reproducing it. I failed to see it on Linux so far. So I guess a bug report is in order? I'd think so. Although due to the changes in 7.2 there's nothing to fix here anymore, it might point to something still to be fixed. Or are bug reports to old versions not welcome? Within reason. Reporting bugs against 5.* would be rather pointless now, but = 6.10 should be okay. If the behaviour has been fixed as a by-product of some other change, at least a test could be made to prevent regression. If, like here, the directly concerned code has been changed, probably nothing is to be done, but the bug may have been caused by something else which still needs to be fixed, so better report one bug too many. I've been chasing the source of the non-deterministic of my library for quite some time now. And at several points in time I had the impression that modifyMVar would not always be atomic. (Of course under the assumption that no other code touches the MVar). But in that case as well as in the case here it is only reproducible by looping the execution of the binary. Moving the loop into the Haskell program will show the bug in the first iteration or never. I will report a bug. Jean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
On 09.10.2011, at 16:40, Jean-Marie Gaillourdet wrote: I will report a bug. http://hackage.haskell.org/trac/ghc/attachment/ticket/5540/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
Hi,
On 09.10.2011, at 17:27, Daniel Fischer wrote:
Jean-Marie Gaillourdet:
the Eq instance of TypeRep shows the same non-deterministic behavior:
Of course, equality on TypeReps is implemented by comparison of the Keys.
On Sunday 09 October 2011, 16:40:13, Jean-Marie Gaillourdet wrote:
Hi Daniel,
I've been chasing the source of the non-deterministic of my library for
quite some time now. And at several points in time I had the impression
that modifyMVar would not always be atomic.
It isn't:
MVars offer more flexibility than IORefs, but less flexibility than STM.
They are appropriate for building synchronization primitives and performing
simple interthread communication; however they are very simple and
susceptible to race conditions, deadlocks or uncaught exceptions. Do not
use them if you need perform larger atomic operations such as reading from
multiple variables: use STM instead.
In particular, the bigger functions in this module (readMVar, swapMVar,
withMVar, modifyMVar_ and modifyMVar) are simply the composition of a
takeMVar followed by a putMVar with exception safety. These only have
atomicity guarantees if all other threads perform a takeMVar before a
putMVar as well; otherwise, they may block.
But I don't think that's the problem here.
(Of course under the
assumption that no other code touches the MVar).
This sentence referred to what you explained above. Although, my reference was
quite cryptic.
But in that case as
well as in the case here it is only reproducible by looping the
execution of the binary. Moving the loop into the Haskell program will
show the bug in the first iteration or never.
That's what I expect.
I think what happens is:
-- from Data.Typeable
cache = unsafePerformIO $ ...
mkTyConKey :: String - Key
mkTyConKey str
= unsafePerformIO $ do
let Cache {next_key = kloc, tc_tbl = tbl} = cache
mb_k - HT.lookup tbl str
case mb_k of
Just k - return k
Nothing - do { k - newKey kloc ;
HT.insert tbl str k ;
return k }
occasionally, the second thread gets to perform the lookup before the first
has updated the cache, so both threads create a new entry and update the
cache.
If you loop in the Haskell programme, after the first round each thread
definitely finds an entry for (), so the cache isn't updated anymore.
That sounds plausible. Do you see any workaround? Perhaps repeatedly evaluating
typeOf?
Jean
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
Hi,
On 09.10.2011, at 17:37, Jean-Marie Gaillourdet wrote:
Hi,
On 09.10.2011, at 17:27, Daniel Fischer wrote:
That's what I expect.
I think what happens is:
-- from Data.Typeable
cache = unsafePerformIO $ ...
mkTyConKey :: String - Key
mkTyConKey str
= unsafePerformIO $ do
let Cache {next_key = kloc, tc_tbl = tbl} = cache
mb_k - HT.lookup tbl str
case mb_k of
Just k - return k
Nothing - do { k - newKey kloc ;
HT.insert tbl str k ;
return k }
occasionally, the second thread gets to perform the lookup before the first
has updated the cache, so both threads create a new entry and update the
cache.
If you loop in the Haskell programme, after the first round each thread
definitely finds an entry for (), so the cache isn't updated anymore.
That sounds plausible. Do you see any workaround? Perhaps repeatedly
evaluating typeOf?
typeOf' seems to be a working workaround:
typeOf' val
| t1 == t2 = t1
| otherwise = typeOf' val
where
t1 = typeOf'' val
t2 = typeOf''' val
{-# NOINLINE typeOf' #-}
typeOf'' x = typeOf x
{-# NOINLINE typeOf'' #-}
typeOf''' x = typeOf x
{-# NOINLINE typeOf''' #-}
Jean
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
On 09.10.2011, at 17:56, wagne...@seas.upenn.edu wrote: Quoting Jean-Marie Gaillourdet j...@gaillourdet.net: That sounds plausible. Do you see any workaround? Perhaps repeatedly evaluating typeOf? If there's a concurrency bug, surely the workaround is to protect calls to the non-thread-safe function with a lock. typeOfWorkaround lock v = do () - takeMVar lock x - evaluate (typeOf v) putMVar lock () return x Yes, but this workaround is in the IO monad while mine is not. Jean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
On 09.10.2011, at 18:13, Daniel Fischer wrote:
On Sunday 09 October 2011, 17:51:06, Jean-Marie Gaillourdet wrote:
That sounds plausible. Do you see any workaround? Perhaps repeatedly
evaluating typeOf?
typeOf' seems to be a working workaround:
typeOf' val
| t1 == t2 = t1
| otherwise = typeOf' val
where
t1 = typeOf'' val
t2 = typeOf''' val
{-# NOINLINE typeOf' #-}
typeOf'' x = typeOf x
{-# NOINLINE typeOf'' #-}
typeOf''' x = typeOf x
{-# NOINLINE typeOf''' #-}
That'll make it very improbable to get bad results, but not impossible.
Thread1: typeOf' (); typeOf'' (), lookup, not there
Thread2: typeOf' (); typeOf'' (), lookup, not there
Thread1: create and insert; typeOf''' (), entry present, use ~ Key 0
Thread2: create and insert, overwites entry with Key 0,
new entry has Key 1; typeOf''' (), entry present, use ~ Key 1
It will probably take a long time until it bites, but when it does, it will
hurt.
A proper fix would need a lock to ensure only one thread at a time can
access the cache.
Ok, you're right. I tried to avoid the IO monad, but there seems to be no way
around it.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: building GHC on a cluster
Hi,
On 23.08.11 17:10, Karel Gardas wrote:
Hello,
recent GHC build times on newer MacBook Pros? thread makes me
wondering if someone already attempted to build GHC on a cluster of
machines using for example PVM GNU make[1] for this or any other tool (
or even custom generated bin/ghc-stageX scripts using rsh?) which is
suitable for the task. I'm asking since build of GHC HEAD on my
ARM/Linux (OMAP4 1GHz) using both cores takes around 7 hours and yet
buying another 3 machines might be well in the finance envelope of hobby
project and speed the development which usually happens only during
weekend's evenings...
Thanks!
Karel
[1]: http://pvmgmake.sourceforge.net/
At least the C compilations should be easily distributable with distcc
[1]. I've had great success using it with pure C projects in the past. I
don't know if compiling the runtime system takes long enough to make
distribution wortwhile.
Regards,
Jean
[1]: http://code.google.com/p/distcc/
--
Jean-Marie Gaillourdet
blog: gaillourdet.net
{email, xmpp, jabber, ichat, gimix, gtalk}:j...@gaillourdet.net
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] ANNOUNCE: string-qq-0.0.2
Hi Audrey,
are you aware that Haskell already supports multi-line strings?
foo = This is a\
\multi-line\
\string!
See Section 2.6 of http://haskell.org/onlinereport/lexemes.html
Regards,
Jean
On 25.06.11 22:55, 唐鳳 wrote:
Hi all,
I've just released string-qq 0.0.2 to Hackage:
http://hackage.haskell.org/package/string-qq
The main interface is the s quasi-quoter:
foo :: IsString a = a
foo = [s|
This is a
multi-line
string!
|]
It allows simple multi-line strings of any IsString type (Text, String,
ByteString, etc),
with no interpolation at all, except that the leading newline is trimmed and
\r\n sequences are converted to \n.
It's compatible with both GHC6 and GHC7; for GHC6, write [$s|…|] instead of
[s|…|].
Suggestions and feedback are most welcome. :-)
Cheers,
Audrey
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
--
Jean-Marie Gaillourdet
blog: gaillourdet.net
{email, xmpp, jabber, ichat, gimix, gtalk}:j...@gaillourdet.net
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] type class design
Hi, sorry for answering to such an old thread. David Menendez d...@zednenem.com writes: On Fri, Oct 29, 2010 at 8:33 AM, Tillmann Rendel ren...@informatik.uni-marburg.de wrote: Hi, Uwe Schmidt wrote: In the standard Haskell classes we can find both cases, even within a single class. Eq with (==) as f and (/=) as g belongs to the 1. case Note that the case of (==) and (/=) is slightly different, because not only can (/=) be defined in terms (==), but also the other way around. The default definitions of (==) and (/=) are mutually recursive, and trivially nonterminating. This leaves the choice to the instance writer to either implement (==) or (/=). Or, for performance reasons, both. While I understand the argument in general, I've never understood why it applies to Eq. Are there any types where it is preferable to define (/=) instead of (==)? Yes for infinite data structures. Cheers, Jean-Marie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [darcs-users] How to develop on a (GHC) branch with darcs
Hi Simon, Simon Peyton-Jones simo...@microsoft.com writes: | known problem with darcs with no obvious solution. For me, switching | GHC to git would certainly be a win. I have personal experience of git, because I co-author papers with git users. I am not very technologically savvy, but my failure rate with git is close to 100%. Ie I can do the equivalent of 'pull' or 'push' but I fail at everything else with an incomprehensible error message. Maybe I just need practice (or more diligence), but I really don't understand git's underlying model, despite trying, and reading several tutorials. If anyone has a favourite how to understand git doc, do point me at it. I've felt the same for quite some time. Therefore I used to prefer mercurial, because of its way more consistent user interface. But my view has changed after I've seen this [1] introduction of magit [2] an emacs git user interface. Now, I feel at least capable of working with git in emacs. [1] http://vimeo.com/2871241 [2] http://philjackson.github.com/magit/ Cheers, Jean-Marie ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Documentation of System.Process
Hi Simon, thanks for the clarification. Regards, Jean Simon Marlow marlo...@gmail.com writes: On 26/11/2010 10:00, Jean-Marie Gaillourdet wrote: Hi all, I've been searching information regarding file handles to pipes created by System.Process.createProcess. The documentation does not state whether they are in binary mode, i.e. whether they have line ending conversion or an encoding enabled. That kind of information is available for runInteractiveCommand in the same module. runInteractiveCommand opens all pipes in binary mode. I've concluded from the source of that module that the same is probably true for createProcess. I've two questions now: 1. Is it correct that createProcess returns file handles in binary mode when creating pipes? No, in fact the Handles use localeEncoding and nativeNewlineMode by default. You can use hSetBinaryMode if you want no encoding or newline translation. 2. Could you add that information to the haddock docs? Yes. Is their some other place where I could have found this? The source :-) Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Documentation of System.Process
Hi all, I've been searching information regarding file handles to pipes created by System.Process.createProcess. The documentation does not state whether they are in binary mode, i.e. whether they have line ending conversion or an encoding enabled. That kind of information is available for runInteractiveCommand in the same module. runInteractiveCommand opens all pipes in binary mode. I've concluded from the source of that module that the same is probably true for createProcess. I've two questions now: 1. Is it correct that createProcess returns file handles in binary mode when creating pipes? 2. Could you add that information to the haddock docs? Is their some other place where I could have found this? Thanks for your great work! Regards, Jean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Specification and prover for Haskell
Hi Romain, are you aware of Haskabelle [1], a Haskell to Isabelle/HOL converter? I've never used or investigated it. On 25.10.2010, at 10:09, Romain Demeyer wrote: Hello, I'm working on static verification in Haskell, and I search for existing works on specification of Haskell programs (such as pre/post conditions, for example) or any other functional language. It would be great if there exists a prover based on this kind of specifications. I already found the ESC/Haskell. Do you know some other works which could be interesting? Thanks, -- Jean [1] http://isabelle.in.tum.de/haskabelle.html ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Haskell Weekly News: Issue 155 - October 20, 2010
Hi, On 21.10.2010, at 11:38, Ketil Malde wrote: Malcolm Wallace malcolm.wall...@me.com writes: might value HWN as a quick-summary catchup of community news. Can you resume posting HWN there as well please? s/as well/instead/g +1 I'm always getting two copies of everything in haskell@, since everything is cross-posted to -cafe. Are there actually people subscribed to -cafe, but *not* to hask...@? And if so, why? Over the last year the volume of traffic in haskell-cafe has increased so much, that I am often not able to follow everything. Which means there are often hundreds of emails in my haskell-cafe folder marked as new. Having announcements separated or in haskell@ would be IMHO a real improvement. If every announcement or periodic status update (as e.g. HWN) is cross posted then there is no need for having two separate mailinglist. And I'd assume there is no majority in favor of merging those two mailinglist. -- Jean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Lambda-case / lambda-if
Hi,
On 06.10.2010, at 22:43, Sterling Clover wrote:
On Oct 6, 2010, at 5:39 AM, Simon Marlow wrote:
A slightly different suggestion from Simon PJ and myself (we agreed on
something syntax-related :-) is the following:
\case 1 - f
2 - g
where the two-token sequence '\ case' introduces a new optional layout
context, the body of which is exactly the same as in a case expression. So
you could also write
\case { 1 - f; 2 - g }
if you want. Guards are allowed of course.
* a bit more noisy than just \: I'm not sure what the
ramifications of having \ introduce a layout context
on its own would be, but I suspect there would be difficulties.
Certainly some existing code would fail to parse, e.g.
(case e of [] - \x - x+1; (x:xs) - \x - x+2)
\ introducing a layout context is a no-go because, as in the example given,
it breaks too much code. However, \case as described is somewhat less
powerful. In particular, \ with a layout context lets us have multi-argument
pattern matching, while both \case and case of give only single argument
pattern matching. I don't know if the extra functionality is that important,
but I don't see why we can't provide for it anyway, as in:
\case (x:xs) n - go xs; _ n - n;
Then, there is an inconsistency between lambda-case and traditional case and
people will start complaining about that.
Haskell98 is a very well thought out language with very few syntactiv warts.
I'd avoid introducing new language extensions which do introduce new warts.
Backwards compatibility is not so important, because GHC will hopefully make it
optional. Even when an extended \{ p1 - e1; p2 - e2 } is part of Haskell 2012
GHC will probably support Haskell 2011 as well. Therefore, I'd worry less about
backwards compatibility, but concentrate more on consistency and elegance. I.e
I'll favor
\p1 p2 - e1
p3 p4 - e2
Just my 2 cents.
-- Jean___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ultra-newbie Question
Hi Alberto, On 20.09.2010, at 10:53, Alberto G. Corona wrote: 2010/9/18 Daniel Fischer daniel.is.fisc...@web.de n_lastn n = reverse . take n . reverse Which is the most elegant definition, but it's an O(length list) space operation (as are all others proposed so far). T No!. You forget laziness!. it is 0(n) with n= the parameter passed to n_lastn. It is not O(length list). the reversed and de-reversed elements are just the ones being taken , not the whole list. (please kill me if I´m wrong. I don´t want to live in a world where beauty is inneficient) I am afraid you are argumentation is wrong. Let's see: f :: [a] - a f = head . reverse This is a function running in O(n) time, where n is the length of given list. That is, because f has to follow at least n pointers in order to reach the end of the parameter list. It might be much more expensive if the list has to be computed, because f got only a thunk to cumpute a list instead of a finished list. Lazyness helps helps to reduce work if your input list is lazily constructed and your function forces the returned element. Then you don't have to force all elements of the list, only the last one. Let's say l = [e_0, ..., e_n]. All the e_i are expensive calculations. g :: [a] - a g xs = x `seq` x where x = head (reverse xs) In order to compute g l you only have to evaluate e_n, not all the other e_i. Hope this helps. Jean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ultra-newbie Question
Hi James,
On 20.09.2010, at 15:20, James Andrew Cook wrote:
Lazyness helps helps to reduce work if your input list is lazily constructed
and your function forces the returned element. Then you don't have to force
all elements of the list, only the last one. Let's say l = [e_0, ..., e_n].
All the e_i are expensive calculations.
g :: [a] - a
g xs = x `seq` x
where
x = head (reverse xs)
Can x `seq` x have any different strictness than just plain x? I may be
wrong, but I don't think so. Essentially, it's saying that when x is
needed, evaluate x to WHNF and then return x.
Yes, I think you are right. I was trying to force evaluation of the returned
element. Something like that:
{-# LANGUAGE BangPatterns #-}
g :: [a] - a
g xs = x
where
!x = head (reverse xs)
-- Jean___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Using associated data types to create unpacked data structures
Hi,
On 12.08.2010, at 12:25, Simon Marlow wrote:
On 12/08/2010 11:13, Johan Tibell wrote:
There needs to be some amount of code generation, but much of the
implementation can still be shared. I previously tried to defined the
type class as
{-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-}
module Ex2 where
import Prelude hiding (lookup)
data MapView k v = TipView
| BinView {-# UNPACK #-} !Size !k !v !(Map k v)
!(Map k v)
class Unbox k v where
data Map k v :: *
tip :: Map k v
bin :: Size - k - v - Map k v - Map k v - Map k v
view :: Map k v - MapView k v
type Size = Int
lookup :: (Ord k, Unbox k v) = k - Map k v - Maybe v
lookup k m = case view m of
TipView - Nothing
BinView _ kx x l r - case compare k kx of
LT - lookup k l
GT - lookup k r
EQ - Just x
{-# INLINE lookup #-}
Calling lookup from a different module at a know type gives exactly the
Core you'd like to see (unpacked types, no MapView constructors).
I'm not sure I want lookup (and other operations) to be inlined at every call
site though.
Wouldn't it be better to enable specialize pragmas from outside the defining
module. Then a user of the Ex2 could declare his need for an optimized version
of lookup for his particular type. Of course, that would require the inclusion
of lookup into the .hi file.
-- Jean___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: Odd parallel haskell observations (some more numbers)
Hello, I am no expert in web server tuning, but I will share my thoughts about your approach and expectations nevertheless. On 08.08.2010, at 21:07, Alexander Kotelnikov wrote: So I continue to issue thousands of HTTP GET requests to a local apache an got some ThreadScope pictures and numbers (BTW, I all this happens on a 4-core machine). So your apache configuration is very crucial for the performance figures you will receive from your benchmark. As far as I know web server benchmarks usually run continuously and report a current throughput or average latency of the last n seconds or something like that. This allows the tested web server to adapt to the kind of load it experiences. And the benchmarker is able to wait untill those numbers stabilize. When you execute your program with a different number of capabilities (different -N settings), apache will see a different kind of load and behave different. This makes it hard to change your program and expect similar results. I would point out the following as deserving an explanation: 1. It looks like that none of tests used resources of more than 2 cores. This might be an indication that cpu resources are not the limiting factor in this benchmark. You basically bench the io capabilities of your operating system, your installed apache with your configuration and of your installed ghc. Therefore, increasing available cpu resources does't lead necessarily to increased performance. 2. Sometimes there is no activity in any thread of a running program (get.N4qg_withgaps.eventlog.png, does this mean that process is in a OS queue for scheduling or something else?) 3. Without RTS's -c or -qg multithreaded run suffers from excessive GC actions. 4. Even with -c/-qg thread's run looks to be iterrupted too frequent. 5. Provided that 1 requests in a row can be completed in ~3.4s I would expect that 4 threads might come close or even under 1s, but 1.9s was the best result. A last point to consider: Is getRequest strict? Does it internally use some kind of lazy IO? Is it possible that some resource aren't properly freed? Perhaps, because the library relies on the garbage collector reclaiming sockets? Or because the request aren't completely read? I simply don't no the internall of Network.HTTP, but if it uses lazy IO it is IMHO not suitable for such a benchmark. Just, my two euro cents. -- Jean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Deadlock with Repa
Hi, I've been trying to use repa and stumbled into rather strange behavior of my program. Sometimes, there seems to be a deadlock at other times it seems there is a livelock. Now, I've managed to prepare a version which consistently generates the following output: $ ./MDim MDim: thread blocked indefinitely in an MVar operation $ But I don't use any MVar directly. And the only used library which is not part of ghc are repa and repa-algorithms. To state it clearly I don't use any MVars, par, pseq, forkIO nor any other parallelism or cuncurrency functionality. The only thing my program uses is repa which is supposed to use some kind of parallelism as far as the documentation says. So I am wondering whether this is a problem with my code or with repa or with ghc. The same behaviour occurs with ghc-6.12.1 and ghc-6.13.20100726. This is on MacOSX 10.6.4. In order to reproduce take the attached file and compile it with: $ ghc --make -package dph-prim-par MDim.hs -main-is MDim -fforce-recomp [1 of 1] Compiling MDim ( MDim.hs, MDim.o ) Linking MDim ... $ ./MDim MDim: thread blocked indefinitely in an MVar operation $ I haven't been able to make the program smaller without removing the blockage. But, essentially it's just pure number crunching you can ignore. I'd be really happy if anyone could give me a hint how to debug this, or whether I am able to do anything about it, at all. Best regards, Jean-Marie MDim.hs Description: Binary data -- Dipl.-Inf. Jean-Marie Gaillourdet Software Technology Group University of Kaiserslautern, Department of Computer Science Gebäude 32, Raum 406 Gottlieb-Daimler-Str. D-67653 Kaiserslautern Tel: 06 31 - 205 - 32 72 Fax: 06 31 - 205 - 34 20 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] How to browse code written by others
On 15.06.2010, at 01:35, Luke Palmer wrote: On Mon, Jun 14, 2010 at 2:02 AM, Jean-Marie Gaillourdet j...@gaillourdet.net wrote: Hello, On 13.06.2010, at 22:32, Martin Drautzburg wrote: I need your advice about how to browse code which was written by someone else (Paul Hudak's Euterpea, to be precise, apx. 1 LOC). I had set some hopes on leksah, and it indeed shows me the interfaces, but I have not yet convinced it to show me more than that. I ran haddock over the sources, and again I could not see more that just signatures. I would be very happy with something like a Smalltalk browser. Something that would let me zoom down to the source code, but with search and hyperlink capabilities (senders and implementers in Smalltalk). Anyways, how do you guys do it, i.e. how to you dive into non-trivial foreign code? I use the following tools: * haddock generated docs with hyperlinked sources * MacVim (or just vim) with Claus Reinke's haskellmode-vim, see: http://projects.haskell.org/haskellmode-vim/index.html Have a look at the screencasts to see documentation lookup, and code navigation: http://projects.haskell.org/haskellmode-vim/screencasts.html Make sure you know how to use tags inside of vim. ghci is able to generate the tagsfiles for you. This allows you to jump to definitions of identifiers. If you go this route, I will shamelessly promote hothasktags instead of ghci. It generates proper tags for qualified imports. That sounds interesting. Thanks for the hint. Regards, Jean-Marie___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to browse code written by others
Hello, On 13.06.2010, at 22:32, Martin Drautzburg wrote: I need your advice about how to browse code which was written by someone else (Paul Hudak's Euterpea, to be precise, apx. 1 LOC). I had set some hopes on leksah, and it indeed shows me the interfaces, but I have not yet convinced it to show me more than that. I ran haddock over the sources, and again I could not see more that just signatures. I would be very happy with something like a Smalltalk browser. Something that would let me zoom down to the source code, but with search and hyperlink capabilities (senders and implementers in Smalltalk). Anyways, how do you guys do it, i.e. how to you dive into non-trivial foreign code? I use the following tools: * haddock generated docs with hyperlinked sources * MacVim (or just vim) with Claus Reinke's haskellmode-vim, see: http://projects.haskell.org/haskellmode-vim/index.html Have a look at the screencasts to see documentation lookup, and code navigation: http://projects.haskell.org/haskellmode-vim/screencasts.html Make sure you know how to use tags inside of vim. ghci is able to generate the tagsfiles for you. This allows you to jump to definitions of identifiers. * SourceGraph, it generates an HTML report of a cabal projekt or of any source tree. IMHO, great to get the overall picture. Regards, Jean-Marie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Woes on MacOS 10.6 - linking issues
Hi Brett, On 11.06.2010, at 04:53, Brett Giles wrote: I seem to have Gtk2HS 0.11 installed, but not quite working. Interestingly, I can run a demo, such as the hello/World.hs example, directly in ghci. However, when I try to do a ghc --make on any code containing gtk2hs I get a link error like this: Undefined symbols: _iconv_close, referenced from: _hs_iconv_close in libHSbase-4.2.0.0.a(iconv.o) (maybe you meant: _hs_iconv_close) _iconv, referenced from: _hs_iconv in libHSbase-4.2.0.0.a(iconv.o) (maybe you meant: _hs_iconv_open, _hs_iconv , _hs_iconv_close ) _iconv_open, referenced from: _hs_iconv_open in libHSbase-4.2.0.0.a(iconv.o) (maybe you meant: _hs_iconv_open) ld: symbol(s) not found I've had the exactly that same issue an hour ago, when I was trying to cabal install threadscope on Snow Leopard 10.6.3. I managed to build it using cabal install threadscope --extra-lib-dir=/usr/lib The resulting binary seems to work fine. I do have libiconv installed as a universal library via macports. gtk, glade etc., are also universal installed via macports. But, I did not manage to build glade with macports as a universal binary. I had to force it to be i386 only, since evolution-data-server failed to compile. How, did you manage to build a universal binary? Sorry, for the off-topic question. Best regards, Jean ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] FRP demos and tutorials page
Hi,
since I never took the time to understand frp properly I thought it would be
helpful to look at some examples. I was able to compile and run the first to
programs after I managed to find out the dependencies. But I failed to compile
third one. I just got the a compiler error with ghc-6.12.1 on Mac OS X 10.6,
see below.
Best regards,
Jean
leibniz:robot_sim jmg$ ./go
Compiling Generator
[1 of 2] Compiling Model( Model.hs, Model.o )
[2 of 2] Compiling Main ( Main.hs, Main.o )
Linking main ...
Compiling Player
[1 of 5] Compiling ReadImage( ReadImage.hs, ReadImage.o )
[2 of 5] Compiling Sprites ( Sprites.hs, Sprites.o )
[3 of 5] Compiling ViewSupport ( ViewSupport.hs, ViewSupport.o )
ViewSupport.hs:32:7:
No instance for (MatrixComponent Double)
arising from a use of `scale' at ViewSupport.hs:32:7-11
Possible fix:
add an instance declaration for (MatrixComponent Double)
In the expression: scale
In the definition of `scal': scal = scale
ViewSupport.hs:100:9:
No instance for (NormalComponent Double)
arising from a use of `normal' at ViewSupport.hs:100:9-33
Possible fix:
add an instance declaration for (NormalComponent Double)
In a stmt of a 'do' expression: normal (Normal3 nx ny nz)
In the second argument of `($)', namely
`do { normal (Normal3 nx ny nz);
mapM_
(\ ((vx, vy, vz), tcoord)
- do { texCoord tcoord;
})
(zip ([q0] ++ [q1] ++ [q2] ++ [q3]) ts) }'
In the expression:
renderPrimitive Quads
$ do { normal (Normal3 nx ny nz);
mapM_
(\ ((vx, vy, vz), tcoord)
- do { texCoord tcoord;
})
(zip ([q0] ++ [q1] ++ [q2] ++ [q3]) ts) }
ViewSupport.hs:102:18:
No instance for (TexCoordComponent Double)
arising from a use of `texCoord' at ViewSupport.hs:102:18-32
Possible fix:
add an instance declaration for (TexCoordComponent Double)
In a stmt of a 'do' expression: texCoord tcoord
In the expression:
do { texCoord tcoord;
vertex $ Vertex3 vx vy vz }
In the first argument of `mapM_', namely
`(\ ((vx, vy, vz), tcoord)
- do { texCoord tcoord;
vertex $ Vertex3 vx vy vz })'
ViewSupport.hs:103:18:
No instance for (VertexComponent Double)
arising from a use of `vertex' at ViewSupport.hs:103:18-23
Possible fix:
add an instance declaration for (VertexComponent Double)
In the first argument of `($)', namely `vertex'
In the expression: vertex $ Vertex3 vx vy vz
In the expression:
do { texCoord tcoord;
vertex $ Vertex3 vx vy vz }
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Feedback request: priority queues in containers
Hi, I think this is my first post to this list although I've been reading it for a long time. So, please, be patient with me and my post. On 03/16/2010 02:29 PM, Louis Wasserman wrote: * We offer Functor, Foldable, and Traversable instances that do not respect key ordering. All are linear time, but Functor and Traversable in particular assume the function is monotonic. The Foldable instance is a good way to access the elements of the priority queue in an unordered fashion. (We also export mapMonotonic and traverseMonotonic, and encourage the use of those functions instead of the Functor or Traversable instances.) So, it is possible to break the invariants of your priority queue by using fmap with a non-monotonic function, right? I see that it might be usefull to have such instances, sometimes. As it is not possible to hide instances, once they are definded, I'd propose to not offer those instances by default. Instead you could provide implementations of all the instance functions necessary to define this instances yourself. Or one could have a newtype wrapper around the priority queue for which instances of Function, Foldable, and Traversable are defined. This would allow to activate the nice instances on demand but to stay safe by default. Best regards, Jean-Marie ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Interpreting profiling results
Hi, Daniel Fischer wrote: total alloc = 165,728 bytes (excludes profiling overheads) COST CENTREMODULE %time %alloc CAFGHC.Handle 0.0 10.7 CAFText.Read.Lex 0.02.1 CAFGHC.Read 0.01.2 square Main 0.02.8 solve Main 0.01.3 show_aVx Main 0.03.7 readsPrec_aYF Main 0.0 60.6 main Main 0.09.6 genNumsMain 0.05.0 cell Main 0.01.2 individualinherited COST CENTRE MODULE no.entries %time %alloc %time %alloc MAIN MAIN 1 0 0.00.3 0.0 100.0 mainMain 186 1 0.09.6 0.0 85.6 show_aVx Main 196 2 0.03.7 0.03.7 cell Main 197 16 0.00.0 0.00.0 solve Main 188 5 0.01.3 0.0 11.8 genNums Main 189 8 0.05.0 0.0 10.4 square Main 194 88 0.02.8 0.03.2 cellMain 195 16 0.00.4 0.00.4 col Main 192 4 0.00.7 0.01.1 cellMain 193 16 0.00.4 0.00.4 row Main 190 4 0.00.7 0.01.1 cellMain 191 16 0.00.4 0.00.4 readsPrec_aYF Main 187 3 0.0 60.6 0.0 60.6 CAF GHC.Read 151 1 0.01.2 0.01.2 CAF Text.Read.Lex 144 8 0.02.1 0.02.1 CAF GHC.Handle 128 4 0.0 10.7 0.0 10.7 CAF GHC.Conc 127 1 0.00.0 0.00.0 Does the column 'entries' represent the number of times the function was called? Number of times it was 'entered', not quite the same as the number of times it was called. I think (Warning: speculation ahead, I don't *know* how the profiles are generated) it's thus: Say you call a function returning a list. One call, first entry. It finds the beginning of the list, the first k elements and hands them to the caller. Caller processes these, asks can I have more, or was that it?. Same call, second entry: f looks for more, finds the next m elements, hands them to caller. Caller processes. Repeat until whatever happens first, caller doesn't ask whether there's more or callee finds there's nothing more (or hits bottom). Warning: speculation ahead, but is based on my knowledge on other profilers. Many profilers work statistically, they interrupt a program at more less random (or equal) intervals and inspect the stack, whick is of course quite difficult in Haskell as far as I understand it. I have interpreted the entries column as an indication for the amount of profile interrupts which happened when a function f was on top of the stack, whatever that means in Haskell. The manual of GHC 6.10.4, chapter 5 states: The actual meaning of the various columns in the output is: entries The number of times this particular point in the call graph was entered. So for me the question remains open, is entries a precisely counted value or a statistically determined one? Best regards, Jean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: I just don't get it (data structures and OO)
Hi, On 06.06.2007, at 07:00, Phlex wrote: So here is one more question : Let's say I want unique System names across the Universe ... that would mean i need to have a Data.Map in the Universe, with Name keys and System values. Since all data are values instead of references, would i end up with two copies of each System (in Universe's Data.Map and in its Galaxy), or would these be shared somehow ? In other words, should i go for integer (or maybe access key/tuple) identified objects or just put the System in both Data.Maps it belongs to ? That depends. In an OO world everything has its own implicit identity. The new operator in Java provides you with an object with a new and unique key which is not easy to observe. But most formal semantics have it. One can think of it as the address of the allocated object. In FP there are no objects, there are only terms. Whether two terms are identically is answered by a structural traversal over the values and subvalues. Now, I return to your question. What makes your objects galaxies, planets, stars, etc. unique? Is it their coordinate in space, their name, their structural position in your tree? What is it? Let's assume you say their names are unique. Then you only have to store a set of all names used in your universe. If you want a planet which orbits around star a to be different form another planet that is in orbit of star b, although both planets are the same in every other aspect. Then you might think about introducing arbitrary unique integer keys. This is similar to database design. There are those normal form laws [1] which guide you to improve your db schema. In database design there are people who introduce artificial primary keys almost always. Although there are natural primary keys most of the time. I hope these random thoughts help a bit to change the perspective. Regards, Jean-Marie [1] http://en.wikipedia.org/wiki/Database_normalization ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance and STUArrays
Hi Dominic, Dominic Steinitz wrote: I've been playing around some more trying improve the performance of the SHA1 implmentation in the crypto library. I've isolated one of the functions and implemented it using a) unfold and b) STUArray The STUArray implementation is about twice as fast but I was expecting an order of magnitude improvement given I thought I would have been allocating 16 x 80 new 32 bit words with unfold but nothing with the STUArray. Should I have been disappointed? [EMAIL PROTECTED]:~/sha12 time ./arrTest 17 STUArray /dev/null real0m11.102s user0m9.129s sys 0m0.112s [EMAIL PROTECTED]:~/sha12 time ./arrTest 17 Unfold /dev/null real0m18.381s user0m16.361s sys 0m0.212s code snipped I did not have time to look into your code yet. But the question whether this is only a constant factor improvement or an implementation with a different time complexity can only be researched by a series of experiments with different input sizes. An interpretation of a series of results of experiments is more meaningful than just one data point. Greets, Jean-Marie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: A question about functional dependencies and existential
Hi Oleg and others, [EMAIL PROTECTED] wrote: Jean-Marie Gaillourdet wrote: class T root pos sel | pos - root, root - sel where f :: pos - sel - Bool instance T root (Any root) sel If that is correct, I don't understand why this instance should be to general, as every instantiation of root exactly determines the corresponding instantiation of Any root. The class T has two functional dependencies: pos - root and root-sel. I believe you are talking about the former whereas my previous message was talking about the latter. But the same applies to the second functional dependency and the type variable sel. Every instantiation of root determines the instantiation of sel. And that forbids instance T Int (Any Int) Bool and instance T Int (Any Int) Int inside the same scope, doesn't it? At least, that is what I would like to express by those two fundeps. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: A question about functional dependencies and existential quantification
Hi,
[EMAIL PROTECTED] wrote:
The problem is not related to existentials, so we just drop them
{-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-}
module TestCase where
data Any root = ANY
class T root pos sel | pos - root, root - sel where
f :: pos - sel - Bool
instance T root (Any root) sel
test x = f ANY x
Hugs and GHC 6.4 both complain about the instance of T:
Hush (September 2006 version) says
ERROR /tmp/j.hs:9 - Instance is more general than a dependency allows
and GHC 6.4.2 says
Illegal instance declaration for `T root (Any root) sel'
(the instance types do not agree with the functional dependencies
of the class)
In the instance declaration for `T root (Any root) sel'
As I understand functional dependencies, and I am definitely _not_ an
expert on them, they state, that given the lhs of a dependency is
instantiated, the type variables of the rhs are determined, too.
If that is correct, I don't understand why this instance should be to
general, as every instantiation of root exactly determines the
corresponding instantiation of Any root.
I concur. The class declares T as being a ternary relation such that
the following holds
forall r p p' s s'. T(r,p,s) T(r,p',s') - s = s'
Now, the instance `T root (Any root) sel' is satisfied when
root=Int, sel = Bool and when root=Int, sel = Int. Does it not? That
falsifies the above proposition. In other words, the instance T is not
functional with respect to the first and the third arguments.
That is not surprising. What is surprising is why GHC 6.6 accepts such
an instance?
GHC 6.6 does not accept such instances. Add the following code to the
module TestCase
instance T Int Int Int
instance T Int Int Bool
and you get the following error:
TestCase.hs:10:0:
Functional dependencies conflict between instance declarations:
instance T Int Int Int -- Defined at TestCase.hs:10:0
instance T Int Int Bool -- Defined at TestCase.hs:11:0
-- Jean-Marie
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A question about functional dependencies and existential quantification
Hi,
I am trying to do something like the following:
{-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-}
module TestCase where
data Any root = forall pos sel . T root pos sel = ANY pos
class T root pos sel | pos - root, root - sel where
f :: pos - sel - Bool
instance T root (Any root) sel where
f (ANY p) s = f p s
There is a multi-parameter type class T with some functional
dependencies. And I want do define an almost general type for T, Any
root. I would like to have that type in T as well. But ghc is not able
to type check f. It gives:
TestCase.hs:10:7:
Couldn't match expected type `sel1' (a rigid variable)
against inferred type `sel' (a rigid variable)
`sel1' is bound by the pattern for `ANY' at TestCase.hs:10:7-11
`sel' is bound by the instance declaration at TestCase.hs:9:0
When using functional dependencies to combine
T root pos sel, arising from use of `f' at TestCase.hs:10:18-22
T root pos sel1,
arising from is bound by the pattern for `ANY'
at TestCase.hs:10:7-11
at TestCase.hs:10:7-11
In the pattern: ANY p
In the definition of `f': f (ANY p) s = f p s
I think sel1 and sel are equal, because the root in the type of (ANY
p) on the left side is the same as the root of the type of f p s on
the right side. From that should follow with help of the functional
dependency that sel1 and sel are the same types. Do I misunderstand the
type system or is that a weakness of GHC? Or am I trying to do something
silly?
I have a solution that involves requiring sel to be in Typeable and
using cast and I never came across a runtime error, so far. Is there a
better way to express that?
Any enlightenment is appreciated.
Regards,
Jean-Marie
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A question about functional dependencies and existential quantification
Hi, thanks for your quick answer. Do you have any predictions when System F_c in GHC will be available for usage? Regards, Jean-Marie Simon Peyton-Jones wrote: What you want to do is perfectly reasonable -- but it cannot be translated into System F and that's why GHC rejects it. GHC now has a richer intermediate language that *can* handle this; see our paper http://research.microsoft.com/~simonpj/papers/ext-f. Manuel and Martin and I are now working on the *source*-language aspects, incl type inference. When we are done, we'll be able to compile your program, or at least one very like it. So, stay tuned. Meanwhile thank you for the example. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Bug with in-place installation on Mac OS X
Hi,
I have two bugs to report. The second occured when I tried to report
the first one via Trac. I followed the link in chapter 1.2 of ghc
latest user-guide and came to a page stating that I should login with
username guest and password guest. The login did not work for me with
Safari and Camino (Mozilla.org's Mac browser). guest seems not to be
a valid username and password.
But now to the first problem. I would like to install ghc-6.6 as
downloaded from http://haskell.org/ghc/dist/6.6/ghc-6.6-i386-apple-
darwin.tar.bz2 in /opt/ghc-6.6.
Here are the steps I did:
$ cd /opt
$ tar xjvf ~/Desktop/ghc-6.6-i386-apple-darwin.tar.bz2
$ cd ghc-6.6
$ ./configure
$ make in-place
$ cd
$ export PATH=$PATH:/opt/ghc-6.6/bin/i386-apple-darwin/
$ ghc
/opt/ghc-6.6/bin/i386-apple-darwin/ghc: line 12: /usr/local/lib/
ghc-6.6/ghc-6.6: No such file or directory
/opt/ghc-6.6/bin/i386-apple-darwin/ghc: line 12: exec: /usr/local/lib/
ghc-6.6/ghc-6.6: cannot execute: No such file or directory
$ which ghc
/opt/ghc-6.6/bin/i386-apple-darwin/ghc
$ cat /opt/ghc-6.6/bin/i386-apple-darwin/ghc
#! /bin/sh
bindir='/opt/ghc-6.6/bin/i386-apple-darwin'
libdir='/opt/ghc-6.6/lib/i386-apple-darwin'
libexecdir='/opt/ghc-6.6/lib/i386-apple-darwin'
datadir='/opt/ghc-6.6/share'
SED='/usr/bin/sed'
DEFAULT_TMPDIR='/tmp'
#!/bin/sh
GHCBIN=/usr/local/lib/ghc-6.6/ghc-6.6;
TOPDIROPT=-B/usr/local/lib/ghc-6.6;
# Mini-driver for GHC
exec $GHCBIN $TOPDIROPT ${1+$@}
The INSTALL file says I should run ./configure without any prefix I
want to do an in-place installation. So I would say one or the other
is wrong.
Thanks for your great work on ghc!
Best regards,
Jean-Marie
PGP.sig
Description: This is a digitally signed message part
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
