Claws Mail Ubuntu indicators notification plugin

by grendel 7. July 2011 12:21

I've been using the excellent Claws Mail email agent for years and after recently switching my OS to Ubuntu 11.04 (Natty), I discovered that none of the notification plug-ins Ubuntu ships implements support for the native indicators and the Messaging menu. So, having a little time on my hands, I developed a simple plug-in which implements just that and only that. You can find it here.

It puts indicators and a menu with some actions right in the Messaging menu and blends in nicely with other Ubuntu notifications.

Note: as I was pointed out after releasing the code on freshmeat, the notification plug-in which comes with Claws Mail does have support for indicators. However, the support is disabled in the official Ubuntu packages for some reason which is why I never knew about it. Despite that, I am going to keep developing the plug-in for my own use - if anyone finds it useful, great, if not, I'll be a proud only user of it :). I like the simplicity and small size of my plug-in and, besides, it was fun developing it and learning new things so I'll just keep enjoying that.

Orchard begins to work under Mono

by grendel 3. February 2011 10:32
After 4 days of work, the first Orchard screen rendered:

This is just a start as it's only the setup screen, but it's a major step forward and a sign that Mono supports MVC3/Razor well enough to run a pretty complex application Orchard is. Make no mistake - the simplicity of the screen is misleading. Behind the scenes we have a whole lot of dynamic objects created using DLR, lots of components built, assemblies loaded, files parsed and code generated. Note also that NO changes were needed to Orchard code in order to make this happen.

I have modifed the setup screen code a bit to show that it indeed runs on Mono :)

The next step is set up SQL and see what breaks next :). It's a good start though!

To test this yourself you will need:

  • Mono from the master branch (all the necessary fixes are ported to the mono-2-10 as well but I haven't really tested it with 2.10 so I can't certify it works there)
  • MonoDevelop from its master branch (xbuild will currently not work).
After the build is done make sure to remove the Orchard.Web/bin/Microsoft.Web.Infrastructure.dll assembly as Mono provides its own version. And remember that Orchard is a .NET 4.0 application - you need to use the following command to run it:
MONO_IOMAP=all xsp4

Tags:

Mono | MVC | MVC3 | Orchard | Razor

Mono and ASP.NET MVC v3

by grendel 17. January 2011 09:23
Microsoft has recently released the next version of the ASP.NET MVC stack and many of you have been asking whether Mono supports it. The answer is complicated since this MVC release is much bigger and includes more components than the previous ones. Unfortunately not all of those components have been released as open source software (although they come with the right to redistribute the assemblies) and therefore MVC integration with the Mono sources and build system makes no point at the moment. The highlight of the release is the new Razor template engine which is among the source-less components, so the Mono build of MVC would have to be done without support for Razor, which would probably take away all the fun from using it for many people. Having said that, I have managed to get to compile with current Mono from master after stubbing out several assemblies (read below for the list) and disabling Razor. The code lives in my local git branch and is not going to hit the Mono repository just yet. The reason for this is that we have decided to first make sure that MVC binaries from Microsoft work fine with Mono and only then set out to implement the non-open source assemblies it relies upon. I committed several changes (commits: c372ab7, 0582257, 1d5e3d4, d18d086, aa2ad86, cd511ea and 3e62637) which made it possible to run an MVC v3 application generated from the default VisualStudio template using several assemblies distributed by Microsoft. To get the application working you need to put in your bin/ folder the following dlls:
  • System.Web.Mvc.dll
  • System.Web.Razor.dll
  • System.Web.WebPages.Deployment.dll
  • System.Web.WebPages.dll
  • System.Web.WebPages.Razor.dll
All of the above assemblies, with the exception of the Mvc one, come without sources and will be at some point implemented in Mono. Also note that the Microsoft.Web.Infrastructure assembly added with the above commits is mostly a collection of stubs so you might (and will) come across the NotImplementedException from time to time. So, with the above changes you should be able to give MVC v3 on Mono a spin - if you come across any issues with running your app on Mono, do file a bug report attaching your application (or, if it is too big/private/secret/etc, a small test case which triggers the issue) to help us iron out all the rough edges.

Update: Gonzalo got Razor working under Mono - please report all the issues you have with your Razor applications under Mono! Congrats, Gonzalo :)

Tags: ,

Mono | ASP.NET | MVC | MVC3

How sgen rocks

by grendel 24. August 2010 18:29

As most of you probably know, Mark Probst (schani) has been hard at work in the past year on implementing a new, generational, garbage collector for Mono (called sgen). The hopes were high for this work as the currently default garbage collector in Mono, boehm, is not really up to the task and causes major slowdowns under certain workloads. The hopes were high, but Mark managed to meet and exceed them :) The test page can be found here. Below are results of a simple test, to run several thousands of requests against a small ASP.NET page, served by XSP. The first run is a "warm-up" one - that is, at the very first request gmcs is invoked in order to compile the .aspx into an assembly. The second request is "pure", without the compilation toll. The test consisted of running the following command line on the client machine (2.2GHz dual core):

ab2 -n 50000 -c 20 -k http://192.168.1.2/hi.aspx
The server was a quad 2.4GHz Xeon machine with hyper-threading on (giving 4 real and 4 "virtual" cores). The tests were conducted with Mono from the master branch. Both machines were running 64-bit Linux (OpenSuSE 11.3). The first set of results is for the boehm gc:
# ab2 -n 50000 -c 20 -k http://192.168.1.2:8080/hi.aspx
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.1.2 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests


Server Software:        Mono.WebServer.XSP/2.7.0.0
Server Hostname:        192.168.1.2
Server Port:            8080

