bindings to the xmms_remote API, GList and something more
Hi, I think there's a huge flaw in the Haskell design: if you conceive such a powerful and expressive programming language, one that empowers even the most ignorant computer user to write complex applications, instead of sticking to basic shell scripting - the only domain graspable by such stupid pseudo-coders -, well you end up with messages like this one flooding the mailing list you are providing for your users. This is what I call inevitability... To make a short story long, I needed some client for the Audacious media player, something I could use to remote control it and, since I'm addicted to Haskell, instead of surfing the web to find a suitable client I surfed the web to find the API documentation. With the FFI, in a matter of half an hour I had the client with all the commands I needed. (The long introduction was written just to let you know that you'd better not waste too much time with what follows...;-) So far so good, but, since everything was so easy, I thought: "Why not packaging a library (and the client) for Hackage? Maybe others may be willing to use it, maybe..." And then the problems start, problems due to my basic ignorance of the C language ("How comes you dare to import in Haskell functions written in a language you don't even understand?" you should replay!). Basically there are two C types I'm having problem with: 1. GList: even though I read the gtk2hs code I do not exactly understand how to create a GList to feed to this function: void xmms_remote_playlist_add(gint session, GList * list); As far as I understand this function takes a session number and a list of files' names. Still I seem not to be able to create a wrapper function around the imported one. 2. what a "gchar ** list" is? As far as my C goes, it should be an array of strings, right? What should I use on the Haskell side, newArray? void xmms_remote_playlist(gint session, gchar ** list, gint num, gboolean enqueue); 3. c2hs v. hsc2hs? Which should I prefer? In c2hs I write {#pointer * GList#}. What is the equivalent in hsc2hs? 4. As I said, I solved my personal problem: I imported enough functions to create the client I needed. Releasing the library is just something I would like to do, to give something back to the Haskell community. So this is something useful if I can provide robust and well designed code. This is a name space question: what is the name of the exported module? Sound.XMMS, Sound.XmmsRemote? Is the some kind of convention I should be referring to? Sorry if I was too long. Moreover I'm asking help I need just to publish a piece of software that is probably useless. Do not waste your time. But if you do, well... thank you, I really appreciate. Andrea
On Fri, Sep 21, 2007 at 09:08:13AM +0200, Andrea Rossato wrote:
Hi, I think there's a huge flaw in the Haskell design:
I don't know if this is a feature, the fact that most of the times you can find a solution to your problems by yourself, but only after polluting the haskell-cafe mailing list with your question...
Basically there are two C types I'm having problem with:
1. GList: even though I read the gtk2hs code I do not exactly understand how to create a GList to feed to this function:
void xmms_remote_playlist_add(gint session, GList * list);
As far as I understand this function takes a session number and a list of files' names. Still I seem not to be able to create a wrapper function around the imported one.
Well I used gtk2hs more carefully and that's the wrapper:
foreign import ccall unsafe "beepctrl.h xmms_remote_playlist_add"
c_xmms_remote_playlist_add :: CInt -> GList -> IO ()
xmms_remote_playlist_add :: Session -> [String] -> IO ()
xmms_remote_playlist_add s fns = do
l <- mapM newCString fns >>= toGList
c_xmms_remote_playlist_add (fromIntegral s) l
-- stolen from gtk2hs
#include
2. what a "gchar ** list" is? As far as my C goes, it should be an array of strings, right? What should I use on the Haskell side, newArray? void xmms_remote_playlist(gint session, gchar ** list, gint num, gboolean enqueue);
yes, indeed: foreign import ccall unsafe "beepctrl.h xmms_remote_playlist" c_xmms_remote_playlist :: CInt -> Ptr CString -> CInt -> {# type gboolean #} -> IO () xmms_remote_playlist :: Session -> [String] -> Bool -> IO () xmms_remote_playlist s l b = do la <- newArray =<< mapM newCString l c_xmms_remote_playlist (fromIntegral s) la (fromIntegral $ length l) (fromBool b) The next two question are still waiting for an answer though...;-)
3. c2hs v. hsc2hs? Which should I prefer? In c2hs I write {#pointer * GList#}. What is the equivalent in hsc2hs?
4. As I said, I solved my personal problem: I imported enough functions to create the client I needed. Releasing the library is just something I would like to do, to give something back to the Haskell community. So this is something useful if I can provide robust and well designed code. This is a name space question: what is the name of the exported module? Sound.XMMS, Sound.XmmsRemote? Is the some kind of convention I should be referring to?
I apologize for the noise. The auto-replay is for documentation (who knows, maybe others searching the list archives may find this info useful). Andrea
On Fri, Sep 21, 2007 at 11:44:38AM +0200, Andrea Rossato wrote:
I apologize for the noise. The auto-replay is for documentation (who knows, maybe others searching the list archives may find this info useful).
I tried to send a couple of messages to inform that the API I was writing a binding for has been (undocumentedly) deprecated. The messages didn't get through, but I nonetheless finished the job. I wanted to try out also the new Cabal-1.2 - that seems to me quite an impressive improvement over 1.1, btw. I planned also a feature-full client, instead there's just a nasty test/harc.hs file. The client will not be written I'm afraid...;-) My FFI experience will be used for other libraries though. Bibutils could be the first one... I'm not even sure if this message will get through. Actually this is the only mailing list I have some problem with... perhaps some filter may be considering my messages as spam. I'd like to have a copy of that filter installed on my system! Andrea
Andrea Rossato wrote:
I'm not even sure if this message will get through. Actually this is the only mailing list I have some problem with... perhaps some filter may be considering my messages as spam. I'd like to have a copy of that filter installed on my system!
I saw it. In total, four messages from you in this thread. Jules
On Mon, Sep 24, 2007 at 11:00:00AM +0100, Jules Bean wrote:
I saw it. In total, four messages from you in this thread.
I'm really sorry about that, but it was due to a problem and a misunderstanding with the administrator of my STMP server: at first it appeared the server was dropping my mail, instead the mail was just delayed due to a virus infection affecting one of the clients and overloading the server. I apologize. Andrea
On Fri, Sep 21, 2007 at 09:08:13AM +0200, Andrea Rossato wrote:
To make a short story long, I needed some client for the Audacious media player, something I could use to remote control it and, since I'm addicted to Haskell, instead of surfing the web to find a suitable client I surfed the web to find the API documentation. With the FFI, in a matter of half an hour I had the client with all the commands I needed.
[...]
So far so good, but, since everything was so easy, I thought: "Why not packaging a library (and the client) for Hackage? Maybe others may be willing to use it, maybe..."
Not only I found out that Audacious comes with a command line client named audtool, not even mentioned on their web site, but also that the API I was writing a binding for is deprecated. Forgetting to document such changes and publishing on your project's web site misleading information is harmful to others, as this example shows. I learned quite a lot today, and not only about FFI. Sorry for the noise. Andrea
participants (2)
-
Andrea Rossato -
Jules Bean