Re: [Haskell-cafe] Language shootout (reloaded)
On 10/02/06, Stefan Holdermans <[EMAIL PROTECTED]> wrote: > Don Stewart wrote: > > > P.S. I remember having a discussion on #haskell 2 weeks ago where > > we all > > agreed that Haskell placing #1 was pretty much impossible. Did we have > > an inferiority complex? > > Still---and, please, forgive me for this---I feel that us being #1 > now tells us more about the Haskell community than it tells us about > Haskell. > The Haskell community is an important part of Haskell. :) - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language shootout (reloaded)
Don Stewart wrote: P.S. I remember having a discussion on #haskell 2 weeks ago where we all agreed that Haskell placing #1 was pretty much impossible. Did we have an inferiority complex? Still---and, please, forgive me for this---I feel that us being #1 now tells us more about the Haskell community than it tells us about Haskell. Regards, Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Numerical methods in Haskell
Hello Creighton, Friday, February 10, 2006, 12:45:21 AM, you wrote: CH> Between google searching and looking through the activity CH> report, I take it that no one has really developed serious CH> libraries for matrix manipulations, diff eqs, etc. it was a discussion and development in this direction, but seems that there is no ultimate result see for example june thread "Re: [Haskell-cafe] matrix computations based on the GSL" -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Language shootout (reloaded)
Just so we can feel that we're doing the right things :) On the great language shootout, as of last night, we're: * Ranked overall number 1, by a good margin: * Ranked number 1 on lines of code * Ranked number 2 on speed. http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all Thanks to everyone who's contributed to the entries over the last few weeks, on the wiki, and on this list. Cheers, Don P.S. I remember having a discussion on #haskell 2 weeks ago where we all agreed that Haskell placing #1 was pretty much impossible. Did we have an inferiority complex? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] standard poll/select interface
On 09.02 22:24, Bulat Ziganshin wrote: > as i understand this idea, transformer implementing async i/o should > intercept vGetBuf/vPutBuf calls for the FDs, start the appropriate > async operation, and then switch to another Haskell threads. the I/O > manager thread should run select() in cycle and when the request is > finished, wake up the appropriate thread. what's all. if you will ever > need, this implementation can then be used to extend GHC's System.IO > internals with the support for new async i/o managers (as i > understand, select() is now supported by GHC, but poll(), kqueue() is > not supported?). the only difference that my lib gives an opportunity > to test this implementation without modifying GHC I/O internals, what > is somewhat simpler. so, interface for async vGetBuf/vPutBuf routines > should be the same as for read/write: > > type FD = Int > vGetBuf_async :: FD -> Ptr a -> Int -> IO Int > vPutBuf_async :: FD -> Ptr a -> Int -> IO Int Please don't fix FD = Int, this is not true on some systems, and when implementing efficient sockets one usually wants to hold more complex state. > JM> Don't take the absence of a feature in jhc to mean I don't like or want > JM> that feature. There are a lot of things I don't have but that I'd > JM> definitly want to see in the language simply because I was only shooting > JM> for H98 to begin with and was more interested in a lot of the back end > JM> stuff. You should figure out the nicest design that uses just the > JM> extensions needed for the design you want. it could help us decide what > JM> goes into haskell-prime to know what is absolutely needed for good > JM> design and what is just nice to have. > > this simply means that the Streams library cannot be used with JHC, > what is bad news, because it is even more rich than GHC's System.IO. > jhc had chance to get modern I/O library. but it lost that chance :) I think it is more like "all haskell-prime programs". Seriously, if we design a new IO subsystem it would be quite nice to be able to use it from standard conforming programs. Maybe things can be reformulated in a way that will be compatible with haskell-prime. > please look. at this moment Sreams library lacks only a few important > features, already implemented in GHC's System.IO: sockets, line > buffering and async i/o. moreover, i don't have an experience in > implementing the async i/o, so foreign help is really necessary If you want I can look at getting network-alt to implement the interface. - Einar Karttunen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Emulating bash pipe/ process lib
On Thu, 9 Feb 2006, Bulat Ziganshin wrote: > Thursday, February 09, 2006, 8:58:27 PM, you wrote: > DC> "Slow" devices like pipes, sockets etc. get along fine with Handles > DC> or whatever buffered I/O - as long as you have only one going at a time. > DC> Multiple input sources - like, say you want to read a process' output > DC> (unit 1) and diagnostic output (unit 2) separately, and either one has > DC> the potential to fill up the pipe and block while you're waiting for > DC> input on the other pipe - buffers at least complicate the dispatching > DC> mechanics you need for this, if not make it impossible. > > are you tried LineBuffering and NoBuffering? seem that it is developed > exactly for this case (plus for terminals) That's part of the idea, it helps keep the data out of buffers where select or whatever can't see it. But then you need functions with semantics that really support unbuffered I/O. When select tells you that the device is readable, you don't know that there is one full line, or how many bytes there are, so hGetLine doesn't apply here, nor would the Haskell equivalent of fread(3) if there were one. The only thing left is hGetChar - one char, then select, then another. (And multi-byte chars cause us to worry about this.) Since POSIX read(2) already supports exactly the functions you need for unbuffered I/O, it's simpler, easier and more efficient to leave the whole business right there at the file descriptor level. I'm sure you can make a non-buffering buffer layer work on top of the file descriptor, but what makes it worth the trouble? Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Numerical methods in Haskell
Hi, Between google searching and looking through the activity report, I take it that no one has really developed serious libraries for matrix manipulations, diff eqs, etc. Are there any practical reasons for this or is it just a matter of the haskell community being small and there not being many people interested in something so specialized? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] FFI Wiki Page (was: FFI question)
Bulat wrote: > we need to establish FFI > page on the wiki and give at least links to all this packages and > small info about using FFI with ghc/hugs There is such a page (to be more precise, a section of a page): http://haskell.org/hawiki/LibrariesAndTools section "FFI Preprocessors" Also there are http://haskell.org/hawiki/FfiCookbook and http://haskell.org/hawiki/FfiTutorial pages. -- Dimitry Golubovsky Anywhere on the Web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Emulating bash pipe/ process lib
Hello Donn, Thursday, February 09, 2006, 8:58:27 PM, you wrote: DC> "Slow" devices like pipes, sockets etc. get along fine with Handles DC> or whatever buffered I/O - as long as you have only one going at a time. DC> Multiple input sources - like, say you want to read a process' output DC> (unit 1) and diagnostic output (unit 2) separately, and either one has DC> the potential to fill up the pipe and block while you're waiting for DC> input on the other pipe - buffers at least complicate the dispatching DC> mechanics you need for this, if not make it impossible. are you tried LineBuffering and NoBuffering? seem that it is developed exactly for this case (plus for terminals) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] FFI question
Hello Duncan, Thursday, February 09, 2006, 8:45:01 PM, you wrote: DC> There is also c2hs which is well supported and is used for several large DC> C bindings: there is also hsffig by Dmitry Golubovsky. we need to establish FFI page on the wiki and give at least links to all this packages and small info about using FFI with ghc/hugs -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] standard poll/select interface
Hello John, Thursday, February 09, 2006, 3:19:30 AM, you wrote: >> JM> If we had a good standard poll/select interface in System.IO then we >> JM> actually could implement a lot of concurrency as a library with no >> JM> (required) run-time overhead. I'd really like to see such a thing get >> JM> into the standard. Well, mainly it would just be a really useful thing >> JM> to have in general. If others think it is a good idea I can try to come >> JM> up with a suitable API and submit it to the repo. >> >> i have delayed answering to this letter until i announced my Streams >> library. now i can say that such API already exists - in terms of my >> library you need just to write an transformer that intercepts >> vGetBuf/vPutBuf calls and pass them to the select/poll machinery. so >> you can write such transformer just now and every program that uses >> Streams will benefit from its usage. Converting programs that use >> Handles to using Streams should be also an easy task. JM> I was actually asking for something much more modest, which was the JM> routine needed to pass them to the select/poll machinery. but yeah, what JM> you say is one of my expected uses of such a routine. Once a standard IO JM> library settles down, then I can start working on the exact API such a JM> routine would have. but if all will wait while the library settles down, it will never occur :) your work can change design of library, like the my library itself can change the shape of haskell' :) at this moment, i just developed the library which satisfy demands in extending current I/O library by new features, such as Unicode support, high speed, portability to other compilers, binary i/o, i/o for packed strings, and asynchronous i/o using methods other than select(). but i don't implement all these features actually, i just developed infrastructure, in which all these features can be easily added. unlike the System.IO library, you don't need to ask someone to implement new features or make corrections in foreign sources. you just need to develop module what implements this standard Stream interface and then it can be used as easy as transformers from the library itself as i understand this idea, transformer implementing async i/o should intercept vGetBuf/vPutBuf calls for the FDs, start the appropriate async operation, and then switch to another Haskell threads. the I/O manager thread should run select() in cycle and when the request is finished, wake up the appropriate thread. what's all. if you will ever need, this implementation can then be used to extend GHC's System.IO internals with the support for new async i/o managers (as i understand, select() is now supported by GHC, but poll(), kqueue() is not supported?). the only difference that my lib gives an opportunity to test this implementation without modifying GHC I/O internals, what is somewhat simpler. so, interface for async vGetBuf/vPutBuf routines should be the same as for read/write: type FD = Int vGetBuf_async :: FD -> Ptr a -> Int -> IO Int vPutBuf_async :: FD -> Ptr a -> Int -> IO Int i think that implementations for ghc and jhc should be slightly different, though, because of different ways to implement multi-threading. but the I/O manager should be the same - it just receives info about I/O operations to run and returns information about completed ones. ... well, this I/O manager should implement just one operation: performIO :: Request -> IO () type Request = (IOType, FD, Ptr a, Int, Notifier) data IOType = Read | Write | ... type Notifier = Result -> IO () data Result = OK Int | Fail ErrorInfo "performIO" starts new I/O operation. On the completion of this operation, Notifier is called with information about results of execution. so, for the GHC the following should work: vGetBuf_async fd ptr size = do done <- newMVar let notifier = putMVar done () performIO (Read, fd, ptr, size, notifier) takeMVar done for JHC, the body of "vGetBuf_async" may be different if you will find this interface reasonable, at least for the first iteration, i will develop appropriate transformer, so for you remains "only" the implementation of "performIO" >> of course, Streams library is not some standard just now, and moreover >> - it is not compatible with JHC. the greatest problem is what i using >> type classes extensions available in GHC/Hugs what is not in H98 >> standard. so, i'm interested in pushing Haskell' to accept most >> advanced possible extensions in this area and, of course, in actual >> implementing these extensions in the Haskell compilers. alternative >> way to make Streams available to wider range of Haskell compilers is >> to strip support of streams working in monads other that IO. JM> Don't take the absence of a feature in jhc to mean I don't like or want JM> that feature. There are a lot of things I don't have but that I'd JM> definitly want to see in the language simply because I was only shooting JM> for H98 to begin with and was
Re: [Haskell-cafe] Emulating bash pipe/ process lib
On Thu, 9 Feb 2006, Marc Weber Marc Weber wrote:
...
> So my simple test looks like this:
>
>
> module Main where
> import System.IO
> import System.Posix.IO
>
> main = do
> (fdIn,fdOut) <- createPipe
> let (iohIn, iohOut) = (fdToHandle fdIn, fdToHandle fdOut)
> hIn <- iohIn
> hOut <- iohOut
> hPutStr hIn "test"
> line <- hGetLine hOut
> print line -- should now print test having been piped through my pipe
>
> but I get the error:
> pipe2: : hPutStr: illegal operation (handle is not
> open for writing)
That's right. "The first component is the fd to read from, the second
is the write end." You're writing to the read end.
> And in current CVS docs in base.System.Process.hs it is said that
> createPipe is no longer exported ?
Maybe they're just going to export functions like this under their
common POSIX names ("pipe", "dup2"), and bring them more into line
with standard behavior (execve takes argv[0..n], not argv[1..n].)
"Slow" devices like pipes, sockets etc. get along fine with Handles
or whatever buffered I/O - as long as you have only one going at a time.
Multiple input sources - like, say you want to read a process' output
(unit 1) and diagnostic output (unit 2) separately, and either one has
the potential to fill up the pipe and block while you're waiting for
input on the other pipe - buffers at least complicate the dispatching
mechanics you need for this, if not make it impossible. For my money,
it makes more sense to learn how deal with pipes directly at the file
descriptor level, and at worst if the committees find it too unsightly
you may have to write FFI interfaces to get pipe() back.
Donn Cave, [EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI question
On Thu, 2006-02-09 at 09:27 -0800, Donn Cave wrote: > On Thu, 9 Feb 2006, Christopher Brown wrote: > > Frederico, > > > > Have you tried using Green Card? > > > > http://haskell.org/greencard/ > > > > It is basically a foreign function pre-processor for Haskell. It > > allows your Haskell programs to interface with C libraries in a very > > straight forward way. > > I tried it, and managed to get it working to some extent. Then > I found out about hsc2hs and the current FFI support in ghc, and > I noticed that according to http://www.haskell.org/greencard/ , > the current version of Green Card is an alpha release from 2003. > > >From comparison of the two, my impression is that this parrot is > dead, and everyone is just too polite to say so. Unfortunately, > this inability to pull the shades on Green Card, Haskell Direct, > etc., takes away a little from ghc's outstanding FFI. There is also c2hs which is well supported and is used for several large C bindings: http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ It works at a higher level than hsc2hs and can make writing bindings quite a bit simpler and cleaner. For example the cairo bindings use it: http://darcs.haskell.org/gtk2hs/cairo/Graphics/Rendering/Cairo/ see the various .chs files, for example: http://darcs.haskell.org/gtk2hs/cairo/Graphics/Rendering/Cairo/Internal/Drawing/Paths.chs Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI question
On Thu, 9 Feb 2006, Christopher Brown wrote: > Frederico, > > Have you tried using Green Card? > > http://haskell.org/greencard/ > > It is basically a foreign function pre-processor for Haskell. It > allows your Haskell programs to interface with C libraries in a very > straight forward way. I tried it, and managed to get it working to some extent. Then I found out about hsc2hs and the current FFI support in ghc, and I noticed that according to http://www.haskell.org/greencard/ , the current version of Green Card is an alpha release from 2003. >From comparison of the two, my impression is that this parrot is dead, and everyone is just too polite to say so. Unfortunately, this inability to pull the shades on Green Card, Haskell Direct, etc., takes away a little from ghc's outstanding FFI. Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Betreft: Re: [Haskell-cafe] Elementary HaXml question
[EMAIL PROTECTED] writes: > foldXml (txt ?> keep :> > fontSize4 /> tag "em" ?> mkSubtitle :> > children) > now transforms > Hello World > into > > > I still have a problem with the other example: > Hello World Ah, I see. In the first case, you simply change the tag into , keeping the tag exactly the same. But in the second case, you not only want to change into , but also to move the tag from outside the to inside. I think you need something like this: mkSubtitle `o` (tag "em" /> fontSize4 /> mkElem "em") |>| children i.e. build an around the children of the tag, and then build the subtitle around the outside of that. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Elementary HaXml question
> I'm new to Haskell and HaXml and I'm playing around with the latter to
> clean some (well-formed) 'legacy' html. This works fine except for the
> following cases. Some of the elements to be cleaned are:
>
> Hello World
> Hello World
>
> This should become:
>
> Hello World
>
> From what I could gather from the documentation, it should be something
> like:
>
> foldXml (txt ?> keep :>
> (attrval("size",AttValue[Left "4"]) `o` tag "font")
>/> tag "i" ?> replaceTag "h1" :> children)
Is the bracketing correct? I can't remember the precedence of the
operators offhand, but perhaps it should be
foldXml (txt ?> keep :>
(((attrval("size",AttValue[Left "4"]) `o` tag "font")
/> tag "i") ?> replaceTag "h1" :> children))
Yes, the braketing is correct since the following code:
foldXml (txt ?> keep :>
fontSize4 /> tag "em" ?> mkSubtitle :>
children)
fontSize4 = (attrval("size",AttValue[Left "4"]) `o` tag "font")
mkSubtitle = mkElemAttr "h1" [("class", ("subtitle"!))]
[children]
now transforms
Hello World
into
Which I'm satisfied with (hurray!). The appears because I 'keep' it
higher in the original switch, the example above is just an extract for
brevity's sake.
I still have a problem with the other example:
Hello World
I _think_ the line in the .hs file should be:
tag "em" /> fontSize4 ?> mkSubtitle :>
Which doesn't work, and I don't know why. If the first example works,
shouldn't the second, too? I also tried
tag "em" /> font ?> mkSubtitle :>
Which doesn't work either. I transformed it into
tag "font" `o` children `o` tag "em" ?> mkSubtitle :>
without avail. Again, any ideas are welcome. (btw: I like HaXml, Malcolm,
nice work!)
Koen.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Elementary HaXml question
[EMAIL PROTECTED] writes:
> I'm new to Haskell and HaXml and I'm playing around with the latter to
> clean some (well-formed) 'legacy' html. This works fine except for the
> following cases. Some of the elements to be cleaned are:
>
> Hello World
> Hello World
>
> This should become:
>
> Hello World
>
> From what I could gather from the documentation, it should be something
> like:
>
> foldXml (txt ?> keep :>
> (attrval("size",AttValue[Left "4"]) `o` tag "font")
>/> tag "i" ?> replaceTag "h1" :> children)
Is the bracketing correct? I can't remember the precedence of the
operators offhand, but perhaps it should be
foldXml (txt ?> keep :>
(((attrval("size",AttValue[Left "4"]) `o` tag "font")
/> tag "i") ?> replaceTag "h1" :> children))
Regards,
Malcolm
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Emulating bash pipe/ process lib
On 2/9/06, Marc Weber Marc Weber <[EMAIL PROTECTED]> wrote: > Hi. I want to write a little haskell program executing about 4 programs > passing data via pipes. As my python script seems to be slower than a > bash script I want to try a ghc executable now. > It should invoke different parts of a text to speech chain. This way I > have one interface then. There is also the HsShellScript library, which has many utilities for using Haskell as a shell programming language, including good support for piping. You can find it here: http://www.volker-wysk.de/hsshellscript/ -- Kurt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: FFI question
Thank you Simon... That was just what I needed... Short and simple. I would like also to thank all for the answers. That will be surely helpful too, if not for me, maybe for someone else. On 2/9/06, Simon Marlow <[EMAIL PROTECTED]> wrote: > Frederico Franzosi wrote: > > I'll try to make it short. > > > > I'm developping a package wich imports C functions. > > > > the fact is that when I try to compile if I call the compiler in the > > usual way, using -package and -llib it gives an undefined reference > > error... > > > > For example if I use: > > $ghc -package PKGname-PKGversion -fffi -o main Main.hs -llib > > > > it gives an error message (undefined references of objects from PKG to > > functions in lib) > > > > > > but if I use: > > > > $ghc -fffi -o main Main.hs -llib /path/to/PKGlib.a > > > > it compiles correctly. > > It looks like -llib is appearing earlier on the linker's command line > than the library from your package, when you use -package. You haven't > specified a dependency between the two, so GHC is making an arbitrary > choice. > > The right way to fix this, if your package depends on a library, is to > include that library in the "extra-libraries" field of the package. > > Cheers, > SImon > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Emulating bash pipe/ process lib
Marc Weber Marc Weber wrote: Hi. I want to write a little haskell program executing about 4 programs passing data via pipes. As my python script seems to be slower than a bash script I want to try a ghc executable now. It should invoke different parts of a text to speech chain. This way I have one interface then. Talar und #haskell told me that I might use runProcess and pass handles for stdin and out created by createPipe and fdToHandle. So my simple test looks like this: module Main where import System.IO import System.Posix.IO main = do (fdIn,fdOut) <- createPipe let (iohIn, iohOut) = (fdToHandle fdIn, fdToHandle fdOut) hIn <- iohIn hOut <- iohOut hPutStr hIn "test" line <- hGetLine hOut print line -- should now print test having been piped through my pipe but I get the error: pipe2: : hPutStr: illegal operation (handle is not open for writing) And in current CVS docs in base.System.Process.hs it is said that createPipe is no longer exported ? If you want to communicate with external programs via pipes, then System.Process should provide everything you need. Take a look at runInteractiveProcess in particular. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type inference
Brian Hulley wrote: Fred Hosch wrote: Is type inferencing in Haskell essentially the same as in SML? The most significant difference certainly is that type inference has been beefed up with type classes in Haskell, which are quite a powerful mechanism refining Hindley/Milner inference. Besides that, Haskell allows some additional programs for which types can /not/ be inferred (e.g. the examples Brian was giving), while SML does not. SML also has a complicated thing called the "value restriction" because it allows mutable references to be altered via side effects. Because Haskell has no side effects, there is no need for a value restriction. Although there is no "need" for it, Haskell still has it, in minor variation. It is commonly known as "The Dreaded Monomorphism Restriction" ;). - Andreas -- Andreas Rossberg, [EMAIL PROTECTED] Let's get rid of those possible thingies! -- TB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: FFI question
Frederico Franzosi wrote: I'll try to make it short. I'm developping a package wich imports C functions. the fact is that when I try to compile if I call the compiler in the usual way, using -package and -llib it gives an undefined reference error... For example if I use: $ghc -package PKGname-PKGversion -fffi -o main Main.hs -llib it gives an error message (undefined references of objects from PKG to functions in lib) but if I use: $ghc -fffi -o main Main.hs -llib /path/to/PKGlib.a it compiles correctly. It looks like -llib is appearing earlier on the linker's command line than the library from your package, when you use -package. You haven't specified a dependency between the two, so GHC is making an arbitrary choice. The right way to fix this, if your package depends on a library, is to include that library in the "extra-libraries" field of the package. Cheers, SImon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Elementary HaXml question
Hi all,
I'm new to Haskell and HaXml and I'm playing around
with the latter to clean some (well-formed) 'legacy' html. This works fine
except for the following cases. Some of the elements to be cleaned are:
Hello
World
Hello World
This should become:
Hello
World
I can build filters to find , or , but the combination does not seem
to work.
From what I could gather from the documentation, it
should be something like:
foldXml (txt ?>
keep :>
(attrval("size",AttValue[Left "4"])
`o` tag "font") /> tag "i" ?> replaceTag "h1"
:>
children)
This doesn't work. I am clearly missing something
elementary here, so any hints are welcome.
Cheers,
K.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI question
On 2/9/06, Frederico Franzosi <[EMAIL PROTECTED]> wrote: Hi, I don't really know how this stuff exactly works, but here's few things I have found useful when I ran into this sort of problems. > I'm developping a package wich imports C functions. > For example if I use: > $ghc -package PKGname-PKGversion -fffi -o main Main.hs -llib > > it gives an error message (undefined references of objects from PKG to > functions in lib) I don't have exact answer, but ghc uses ld under the hood and sometimes the order of libraries on ld command line matters. Here's few things that might be useful if that's the case. Use ghc -v and find final link ld/gcc (I don't recall which one ghc invokes for linking) and try that line yourself, you can also move libraries up on list etc to find what order you actually need. Add -llib to the options in package.conf as a library- try adding as first and try adding as last. Try both ;-) Try adding as object file, ie /path/to/lib.a Order of arguments on ghc command line doesn't matter so much, because ghc will put (if I recall correctly) package libraries first and then add -llib and such options to the end on the ld command line- so it's pretty hard to work around the problem just by invoking ghc different way. > $ghc -fffi -o main Main.hs -llib /path/to/PKGlib.a > > it compiles correctly. > > > and also when I do: > > $ghc -package PKGname-PKGversion -fffi -o main Main.hs /path/to/lib.a If I were to guess these work because /path/to/lib.a is handled as an object file, which is somehow different from being library. I have no knowledge what and why there is this sort of magic restrictions. HTH, -Esa ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI question
Hello Frederico, Thursday, February 09, 2006, 5:08:12 AM, you wrote: FF> I'm developping a package wich imports C functions. it depends on the details of your use. things go far away from the times where FFI addendum was published, but there is no good docementation, afaik. first, there are a number of FFI-helper packages, that are directed to simplify use of additional features, such as importimg constans, enums, structures, i.e. things not in FFI standard second, GHC nowadays can much easier use C functions. i personally do the following: ghc -c module.c ghc --make main.hs module.o and use module.h with usual declarations of function types while the main.hs contains import staements like the foreign import ccall unsafe "module.h __w_stat_ctime" wst_ctime :: Ptr CWStat -> IO CTime foreign import ccall unsafe "module.h __w_stat_atime" wst_atime :: Ptr CWStat -> IO CTime here< C functions __w_stat_ctime and __w_stat_ctime imported with giving them in Haskell program names wst_ctime and wst_atime. hope it will help. if not - give us additional details about your usage of FFI. -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI question
Frederico, Have you tried using Green Card? http://haskell.org/greencard/ It is basically a foreign function pre-processor for Haskell. It allows your Haskell programs to interface with C libraries in a very straight forward way. Chris. On 9 Feb 2006, at 02:08, Frederico Franzosi wrote: I'll try to make it short. I'm developping a package wich imports C functions. the fact is that when I try to compile if I call the compiler in the usual way, using -package and -llib it gives an undefined reference error... For example if I use: $ghc -package PKGname-PKGversion -fffi -o main Main.hs -llib it gives an error message (undefined references of objects from PKG to functions in lib) but if I use: $ghc -fffi -o main Main.hs -llib /path/to/PKGlib.a it compiles correctly. and also when I do: $ghc -package PKGname-PKGversion -fffi -o main Main.hs /path/to/lib.a it compiles correctly. I know that it is surely my mistake but I didn't find anything helpful in docummentation or in FFI list. I know that I should send this message to ffi mailing list but it is kind of stopped and I think I'll get my answers here... Thank you for the atention. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Christopher Brown Ph.D. Student University of Kent. UK. http://www.cs.kent.ac.uk/people/rpg/cmb21/index.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type inference
Cale Gibbard wrote: On 09/02/06, Brian Hulley <[EMAIL PROTECTED]> wrote: Brian Hulley wrote: f :: forall m. (forall a. a->m a) -> c -> d -> (m c, m d) Of course this type doesn't work on your original example, since (,) is a type constructor with two parameters, not one, but this type signature does actually work just fine in GHC. --- data Pair x = Pair x x deriving Show data Id x = Id x deriving Show f :: forall m c d. (forall a. a -> m a) -> c -> d -> (m c, m d) f g x y = (g x, g y) --- *Main> f (\x -> Pair x x) 3 "hello" (Pair 3 3,Pair "hello" "hello") *Main> f (\x -> Id x) 3 "hello" (Id 3,Id "hello") Perhaps in practice this kind of workaround is sufficient, although this requires you to put the results into a form that can be syntactically matched against m a. I wonder though if it would be possible to have a type system that would work for my original example by automatically creating internal declarations type T1 a = (a,a) and type T2 a = a so that m would match against T1 and T2 respectively. It is difficult to know if this would be a worthwhile thing to do or if most practical applications of polymorphism in any case involve transformations whose shape can be captured sufficiently with multi-param typeclasses etc. Regards, Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
