Re: [Haskell-cafe] Build dependency problem with bytestring.
Don Stewart wrote: jstrait: Hi all, I'm upgrading HAppS from my 0.9.2 to the current 0.9.2.1 in Hackage. Some HAppS components have built and installed (IxSet and Util). Halfway through the HAppS-State build, the GHC runtime linker gives a fatal error on finding a duplicate definition for symbol fps_minimum while loading bytestring 0.9.0.4 after having already loaded bytestring 0.9.0.1. From trial and error, I'm guessing that HAppS-State needs 0.9.0.1 but one of its build dependencies was built with 0.9.0.4. Using GHC 6.8.2 Linux here. Any suggestions on how best to currently approach this situation? . you need to uninstall your happs build, uninstall bytestring 0.9.0.1, and start over, so all packages link against 0.9.0.4 only. Cheers, Don Thanks for the response, Don. I ended up unregistering and rebuilding many more packages against bytestring 0.9.0.4 that had previously been built against 0.9.0.1. However, GHC itself had been built with bytestring 0.9.0.1, and was showing up as broken in the package listing. So, when I was done fighting the missing dependency errors, I just reinstalled bytestring 0.9.0.1 and let the rest be, for now. Another issue I had, and I don't think this is the intended behavior of Cabal, is that when using 'cabal install --global' as root, lib files from the package would be placed under the root's own .cabal/lib/ directory. So, as a different user, I would be unable to access those lib files if they were needed for my own local build. I had to add the option '--libdir=/usr/lib/ghc-6.8.2/lib' on install, something I thought should have been implicit when using the --global option. Jon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Analysing Haskell with Graph Theory
(CC'd to the list) On 07/03/2008, Dusan Kolar [EMAIL PROTECTED] wrote: I'm just wondering what algorithms you use for analysis. For instance, clique is an NP complete problem. Do you use some approximation? If yes, which? I'm particularly interested in the algorithm. I haven't gotten that far yet ;-) As it stands, my supervisor have discussed this slightly and I'll probably start off with a more-or-less brute-force approach. This should be OK as the graph will probably be reasonably sparse and (hopefully) not too big! -- Ivan Lazar Miljenovic ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Emping 0.4
Hello All, Emping 0.4, a utility which can derive heuristic rules from facts in Open Office Calc spreadsheet .csv format, has been released on HackageDB. Version 0.4 supports blank fields, treated as 'none of the others', which allows for split attribute values. For example, Owns Car could have values Yes or 'No, and then Yes could be split into Make, Price Range and so on, while the fields for No could be blank for these attributes. Data still have to be in the spreadsheet format of rows and columns (and in OO Calc .csv). Version 0.4 has a Gtk2Hs based GUI and the code has been changed in several places. Compiled with GHC 6.8 it appears to be noticeably faster than version 0.3. The package comes with a user guide, a white paper, and two data files from the UCI Machine Learning Repository. To get an impression see: http://j-van-thiel.speedlinq.nl/emp/empug.html The compiled binary for Linux, with documentation, can also be downloaded directly from my web site. Thank you, Hans van Thiel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Build dependency problem with bytestring.
On Fri, 2008-03-07 at 00:59 -0800, Jon Strait wrote: Don Stewart wrote: jstrait: Hi all, I'm upgrading HAppS from my 0.9.2 to the current 0.9.2.1 in Hackage. Some HAppS components have built and installed (IxSet and Util). Halfway through the HAppS-State build, the GHC runtime linker gives a fatal error on finding a duplicate definition for symbol fps_minimum while loading bytestring 0.9.0.4 after having already loaded bytestring 0.9.0.1. From trial and error, I'm guessing that HAppS-State needs 0.9.0.1 but one of its build dependencies was built with 0.9.0.4. Using GHC 6.8.2 Linux here. Any suggestions on how best to currently approach this situation? . you need to uninstall your happs build, uninstall bytestring 0.9.0.1, and start over, so all packages link against 0.9.0.4 only. Cheers, Don Thanks for the response, Don. I ended up unregistering and rebuilding many more packages against bytestring 0.9.0.4 that had previously been built against 0.9.0.1. However, GHC itself had been built with bytestring 0.9.0.1, and was showing up as broken in the package listing. So, when I was done fighting the missing dependency errors, I just reinstalled bytestring 0.9.0.1 and let the rest be, for now. The current development version of cabal detects theses problems of inconsistent versions of dependencies and warns about them and provides detail on what packages have conflicting dependencies. The next step is rather harder which is to get cabal-install to make installation plans that avoid the problem in the first place, possibly by rebuilding existing packages against different versions of their dependencies. Another issue I had, and I don't think this is the intended behavior of Cabal, is that when using 'cabal install --global' as root, lib files from the package would be placed under the root's own .cabal/lib/ directory. So, as a different user, I would be unable to access those lib files if they were needed for my own local build. I had to add the option '--libdir=/usr/lib/ghc-6.8.2/lib' on install, something I thought should have been implicit when using the --global option. Sorry about that. You'll be glad to know however that we fixed it the other day. Upgrade to the latest darcs version of the Cabal lib and cabal-install. If you find the problem isn't fixed or you run into other issues please do report them! :-) http://hackage.haskell.org/trac/hackage/ Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Analysing Haskell with Graph Theory
Ivan Miljenovic [EMAIL PROTECTED] writes: Can anyone think of any other kind of functions that would be useful in this kind of source code analysis? Sometimes, it's not obvious where to draw boundaries between modules, perhaps finding a smallest cut (if that is the correct term) could help to minimize the interfaces? I.e. find tightly connected components that have relatively few inbound links. Sounds like an interesting project, good luck! -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Analysing Haskell with Graph Theory
On Fri, Mar 7, 2008 at 1:45 AM, Ivan Miljenovic [EMAIL PROTECTED] wrote: Can anyone think of any other kind of functions that would be useful in this kind of source code analysis? Will you be considering parallel programs? Also, perhaps some information flow analysis would be interesting. Arnar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Analysing Haskell with Graph Theory
On 07/03/2008, Arnar Birgisson [EMAIL PROTECTED] wrote: Will you be considering parallel programs? Also, perhaps some information flow analysis would be interesting. What do you mean by parallel programs? The parallelism hints used by ghc? In that case, I'll be supporting whatever the parser I can find supports :p -- Ivan Lazar Miljenovic ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Analysing Haskell with Graph Theory
On 07/03/2008, Ketil Malde [EMAIL PROTECTED] wrote: Sometimes, it's not obvious where to draw boundaries between modules, perhaps finding a smallest cut (if that is the correct term) could help to minimize the interfaces? I.e. find tightly connected components that have relatively few inbound links. As in the seeing if a module can be split into sub-modules (i.e. disjoint or nearly disjoint sub-graphs inside the module graph)? I was thinking about something like that a few days ago but had forgotten about it when discussing it with my supervisor. (It doesn't help that he's mainly a C-programmer, and doesn't really understand what I mean when I talk about modules). -- Ivan Lazar Miljenovic ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Analysing Haskell with Graph Theory
On Fri, Mar 7, 2008 at 12:42 PM, Ivan Miljenovic
[EMAIL PROTECTED] wrote:
On 07/03/2008, Arnar Birgisson [EMAIL PROTECTED] wrote:
Will you be considering parallel programs? Also, perhaps some
information flow analysis would be interesting.
What do you mean by parallel programs? The parallelism hints used by
ghc? In that case, I'll be supporting whatever the parser I can find
supports :p
I mean parallel programs in general. For example, you mention that
preferably one would want main to be the only function that has no
incoming edges. With parallel programs that may not be the case. This
ties into also considering reactive programs (i.e. programs which main
function is of the form while (1) { ... }). I'm not quite sure if it
fits the project you describe, but looking for certain properties like
possible deadlocks or livelocks in such programs is something of
interest.
There is also a security angle to this. Consider two agents, one
representing an ATM and one representing the branch office of a bank.
Analysing the possible possible information paths between the two can
help you define a clear interface between the two (assuming one
doesn't exist already). Having such an interface rigorously defined
helps with maintaining security properties.
Also related to considering parallel programs are coroutines.
Analysing the call graph of systems of coroutines might be
interesting as well.
I'm just thinking outloud though, some of these might not be
interesting at all :)
cheers,
Arnar
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Small displeasure with associated type synonyms
On Fri, Mar 07, 2008 at 08:07:57AM +0100, Tom Schrijvers wrote: Am I correct in thinking this would have worked if it were an associated type instead of an associated type synonym? ie, class C a where data T a val :: T a Yes, you are. Associate data type constructors (as well as ordinary algebraic data constructors) are injective. So we have: Yay, that's what I though! (but was hesitant to suggest anything, since I've never actually used associated anything...) It's nice to hear that I do understand some of this stuff. :) -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Network.Socket Woes
Hi all, I'm trying to do some standard socket stuff using the Network.Socket library. This example is a UDP server: import Network.Socket proto_udp :: ProtocolNumber proto_udp = 17 port = 10162 main = do s - socket AF_INET Datagram 17 bindSocket s (SockAddrInet (PortNum port) iNADDR_ANY) putStrLn $ Listening on port ++ (show port) ++ ... (msg, n, addr) - recvFrom s 1024 putStrLn $ Received ++ (show n) ++ bytes from ++ (show addr) ++ : putStrLn (show msg) Using the equivalent C program (socket, bind, recvfrom) I'm able to successfully receive a 64 byte message from my test program. The Haskell version, however, does not return from recvFrom. I've also tried wrapping this in a withSocketsDo, with no effect. How can I proceed to debug/troubleshoot this program? Thanks, - Scott Bell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Network.Socket Woes
On Fri, Mar 7, 2008 at 8:10 AM, Scott Bell [EMAIL PROTECTED] wrote: my test program. The Haskell version, however, does not return from recvFrom. I've also tried wrapping this in a withSocketsDo, with no effect. So this is a long standing, ah, issue with the Network modules. Try sending a UDP packet to port 45607 and you'll find that the Haskell code gets it. hex(45607) = 0xb227 0x27b2 = 10162 In short, PortNum doesn't do the endian conversion for you. And I don't know a good way to figure out the endianness of the underlying system from Haskell I'm afraid. I usually end up FFIing out to htons or just assuming that the system is little-endian. We should really fix this unless there's some trick that I've been missing all this time. AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Network.Socket Woes
Adam, This does the trick, thanks! I certainly would not have been able to track down such an insidious `issue' without much agony and despair. - Scott On Fri, Mar 7, 2008 at 10:48 AM, Adam Langley [EMAIL PROTECTED] wrote: On Fri, Mar 7, 2008 at 8:10 AM, Scott Bell [EMAIL PROTECTED] wrote: my test program. The Haskell version, however, does not return from recvFrom. I've also tried wrapping this in a withSocketsDo, with no effect. So this is a long standing, ah, issue with the Network modules. Try sending a UDP packet to port 45607 and you'll find that the Haskell code gets it. hex(45607) = 0xb227 0x27b2 = 10162 In short, PortNum doesn't do the endian conversion for you. And I don't know a good way to figure out the endianness of the underlying system from Haskell I'm afraid. I usually end up FFIing out to htons or just assuming that the system is little-endian. We should really fix this unless there's some trick that I've been missing all this time. AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Issues(Bugs?) with GHC Type Families
On Fri, Mar 7, 2008 at 2:10 AM, Ryan Ingram [EMAIL PROTECTED] wrote: I don't think the cost is that great; the compiler can easily flag polymorphic functions that require type information for some or all arguments and in many cases the type evidence can be passed just-in-time when calling from a non-polymorphic function into a polymorphic function. As I understand it, the cost in performance isn't too bad. For example, JHC uses type-passing to implement type classes. One problem is that a language with pervasive typecase has weaker guarantees. For example, in present-day Haskell we can tell that length :: [a] - Int works the same for every type 'a' just by looking at the type signature. That's not the case if we can call typecase in arbitrary functions. We can avoid that problem by requiring a type representation parameter, or otherwise indicating the use of typecase in the signature. Modern Haskell provides this with the Typeable class. (Which, in JHC, is essentially empty.) Thus, another solution for writing the show instance for lists is: class (Typeable a) = Show [a] where show s = case cast s of Just str - \ ++ str ++\ Nothing - showList s where showList ... To summarize: we can make more claims about a function with type forall a. F a - G a than one with type forall a. (Typeable a) = F a - G a, even though every type can (as far as I know) be made an instance of Typeable. -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Network.Socket Woes
Hello Adam, Maybe you could use the binary package [1] to always encode the portNumber, etc. in network byte order? Such as available put/get functions: putWord16be :: Word16 - Put Hope this helps... __ Donnie 1. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-0.4.1 On 3/7/08, Adam Langley [EMAIL PROTECTED] wrote: On Fri, Mar 7, 2008 at 8:10 AM, Scott Bell [EMAIL PROTECTED] wrote: my test program. The Haskell version, however, does not return from recvFrom. I've also tried wrapping this in a withSocketsDo, with no effect. So this is a long standing, ah, issue with the Network modules. Try sending a UDP packet to port 45607 and you'll find that the Haskell code gets it. hex(45607) = 0xb227 0x27b2 = 10162 In short, PortNum doesn't do the endian conversion for you. And I don't know a good way to figure out the endianness of the underlying system from Haskell I'm afraid. I usually end up FFIing out to htons or just assuming that the system is little-endian. We should really fix this unless there's some trick that I've been missing all this time. AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Network.Socket Woes
On Fri, Mar 07, 2008 at 10:56:32AM -0700, Scott Bell wrote: Adam, This does the trick, thanks! I certainly would not have been able to track down such an insidious `issue' without much agony and despair. (haskell-cafe, my apologies for a message that's only tangentially on-topic. The content might be helpful, especially if you're writing socket apps.) Assuming you're on Linux, there are a few handy tools for this job: * 'netstat -nlp' (show listeners, with process name, numeric) * lsof -p $pid (list open file descriptors for PID) * strace -p $pid (trace system calls in running process) * strace /path/to/executable (trace system calls to stderr) * ls -l /proc/$pid/fd (peek at kernel's view of PID's fd table) There's also dtrace on Solaris and OS X, but I don't use those OSes, so I'm not too familiar with it. In Windows, there seems to be an embarassment of riches when it comes to profiling tools. Hope this helps, -- /jbm, but you can call me Josh. Really, you can! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Network.Socket Woes
Adam Langley [EMAIL PROTECTED] writes: On Fri, Mar 7, 2008 at 8:10 AM, Scott Bell [EMAIL PROTECTED] wrote: my test program. The Haskell version, however, does not return from recvFrom. I've also tried wrapping this in a withSocketsDo, with no effect. So this is a long standing, ah, issue with the Network modules. Try sending a UDP packet to port 45607 and you'll find that the Haskell code gets it. hex(45607) = 0xb227 0x27b2 = 10162 In short, PortNum doesn't do the endian conversion for you. And I don't know a good way to figure out the endianness of the underlying system from Haskell I'm afraid. I usually end up FFIing out to htons or just assuming that the system is little-endian. The PortNumber type is an instance of Num, so it works if you do not use the PortNum constructor. Prelude Network.Socket case 10162 :: PortNumber of PortNum p - p 45607 Benedikt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Network.Socket Woes
On Fri, Mar 7, 2008 at 11:04 AM, Benedikt Schmidt [EMAIL PROTECTED] wrote: The PortNumber type is an instance of Num, so it works if you do not use the PortNum constructor. Prelude Network.Socket case 10162 :: PortNumber of PortNum p - p 45607 And there was the trick that I've been missing all this time ;) I'll probably submit a documentation patch for this since I'm a Bear of Little Brain and this wasn't obvious to me. -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Network.Socket Woes
Hello Adam, After taking a closer look, the network module does do the ntohs() FFI call: http://haskell.org/ghc/docs/latest/html/libraries/network/src/Network-Socket.html#PortNumber Thus, I think the issue is probably that Scott's UDP Client does not do the htons() for the port number, or if the UDP Client is in Haskell, then it is not using the Portnumber constructor. __ Donnie On 3/7/08, Adam Langley [EMAIL PROTECTED] wrote: On Fri, Mar 7, 2008 at 8:10 AM, Scott Bell [EMAIL PROTECTED] wrote: my test program. The Haskell version, however, does not return from recvFrom. I've also tried wrapping this in a withSocketsDo, with no effect. So this is a long standing, ah, issue with the Network modules. Try sending a UDP packet to port 45607 and you'll find that the Haskell code gets it. hex(45607) = 0xb227 0x27b2 = 10162 In short, PortNum doesn't do the endian conversion for you. And I don't know a good way to figure out the endianness of the underlying system from Haskell I'm afraid. I usually end up FFIing out to htons or just assuming that the system is little-endian. We should really fix this unless there's some trick that I've been missing all this time. AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Thanks for the help: image of draft visualization
Thanks for everyone's help on the list re my Haskell woes with the latest visualization effort. I've been making my code more generic for the last week, and I plan on releasing a visualization framework back to the community at some point. Gotta get approval from my boss before releasing code back to the wild, but here's an image of the draft of the visualization I've been working on: http://vizdata.renci.org/projects/jeff/ProteinViz/ProteinViz.png Basically, what you're seeing is 18,500 genes arranged in a full heirarchical clustering (the clustering technique uses a metric I'm unfamiliar with, and I got the dataset pre-packaged from the guy who's using it). The final visualization is fully interactive and runs fine under Linux, dies a miserable death under windows (runs out of RAM, and I can't figure out why, nor do I particularly care), and primarily runs on our 14 foot by 9 foot (4.5x3 metres for those of us in metric) linux display wall. The full program is about 800 linux of Haskell code using nothing but the standard library under GHC 6.8. Again, thanks for all your help! -- Jeff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Network.Socket Woes
On Mar 7, 2008, at 11:46 AM, Adam Langley wrote: And there was the trick that I've been missing all this time ;) I'll probably submit a documentation patch for this since I'm a Bear of Little Brain and this wasn't obvious to me. That would be great - I have been doing the same thing, and was just a minute short of sending in the FORTRAN Programmer's solution. It would have really made your eyes burn. Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Network.Socket Woes
On Fri, Mar 7, 2008 at 4:04 PM, Benedikt Schmidt [EMAIL PROTECTED] wrote: The PortNumber type is an instance of Num, so it works if you do not use the PortNum constructor. Prelude Network.Socket case 10162 :: PortNumber of PortNum p - p 45607 Considering that PortNumber implements toEnum/fromEnum, why is PortNum exported anyway? -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Thanks for the help: image of draft visualization
jefferson.r.heard: Thanks for everyone's help on the list re my Haskell woes with the latest visualization effort. I've been making my code more generic for the last week, and I plan on releasing a visualization framework back to the community at some point. Gotta get approval from my boss before releasing code back to the wild, but here's an image of the draft of the visualization I've been working on: [1]http://vizdata.renci.org/projects/jeff/ProteinViz/ProteinViz.png Basically, what you're seeing is 18,500 genes arranged in a full heirarchical clustering (the clustering technique uses a metric I'm unfamiliar with, and I got the dataset pre-packaged from the guy who's using it). The final visualization is fully interactive and runs fine under Linux, dies a miserable death under windows (runs out of RAM, and I can't figure out why, nor do I particularly care), and primarily runs on our 14 foot by 9 foot (4.5x3 metres for those of us in metric) linux display wall. The full program is about 800 linux of Haskell code using nothing but the standard library under GHC 6.8. Again, thanks for all your help! Truly awesome. Well done! Can't wait to see a writeup on your approach, and lessons learnt. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Data.HashTable
On 2008.03.06 22:43:53 +0100, Johannes Waldmann [EMAIL PROTECTED] scribbled 1.4K characters: In practice, Data.Map outperforms it in essentially all cases (Data.HashTable stops working beyond a certain size and so any asymptotic benefits, if they exist at all, don't have time to kick in). What! I learned at school, and I teach my students, * balanced binary tree: costs are log(size) * hashtable: cost are essentially constant therefore, hashtable should be preferred in almost all cases (if you know a reasonable hash function and except where you need persistency, of course) the difference should be visible even for moderate sizes (e.g. 1000). With a reasonable implementation I expect log(1000) = 10 comparisons (and dereferencings) for the tree; while the hashtable should have the computation of the hash value (ideally, in registers), one memory access, and one comparison. ... but indeed some experiments with Data.Map and Data.Hashtable support the point you made. That's either good for Data.Map or bad for Data.Hashtable. PS: I did not manage to compile HsJudy-1.0 with ghc-6.8.2 (some hsc file missing - perhaps that should be auto-generated? how?) Best regards, Johannes. Oh... I'm terribly sorry about that. It was I who uploaded HsJudy. The problem was, it's maintained by the Pugs project for some reason. The directory structure looks like: pugs/ thirdparty/ HsJudy/ hsregex/ HsSyck/ installed/ judy/ Judy-1.0.3/ Here Judy-1.0.3/ contains the actual C library Judy itself. So what the Cabalized package residing in HsJudy/ was doing was literally linking against stuff like '../judy/Judy-1.0.3/src/JudyL/*.o'. At the time I was packaging, Cabal didn't yet warn about problems like ../, so it would build and install just fine when I ran it with no problems; but I forgot that obviously all the ../ stuff would totally break in an sdist tarball. I think I've fixed it: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HsJudy-0.1.1. -- gwern Air eavesdropping pipe-bomb TSCM Centro ^X JIC TWA USACIL Protection pgpPeExTiZYSc.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [pdxfunc] pdxfunc meeting: Monday, March 10, 7pm, CubeSpace
The Portland Functional Programming group is meeting again this Monday, March 10, at 7 p.m. Join us! -- Forwarded message -- From: Igal Koshevoy [EMAIL PROTECTED] Date: Fri, Mar 7, 2008 at 11:26 AM Subject: [pdxfunc] pdxfunc meeting: Monday, March 10, 7pm, CubeSpace To: Igal Koshevoy [EMAIL PROTECTED] Join us at the next meeting of pdxfunc, the Portland Functional Programming Study Group. We'll have presentations, demos and discussions. We welcome programmers interested in all functional languages and our meetings have content for coders of all skill levels. If interested, please also subscribe to our mailing list at http://groups.google.com/group/pdxfunc PRESENTATION * Dr. Bart Massey: Audio Processing With Haskell - Abstract: Dr. Massey will discuss and demonstrate a Haskell implementation of a WAVE file I/O library and compressor-limiter application that he's been working on. He'll also talk about why he chose Haskell to do this. - Speaker: Dr. Bart Massey teaches Computer Science at Portland State University, focusing on open source software engineering and artificial intelligence. He's the current Secretary of the X.org Board of Directors, co-author of the Nickle open source programming language, and spent many years as the faculty advisor the Portland State Aerospace Society that builds open source sounding rockets. REMAINDER We'll spend the rest of the meeting doing open discussion, talking about projects, technical challenges, recent developments, etc. It's a good group with a lot of varied experience, so there won't be any shortage of interesting discussion. NEWS Don Stewart, who gave the group's first presentation, recently announced that the Haskell-based xmonad tiling window manager he helps write is now one year old (http://www.haskell.org/pipermail/xmonad/2008-March/005021.html) and the Real World Haskell book that he, Bryan O'Sullivan and John Goerzen are writing has released some new draft chapters for previewing (http://book.realworldhaskell.org/). Congratulations, Don! Anyway, see you at the meeting! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pdxfunc group. To post to this group, send email to [EMAIL PROTECTED] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pdxfunc?hl=en -~--~~~~--~~--~--~--- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Exception handling when using STUArray
Dear list, I'm using STUArray in some of my time critical number crunching code. I would like to know some way to catch the exceptions raised in the ST monad, ie. ArrayException. Looking through the Control.Exception module, I understand that those functions can only be used within IO monad. So my question is, what the best way to do exception handling in STUArray is. Plus, it would be helpful if I can also raise an exception in ST monad, but how? Thanks, Xiao-Yong -- c/*__o/* \ * (__ */\ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
