Re: Preventing/handling space leaks
Sven Panne [EMAIL PROTECTED] writes: [ Just one more mail and I promise to shut up on this topic... :-) ] Surely slamming C++ is on topic? :-) Fergus Henderson wrote: [...] C does suffer from many of the same problems as C. But in C++, it is much easier to automate techniques like reference counting, which can be done manually in C but are much more cumbersome and error-prone when done manually. Granted, C++'s (copy) constructors, destructors and assignment operators make some things relatively easy compared to C, but the complexity of handling exceptions *correctly* makes things worse again: There is a famous article (I can't remember the title or the author) where a well-known C++ grandmaster explains a stack class, but another later article by someone else describes the numerous bugs in that class when exceptions are taken into account. I think you're referring to this: http://www.awprofessional.com/content/images/020163371x/supplements/Exception_Handling_Article.html I'd also add that GC is more important in object oriented programming, it's more natural to pass objects around on a larger scale. At least IME. And one final remark on Haskell and Java: In large projects in those languages you usually get the genuine space leaks in those languages plus all those nice little leaks from the ubiquitous native functions/methods. So you have to debug in at least two languages at the same time and I haven't seen combined tool support for this yet I'm not sure I understand what you mean. Examples? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Preventing/handling space leaks
Henk-Jan.van.Tuyl [EMAIL PROTECTED] writes: L.S., (Whom?) Does anyone know about documentation (preferably on the Web) on how to prevent/find/remove space leaks? Are there any differences between Hugs and GHC or any other Haskell platform, regarding space leaks? I should probably invest the time to learn Hat or Buddha or something, but I find I get pretty far using GHCs (mostly adopted from NHC, I believe) memory profiling. Look it up in the (excellent) User Guide! Java, for example, does not have [space leaks] Makes me wonder why my Java-using aquaintances are so frustrated about it, then... :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Why are strings linked lists?
Lennart Augustsson [EMAIL PROTECTED] writes: Glynn Clements wrote: What Unicode support? Simply claiming that values of type Char are Unicode characters doesn't make it so. Just because some implementations lack toUpper etc. doesn't mean they all do. I think the point is that for toUpper etc to be properly Unicoded, they can't simply look at a single character. IIRC, there are some characters that expand to two characters when the case is changed, and then there's titlecase and so on. toUpper etc. are AFAIK only implemented correctly for a small (but IMHO probably the useful) subset of characters. Hbc has had those implemented for maybe 10 years. I must admit I haven't looked at HBC -- are these functions implemented properly for codepoints 127? Outside the ISO-8859-x ranges? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: How to best add logging/debugging code?
Johannes Waldmann [EMAIL PROTECTED] writes:
f x y = ( ... ) { info = parens $ fsep [ text f, info x, info y ] }
Cool!
that way you always know who built what.
and it's cheap - if you don't use this information,
then it's never created (due to laziness).
Uh..is that really true? I would think it would keep a lot of data
from being garbage collected?
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: How to best add logging/debugging code?
Ben Escoto [EMAIL PROTECTED] writes: Hi all, does anyone have any tips on how to insert debugging or logging statements through a program? 1. Use some kind of logging monad. 2. Use unsafePerformIO or similar. It seems this must come up a lot when writing Haskell programs. What do most pople do? The latter. In my case, it's more for debugging than logging, so I can live with somewhat weak guarantees. If you need to do it more properly, the simple solution might be to limit logging to when you're in the IO monad anyway? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: DiffArray Performance
Glynn Clements [EMAIL PROTECTED] writes: Stefan Reich wrote: I'd like to ask a general question about unsafePerformIO: What exactly does unsafe mean? Just impure or rather may lead to all kinds of problems, you better don't use this? Essentially both. Haskell assumes purity (referential transparency), so impurity is likely to result in all kinds of problems. Here's a thing that can easily happen: my_trace = unsafePerformIO . putStrLn f x = trace f called `seq` Now, when f is evaluated, it will print the message. However, when f is re-evaluated (normally with a different x), no message is printed! Why? Because the system will optimize by realizing that 'trace' is called with the same argument, and it will just keep the old value (). This behaviour depends on the level of optimization in your compiler/interpreter, feel free to experiment! The fix is of course to do my_trace (f called with arg ++show x) `seq` ... which will usually do what you expect. Moral: unsafe means you can use it, but it doesn't give you any complaining rights when it doesn't do what you think it should do. (Sometimes in my darker moments, I feel we might bite the bullet, and call the whole thing unsafeHaskell, and be done with it :-) -kzm PS: trace is defined in the libraries, not sure if it behaves more reasonable in this respect. -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: determining if a int is a power
[EMAIL PROTECTED] writes: I'm new to haskell and have to do some excersises. Okay. Thank you for being up-front about it. You got some advice, so I'll just add that So i have been trying using any with a helper function Yep, this is a good way to do it. You may want to consider filter or map as well, depending on what you want for result. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: time since the epoch
Stefan Karrmann [EMAIL PROTECTED] writes: a while ago time calculation was subject on this list. Now, I have a time library based on the TAI (international atomic time) time scale. This is cool! But what actually happens when people post interesting library code to the list? Does somebody snarf it, and put it in a more convenient place? Why not upload it into the Haskell library site at Sourceforge, and just post a description and a pointer? http://sourceforge.net/projects/haskell-libs/ -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Transmitting Haskell values
Hal Daume III [EMAIL PROTECTED] writes:
What sent me first into deep confusion is that I found all of
{Text,GHC}.{Read,Show} first, and the Read classes marked as
nonportable GHC extensions. Quite disheartening :-(
Well, then I found the Prelude definition (though it's entirely unclear
how they relate to the Text and GHC versions).
The GHC versions are simply more efficient versions. Show and Read are
completely portable.
AIIEE! Now they tell me -- I've optimized one of my programs, and it
now spends most of it's time 'read'ing. So the thing is just to
import GHC(read) instead of using the Prelude version? I guess it's
worth a try (although I expect I really need to go to binary IO)
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Optimization options?
Juanma Barranquero [EMAIL PROTECTED] writes: So, when we want very fast code, we use: -O -fvia-C. I remember this from a long time ago (a couple of years, at least) I was under the impression it was no longer current. Is it still true? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: implement hash table
[EMAIL PROTECTED] (Donald Bruce Stewart) writes: I'm a new one in this Haskell programming language. Okay, since you're new, I won't take your question too literally. :-) I have a program which involved a lot of computation tasks and it's quite inefficient,so I'm currently examing the possibility of using hash table in my data structure, can some one tell me how to implement it? I can't find much information about it. http://www.haskell.org/ghc/docs/latest/html/base/Data.HashTable.html Note that this lives in the IO monad. This may be fine for your purposes, but are you quite sure you need a hash table, and that you can't use either Data.Set or Data.FiniteMap instead? These used balanced trees, and have O(log n) access times, but IME that is fine for most purposes (and given hierarchical memory systems on modern computers, one could argue that you get this from a hash table, too) http://www.haskell.org/ghc/docs/latest/html/base/Data.FiniteMap.html http://www.haskell.org/ghc/docs/latest/html/base/Data.Set.html -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Reading Floats
Hi, I recently encountered something I found a bit peculiar when reading floats from strings. Leading zeroes seem okay, as long as there is no decimal point. To wit: Main (map read [1.0, 0, 01, 01.0]) :: [Float] [1.0,0.0,1.0,*** Exception: Prelude.read: no parse Neither is leading decimal point allowed: Main (read .01) :: Float *** Exception: Prelude.read: no parse Is this how it's supposed to be? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Feature-request (was: Re: IO behaves oddly if used nested)
Simon Marlow [EMAIL PROTECTED] writes: You don't need to know :-) It's actually in the base package, but GHCi knows about all hierarchical libraries without having to specify any extra command-line arguments. Ai! And here I've been doing :set -package all this time. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
