Announce: xmobar-0.1 released!
Hi!
Sorry if I didn't keep the promise of refactoring Tabbed.hs, but I've
been quite busy. I'll do it, though.
Moreover, I wrote this stuff, a real status bar, inspired by the Ion3
one. I sent a mail about it a couple of days ago, as a challenge to
Robert to rewrite dzen2 in Haskell... No answer, so there I am.
Well, XMobar, I called it this way, is not going, I hope, to compete
with dzen, since it is designed to work only with a configuration
file (see xmobar.config-example). No piping and stuff. Moreover, it is
just a status bar (should work with any WM).
Screenshots:
with xmobar.config-sample
http://gorgias.mine.nu/xmobar/xmobar-config-sample.jpg
another one (text align to left):
http://gorgias.mine.nu/xmobar/xmobar-2.jpg
I forgot to take the default screenshot (when you run xmobar without
config). Well, just find out. Grabit and run: xmobar
You can grab the source of this release here:
http://gorgias.mine.nu/xmobar/xmobar-0.1.tar.gz
Darcs repo here:
http://gorgias.mine.nu/repos/xmobar/
Documentation is absent. Anyway, there is a template to set the output:
<command> will cause xmobar to run the command and display the output.
* Andrea Rossato (mailing_list@istitutocolli.org) wrote:
Moreover, I wrote this stuff, a real status bar, inspired by the Ion3 one. I sent a mail about it a couple of days ago, as a challenge to Robert to rewrite dzen2 in Haskell... No answer, so there I am.
xmobar looks really nice though it seems to leak memory. Initially it started with 1936 KB resident memory after 1:06:34,30 it takes 5344 KB. I think you should investigate into this.. Regarding the dzen rewrite, unfortunatelly I'm not that fluent in haskell for this task. Maybe I'll give it a shot after the exams and some more haskell practice though :). Bye, Rob.
On Fri, Jun 22, 2007 at 06:19:19PM +0200, Robert Manea wrote:
xmobar looks really nice though it seems to leak memory. Initially it started with 1936 KB resident memory after 1:06:34,30 it takes 5344 KB. I think you should investigate into this..
I've already investigated that: it is due to runCom. I've discussed that with other haskellers here: http://www.haskell.org/pipermail/haskell-cafe/2007-June/027234.html I did extensive profiling: after reaching a given level, memory usage seems to stop increasing. But I need some feed back to understand if there are other problems I'm not aware of. This is the reason for the 0.1 release, after all. Please let me know your opinion.
Regarding the dzen rewrite, unfortunatelly I'm not that fluent in haskell for this task. Maybe I'll give it a shot after the exams and some more haskell practice though :).
I was just kidding... ;-) Thanks for your feed back. Ciao Andrea
mailing_list:
On Fri, Jun 22, 2007 at 06:19:19PM +0200, Robert Manea wrote:
xmobar looks really nice though it seems to leak memory. Initially it started with 1936 KB resident memory after 1:06:34,30 it takes 5344 KB. I think you should investigate into this..
I've already investigated that: it is due to runCom.
I've discussed that with other haskellers here: http://www.haskell.org/pipermail/haskell-cafe/2007-June/027234.html
I did extensive profiling: after reaching a given level, memory usage seems to stop increasing. But I need some feed back to understand if
That's interesting. Try setting a low bound on the heap size.
there are other problems I'm not aware of. This is the reason for the 0.1 release, after all.
Please let me know your opinion.
Regarding the dzen rewrite, unfortunatelly I'm not that fluent in haskell for this task. Maybe I'll give it a shot after the exams and some more haskell practice though :).
I was just kidding... ;-)
Thanks for your feed back.
Ciao Andrea _______________________________________________ Xmonad mailing list Xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
On Sat, Jun 23, 2007 at 04:13:02PM +1000, Donald Bruce Stewart wrote:
I did extensive profiling: after reaching a given level, memory usage seems to stop increasing. But I need some feed back to understand if
That's interesting. Try setting a low bound on the heap size.
I'm making some experiment with that, with varied result: under 1 Mega the program exited because of the limit, now I've been running with +RTS -M1M -RTS and it keeps on running with increasing memory usage (now 8124 (vir) 47808 (res) 2244 (shr)). I've also tried a very long profiling (I run it many hours till it ended up with 9 Mega or resident memory, according to top), and these are the reports: http://gorgias.mine.nu/xmobar/xmo.hp http://gorgias.mine.nu/xmobar/xmo.prof http://gorgias.mine.nu/xmobar/xmo.ps This last one makes me wonder: it seems to me that the report is wrong. According to heap profiling there are no memory leaks, am I right? Am I reading the report correctly? I remember I've read something about heap profiling not showing memory leaks related with FFI, there were a discussion in the haskell-cafe mailing list. I'll keep investigating. If you guys have some clue that would be nice. BTW, gorgias is up and running almost (I was able to get a backup machine, an old, very old one). You cen get the darcs repository here: http://gorgias.mine.nu/repos/xmobar/ The server may be down during the next few days (it must be changed) so in case of problems please try coming back later. Ciao Andrea
On Sat, Jun 23, 2007 at 04:22:17PM +0200, Andrea Rossato wrote:
On Sat, Jun 23, 2007 at 04:13:02PM +1000, Donald Bruce Stewart wrote:
I did extensive profiling: after reaching a given level, memory usage seems to stop increasing. But I need some feed back to understand if
That's interesting. Try setting a low bound on the heap size.
I'm making some experiment with that, with varied result: under 1 Mega the program exited because of the limit, now I've been running with +RTS -M1M -RTS and it keeps on running with increasing memory usage (now 8124 (vir) 47808 (res) 2244 (shr)).
I've also tried a very long profiling (I run it many hours till it ended up with 9 Mega or resident memory, according to top), and these are the reports:
http://gorgias.mine.nu/xmobar/xmo.hp http://gorgias.mine.nu/xmobar/xmo.prof http://gorgias.mine.nu/xmobar/xmo.ps
This last one makes me wonder: it seems to me that the report is wrong. According to heap profiling there are no memory leaks, am I right? Am I reading the report correctly?
According to heap profiling, yes, there are no heap leaks. You might still be leaking some other kind of memory...
I remember I've read something about heap profiling not showing memory leaks related with FFI, there were a discussion in the haskell-cafe mailing list. I'll keep investigating.
Stefan
On Sat, Jun 23, 2007 at 08:09:23AM -0700, Stefan O'Rear wrote:
wrong. According to heap profiling there are no memory leaks, am I right? Am I reading the report correctly?
According to heap profiling, yes, there are no heap leaks. You might still be leaking some other kind of memory...
I love the cryptic way you put it...;-) I have the feeling that what's wrong, in my code, is somehow related to the way I'm using the Graphic Context. Or, perhaps, the FontStruct. There's something wrong in my understanding of Xlib. I've been running it with +RTS -M1M -RTS for hours, now. Top reports about 8 Mega of resident memory... I'm going to keep on studying till I'll find a solution. All the best. Andrea
On Fri, Jun 22, 2007 at 06:19:19PM +0200, Robert Manea wrote:
xmobar looks really nice though it seems to leak memory. Initially it started with 1936 KB resident memory after 1:06:34,30 it takes 5344 KB. I think you should investigate into this..
anyway you are totally right, there is a memory leak. I hate C because all the malloc, and free, and so on: once I wrote a patch to make the history size of the Ion3 prompt configurable with a Lua function at run time. Writing the patch was so quick, and the power of C memory management makes you feel great... But then I spent 2 days in trying to debug a stupid bug related to reading out of the range of an array. Well, that was nothing compared to the difficulties I have in debugging garbage collection and memory leak related issues in Haskell. The fact that you do not need to manually allocate memory is great. But if you do not know how the "guy", who is supposed to carry out the job for you, behaves, well, you are in big big troubles. ciao andrea
participants (4)
-
Andrea Rossato -
dons＠cse.unsw.edu.au -
Robert Manea -
Stefan O'Rear