- Haskell-Cafe - Haskell.org

Download binary file
by Jorge Guerra 15 Nov '05

15 Nov '05

Hi everyone, I'm trying to download a binary file (an mp3) from a given URL, at the moment I've found two possible solutions: 1) Use the Network.Socket library from ghc to get the file. The problem with this is that I'll have to deal with the HTTP protocol (done), and read the Handle in binary mode however I don't understand how to do this, in particular how to deal with the buffer (Prt?). 2) Use a system program like wget in linux systems. But I don't know how to call a system command from haskell, and besides I wan't my program to be portable at least between windows and linux. Any sugestions? Sorry for my newbie question. Thanks. -- Jorge E. Guerra D. Departamento de Computación y Tecnología de la Información Universidad Simón Bolívar

2 1

Re: [Haskell-cafe] Two questions: lazy evaluation and Church-Rosser
by Ezra Cooper 15 Nov '05

15 Nov '05

Gregory, Church-Rosser is proved in any good text on lambda calculus, such as Barendregt [1]. Some rather detailed notes on that book are at [2]. Lazy evaluation is often formalized as "call-by-need." Try [3]. Ezra [1] Barendregt. The Lambda Calculus <http://www.amazon.com/exec/obidos/ASIN/0444875085> [2] <http://www.andrew.cmu.edu/user/cebrown/notes/barendregt.html> [3] Maraist, Odersky, and Wadler, "A call-by-need lambda-calculus." Journal of Functional Programming 8(3):275-317 (May 1998). <http://homepages.inf.ed.ac.uk/wadler/topics/call-by-need.html> On Nov 15, 2005, at 5:30 AM, Gregory Woodhouse wrote: > This is surely a dumb question, but where can I find a proof of the > Church-Rosser theorem? > > Now, a totally(?) separate question: I've been trying to do some > background reading on lambda calculus, and have found discussions of > strict evaluation strategies (call-by-value and call-by-name) but > have yet to find an appropriate framework for modeling lazy evaluation > (much less infinite lists and comprehensions). Can anyone point me in > the right direction?

1 0

Semantics for FP?
by Gregory Woodhouse 15 Nov '05

15 Nov '05

First of all, I'm very new to Haskell (but very impressed). I remember having a lot of fun with Lisp as an undergrad, and recently started working with Scheme (and having a great time at it), and so I decided to look into Haskell. Like everyone else, I was totally impressed by the two line quicksort -- and hooked. Unfortunately(?), though, FP seems to pose a bit of a challenge from a semantic point of view. I remember being very impressed with "Dynamic Logic" (Harel et al.), and it really changed my way of thinking about programming languages. But are Kripke structures even of any relevance to Haskell and FP? Well, in order to think it through, I've been experimenting with the idea of reduction providing the basic accessibility relation. That's why I've been asking seemingly off-topic questions about lambda calculus and C-R (well- definedness). === Gregory Woodhouse gregory.woodhouse(a)sbcglobal.net "The whole of science is nothing more than a refinement of everyday thinking." -- Albert Einstein

1 0

warning HEAP: creating uncommited range
by Joel Reymont 14 Nov '05

14 Nov '05

Folks, Does this ring a bell with anyone? logon.exe is a binary that I built with -O -debug and ran from within gdb on Windows. warning HEAP:[logon.exe] warning: Failing creating uncommitted range (7fbfc000 for 5000) Thanks, Joel -- http://wagerlabs.com/

1 0

Re: [Haskell] Making Haskell more open
by Gour 14 Nov '05

14 Nov '05

