Re: [Haskell-cafe] AI - machine learning
Hi Miro! I have no useful information for you. Few weeks ago I also checked for any AI (machine learning first of all) related packages exist and found nothing satisfactory except for some quite small packages implementing a single algorithm (like NN-back-propagation). So there is a lot to do :) If you are going to do something in this area please let me know, I'll be glad to collaborate! p.s. Now I'm taking Machine Learning course at Coursera.org and looking forward to apply this knowledge with Haskell. On Tue, May 15, 2012 at 3:02 AM, miro wrote: > Hi All, recently I started to take a look at haskell, especially at AI. I > can see some email addresses of interested people there but not so much of > other activity behind. Does it exist some mailing group especially for AI? > > Basically I'm interested in trying some machine learning algorithms. Start > with reinforcement learning and value-based), and go towards AGI (Artificial > General Intelligence). Does anybody know about some already existing haskell > approaches, or is there anybody working on this? > > Cheers, > m. > > ___ > 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] anyone else driven mad by trying to setup a gmp free version of haskell platform?
I had no problems building gmp-free GHC 7.4.1 for x86 Solaris (Openindiana to be precise) and Mac OS X. Not as a part of Haskell Platform, just compiler itself. To be precise, there was a little problem under Solaris: make failed complaining about loop in compilation. I removed this check from Makefile and it finished successfully. On Tue, May 8, 2012 at 7:07 PM, Anatoly Yakovenko wrote: > i would really like to be able to ship haskell based linux binaries, > but the gmp dependency makes it virtually impossible. so what version > of host os, host ghc, and haskell-platform sources are known to build > a working compiler? > > any reason why the dependency on gmp is static? are the interfaces > between versions actually different? or can we build a version fo the > compiler that loads the library via dlopen on demand? > > Thanks, > Anatoly > > ___ > 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] Is protocol-buffers package maintainer reachable?
I'm not sure about being a maintainer - I don't even know how those packages work and have no experience in preparing package for hackage. But fixes are really trivial - maybe I'll just upload patched versions if it is possible? Is it possible to contact StackOverflow user? On Mon, Apr 23, 2012 at 7:26 PM, Vo Minh Thu wrote: > For what it's worth, I think he is active on stackoverflow. > > Thu > > Le 23 avril 2012 17:13, Johan Tibell a écrit : >> On Mon, Apr 23, 2012 at 7:53 AM, Max Rabkin wrote: >>> On Mon, Apr 23, 2012 at 15:01, Paul Graphov wrote: >>>> And what should I do if he is >>>> unreachable? >>> >>> My feeling is that if you are willing to take it on, you should ask >>> this list if anybody objects to your taking over the maintainership, >>> and if they do not, take it over (on Hackage, this just means >>> uploading a new version of the package). >> >> If Chris is indeed out of the loop we should find a new maintainer. >> Mark and I are also interested in the future of protocol buffers in >> Haskell. >> >> -- Johan >> >> ___ >> 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Is protocol-buffers package maintainer reachable?
Hello Cafe! I am using protocol-buffers and hprotoc packages but they fail to compile with recent GHC due to trivial errors. Hackage names Christopher Edward Kuklewicz as their maintainer. I've sent him patches more than a month ago but neiter they were applied nor I got any response. It's quite inconvenient to keep patched versions all the time. Does anybody know if he is still interested in maintaining those packages? Is it possible to contact him? And what should I do if he is unreachable? Thanks! Links: http://hackage.haskell.org/package/protocol-buffers http://hackage.haskell.org/package/hprotoc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question about concurrency, threads and GC
Hi! Thanks to all who responded! I got a lot of information to read and think about. For now I decided to use stm-channelize as the simplest approach which seem to be enough. On Mon, Mar 5, 2012 at 9:50 PM, Alexander V Vershilov wrote: > Hello. > > I've also written simple chat server based on conduits and stm channels > > https://github.com/qnikst/chat-server/blob/master/src/Main.hs > > it has quite similar aproach and maybe this solution can be used together > to have better results. > > -- > Alexander Vershilov > > Sat, Mar 03, 2012 at 02:05:17AM -0500, Joey Adams wrote >> On Fri, Mar 2, 2012 at 7:34 PM, Joey Adams >> wrote: >> > I'll try to put together a simple chat server example, like the one I >> > wrote for stm-channelize. >> >> Here it is: >> >> https://github.com/joeyadams/haskell-chat-server-example >> >> See, in particular, the serveLoop function. When a message is >> received from the client, it is written to the send channel of every >> other client. When a message is written on the client's own send >> channel, it is transmitted to the client. The primary thread for the >> client waits until one of the worker threads signals completion, then >> kills both of the worker threads. >> >> I hope this example gives you some ideas. >> >> -Joey > > ___ > 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] Question about concurrency, threads and GC
Hello Cafe! I am trying to implement networked application in Haskell. It should accept many client connections and support bidirectional conversation, that is not just loop with Request -> Response function but also sending notifications to clients etc. NB: I came from C++ background and used to explicit asynchonous operations and pools of OS threads. (Boost.Asio + Boost.Thread) There seem to be lots of goodies around (green threads, STM). The problem is that I cannot figure out how to design such applications. First of all now I have to start some threads for each client. Client state and behaviour may change depending on data that comes from it or other clients. So it seems that I have to start at least three threads: one that reads data from socket, one that sends queued messages to the socket and one that represents clients main behaviour loop. The last one will supposedly read from some STM sources, one of them being TChan/TMVar filled by thread that reads socket. Here I get stuck: how to manage that threads? I tried to search STM examples at hackage and the most interesting packages were: 1) combinatorrent - quite complex application, but it seem to be highly Erlang-inspired, so I am not sure that it is the simplest way of doing thing. 2) network-connection package - it is a library that wraps socket and uses STM internally but exposes almost the same interface with blocking operations. Thread management is quite explicit there. But this package is marked obsolete. I wondered if one can rely upon garbage collector to reap dead threads when using STM? Or is it too error prone (accidental references to STM object that prevent it from being collected) and unpredictable? I have read this post: http://blog.ezyang.com/2011/07/blockedindefinitelyonmvar/ It shows that relying upon handling BlockedIndefinitelyOn* exceptions is a bad idea but is it OK just to rely upon that blocked forever thread will die and not to kill it explicitly? And also if it is really reliable, what are exact rules when some object goes out of scope and becomes collectable? For example in blog post mentioned above in "main1" example "lock" variable is accessible until the end of do-block, i.e. if I add "takeMVar lock" line to its end, it will compile. But it is not used actually. Is it guaranteed that explicit performGC will reap it? Possibly the best answer would be just pointing me to some recent examples of concurrent network applications. Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