Document Path:          /hi.aspx
Document Length:        699 bytes

Concurrency Level:      20
Time taken for tests:   34.739 seconds
Complete requests:      50000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    49520
Total transferred:      51478420 bytes
HTML transferred:       34950000 bytes
Requests per second:    1439.30 [#/sec] (mean)
Time per request:       13.896 [ms] (mean)
Time per request:       0.695 [ms] (mean, across all concurrent requests)
Transfer rate:          1447.13 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   1.0      0      17
Processing:     4   14  26.1     10    1220
Waiting:        4   14  26.1     10    1220
Total:          4   14  26.2     10    1224

Percentage of the requests served within a certain time (ms)
  50%     10
  66%     11
  75%     12
  80%     13
  90%     22
  95%     38
  98%     52
  99%     57
 100%   1224 (longest request)
# ab2 -n 50000 -c 20 -k http://192.168.1.2:8080/hi.aspx
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.1.2 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests


Server Software:        Mono.WebServer.XSP/2.7.0.0
Server Hostname:        192.168.1.2
Server Port:            8080

Document Path:          /hi.aspx
Document Length:        699 bytes

Concurrency Level:      20
Time taken for tests:   55.495 seconds
Complete requests:      50000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    49518
Total transferred:      51478320 bytes
HTML transferred:       34950000 bytes
Requests per second:    900.98 [#/sec] (mean)
Time per request:       22.198 [ms] (mean)
Time per request:       1.110 [ms] (mean, across all concurrent requests)
Transfer rate:          905.88 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0  13.7      0    3053
Processing:     2   22  38.9     11    1535
Waiting:        2   22  38.7     11    1535
Total:          2   22  41.3     11    3071

Percentage of the requests served within a certain time (ms)
  50%     11
  66%     12
  75%     12
  80%     13
  90%     65
  95%     92
  98%    115
  99%    241
 100%   3071 (longest request)
The second set is for the sgen gc:
# ab2 -n 50000 -c 20 -k http://192.168.1.2:8080/hi.aspx
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.1.2 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests


Server Software:        Mono.WebServer.XSP/2.7.0.0
Server Hostname:        192.168.1.2
Server Port:            8080

Document Path:          /hi.aspx
Document Length:        699 bytes

Concurrency Level:      20
Time taken for tests:   28.736 seconds
Complete requests:      50000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    49520
Total transferred:      51478420 bytes
HTML transferred:       34950000 bytes
Requests per second:    1739.99 [#/sec] (mean)
Time per request:       11.494 [ms] (mean)
Time per request:       0.575 [ms] (mean, across all concurrent requests)
Transfer rate:          1749.45 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   1.0      0      29
Processing:     4   11  27.6     10    1383
Waiting:        4   11  27.6     10    1383
Total:          4   11  27.8     10    1387

Percentage of the requests served within a certain time (ms)
  50%     10
  66%     11
  75%     12
  80%     12
  90%     14
  95%     15
  98%     18
  99%     23
 100%   1387 (longest request)
# ab2 -n 50000 -c 20 -k http://192.168.1.2:8080/hi.aspx
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.1.2 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests


Server Software:        Mono.WebServer.XSP/2.7.0.0
Server Hostname:        192.168.1.2
Server Port:            8080

Document Path:          /hi.aspx
Document Length:        699 bytes

Concurrency Level:      20
Time taken for tests:   33.681 seconds
Complete requests:      50000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    49512
Total transferred:      51478045 bytes
HTML transferred:       34950000 bytes
Requests per second:    1484.52 [#/sec] (mean)
Time per request:       13.472 [ms] (mean)
Time per request:       0.674 [ms] (mean, across all concurrent requests)
Transfer rate:          1492.58 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0  23.6      0    3089
Processing:     2   13  24.2     10     674
Waiting:        2   13  24.2     10     674
Total:          2   13  33.8     10    3099

Percentage of the requests served within a certain time (ms)
  50%     10
  66%     11
  75%     12
  80%     13
  90%     14
  95%     16
  98%     21
  99%    172
 100%   3099 (longest request)
The points of interest are:
  • Requests per second. Both tests show that the second run is slower, which is to be expected since there are more objects to be collected. Boehm has much more work here since it has to perform a lot of big collections, while sgen wins by having two kinds of collections - major and minor. Sgen wins hands down here.
  • Percentage of requests run in given time. Boehm shows a pretty big difference in times here, while sgen is more uniform and, once again, faster.
  • Throughput. And for the third time, boehm loses here considerably - sgen by taking advantage of its minor collection feature spends less time freeing memory and therefore gives better transfer.
  • Memory usage. This is not shown above, but sgen left xsp with more memory at the end of the test run than boehm (~900mb vs ~800mb), but this is expected to change as sgen development progresses.
One thing to note is that you need to run mono with the -O=-aot option when testing sgen (at least on x86-64) since AOT somehow causes it to crash XSP. So, two conclusions here. Sgen is going to make Mono much, much faster and, as Gonzalo> put it (hitting the bull's eye): <gonzalo> YOU ROCK :D (in response to Schani's question if Gonzalo was kidding regarding the performance improvement)

Tags:

Mono

*nix Stack Exchange

by grendel 6. August 2010 10:23
One of the strengths of the open source community is sharing of knowledge, passion, experience and (in most cases at least) selfless need for other people to use the fruits of your work for their benefit. One of the weaknesses, however, is that the open source community tends to get fragmented, create factions of supporters of this or that idea and shunning supporters of a different idea. I think that the idea of the Unix/Linux Stack Exchange is a great way to remove the gaps between parts of the community, so - go and commit to it!

RecentComments

Comment RSS