Sven Panne (Sven.Panne(a)aedion.de) wrote: > * DocBook XML can be transformed into a very rich collection of output > formats: XHTML, HTML Help, DVI, PS, PDF, FO, plain text, etc. etc. txt2tags has the following backends: HTML, XHTML, SGML, LaTeX, Lout, man, Magic Point, Moin Moin, Page Maker 6.0 & plain text. > * But what's more important: Compared to the more exotic markup mechanisms > proposed, it is well-known and extremely well documented. There are tons of > web sites, books, articles, etc. etc. about DocBook XML. Proposing more > arcane technologies will drastically reduce the amount of people actually > contributing to an Open Source project, a fact which is easily overlooked. But don't forget, as it was already stated, get the whole working-chain ready for authoring in Docbook is not at all ready and for one not proficient in emacs with SGML mode it is very difficult to write texts with so many tags. otoh, e.g. for 'txt2tags' python is the only requirement and it is therefore multi-platform soulution where one can start writing documentation in 15min. Besides that, 'txt2tags-like technology' is already in use for some time - e.g AFT (http://www.maplefish.com/todd/aft.html) dating back in '99 and XMLmind XML Editor has plugin which supports (similar) markup called APT (http://www.xmlmind.com/xmleditor/_distrib/doc/apt/apt_format.html) quote: "Aptconvert is an OpenSource command-line tool that can be used to convert the APT format to HTML, XHTML, PDF, PostScript, (MS Word loadable) RTF, DocBook SGML and DocBook XML." However, the main point in using such tool is productivity & simplicity. How many tags from DocBook DTD are actually used in GHC manual and how many of them are required for HTML output? Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD

5 7

Re: [Haskell] Making Haskell more open
by Gour 14 Nov '05

14 Nov '05

Wolfgang Jeltsch (wolfgang(a)jeltsch.net) wrote: > The font size is much smaller than the font size of other webpages. So if I > would change the default font size to give good results with the Haskell > website, all other websites would have their text in very large letters. Well, haskell.org has smaller font size for the links, but the my preferred portal site (www.iskon.hr) has even smaller. However, pressing 'Ctrl +' to increase font size is, imoho, not such a big task :-) > The question is if HTML is sufficient. In addition, HTML is at some points > not well thought-out. True, but considering the present situation, it is all what is required. Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD

4 3

Re: [Haskell] Making Haskell more open
by Gour 13 Nov '05

13 Nov '05

Wolfgang Jeltsch (wolfgang(a)jeltsch.net) wrote: > The most important question is: Does txt2tags use logical markup? A kind of, e.g. = title = == subtitle == === subsub...=== if this is logical ;) Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD

1 0

Re: [Haskell] Making Haskell more open
by Gour 13 Nov '05

13 Nov '05

Wolfgang Jeltsch (wolfgang(a)jeltsch.net) wrote: > In addition, one could argue that since newsgroups were specifically > designed for discussions, newsgroup software allows proper mangagement > of threads but, well, current e-mail programs might do this in similar > quality. >From the most plain mailers like pine & mutt, to the gui-mailers (kmail, evolution), all have threading support. Sincerely, Gour p.s. I am moving this reply to cafe. -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD

1 0

Please explain behavior of setBit
by Murray Gross 13 Nov '05

13 Nov '05

Here is my trivial program: import Bits main = putStr (show(bit 0::Int)++" "++show (mybit 0)) mybit:: Int -> Int mybit x = setBit (bit 0) x The output (with GHC-5) is 1 1 My question: Why is (bit 0) equal to 1 and not 0? That first bit is set regardless of the value of x (I have tried several), although in each case, the bit I expect to be set is also set (e.g., mybit 4 yields 17). Thanks in advance for assistance. Murray Gross

2 2

RE: [Haskell-cafe] Re: FPS: Finalizers not running (was Memoryusageoutside of the Haskell heap)
by Simon Marlow 12 Nov '05

12 Nov '05

On 07 November 2005 12:07, Donald Bruce Stewart wrote: > simonmar: >> Finalizers aren't guaranteed to be run. In particular, if the main >> thread exits, then we don't run any outstanding finalizers. This >> change was made recently, but it turned out that even prior to 6.4 >> we couldn't guarantee to run all outstanding finalizers. >> >> Does this explain it, or is there something else going on? >> >> BTW, when you addForeignPtrConcFinalizer to a ForeignPtr created with >> mallocForeignPtr, you're *creating* a finalizer, it doesn't have one >> to start with. It's pretty expensive to do this. > > Ah, right, I see. It's: > > mallocForeignPtr = doMalloc undefined > where doMalloc :: Storable b => b -> IO (ForeignPtr b) > doMalloc a = do > IO $ \s -> > case newPinnedByteArray# size s of { (# s, mbarr# #) > -> (# s, ForeignPtr (byteArrayContents# > (unsafeCoerce# mbarr#)) > (MallocPtrNoFinalizer mbarr#) #) } > where (I# size) = sizeOf a > > So the GC will take care of these thingies? > Now, this probably means that the problem is somewhere else in > Joelr's code. Yes, mallocForeignPtr's are implemented using pinned GC'd memory, with no finalizer (unless you add one). That's why they're nice and fast. It looks like you have an old version of GHC.ForeignPtr there - it has a bug in it, please cvs update to the latest version. Cheers, Simon

5 7