Disclaimer: this is an automatic aggregator which pulls feeds and comments from many blogs of contributors that have contributed to the Mono project. The contents of these blog entries do not necessarily reflect Novell's position.


Branching and Merging
Keep trunk pristine,
Keep features flowing,
Release on demand.
Pre-Commit Testing
I see you knocking
but you can't come in.
ideally, CR mailing should happen BEFORE
actual commit/push of change-set to the
codebase -- upholds trunk/head/tip quality

Yesterday friends of mine have released Rejaw, a microblogging-like, Comet-based threaded web chat infrastructure. It is with a full set of API. The introduction can be read here. I was one of the alpha testing users.
There are already some articles introducing Rejaw:
Time for another snapshot.
Changes since previous development snapshot:
WARNING: THIS IS A DEVELOPMENT SNAPSHOT, NOT AN OFFICIAL RELEASE.
Development snapshots are intended for evaluating and keeping track of where the project
is going, not for production usage. The binaries have not been extensively tested
and are not strong named.
This version supports .NET 2.0 SP1 and Mono 2.0.
Binaries available here: ikvmbin-0.37.3141.zip
Join me at an IRC chat to talk about open source civic technology projects, on Saturday, August 16 at 4pm Eastern time! The agenda will be a mix between seeing what various civic technology projects are up to like GovTrack (my site, powered by Mono), OpenCongress, and any others run by people who show up, and getting new people involved in ongoing projects. “oGosh” is Open Government Open Source Hacking (wiki | Facebook), what I’m calling the loose community that binds these projects together.
The chat will be in the #transparency channel on Freenode. For more information on the meeting (and on how to get to the chat), see http://wiki.opengovdata.org/index.php/OGosh.
Suggestions for agenda topics are most welcome either to me directly or by revising the wiki page above. Hope to see you there.
I'm trying to plan some examples of using Mono in game development, so that we have time to get together some solid demos and samples for next year's GDC.
I'm primarily interested in showing how Mono fits into the existing games development ecosystem; we don't really have an XNA-like story for developing fully managed games in Mono at this point. The focus of the demos will therefore be:
Does anyone know of any complete games or cool demos for which source or C/C++ SDKs are available, so that Mono could be embedded as a scripting engine? (I'm already considering Source Engine and Quake 3).
Nice ideas for demos would be useful too, though obviously developing a serious game from scratch is out of the question...
Meanwhile in a repository not far away:
namespace metaboo
import Boo.Lang.Compiler
import Boo.Lang.Compiler.Ast
import Boo.OMeta
import Boo.OMeta.Parser
syntax Units:
atom = mass | super
mass = (integer >> value as Expression, "kg") ^ [| Mass($value, "kg") |]
syntax Ranges:
atom = integer_range | super
integer_range = (integer >> begin as Expression, DOT, DOT, integer >> end as Expression) ^ [| range($begin, $end) |]
def parse(code as string):
compiler = BooCompiler()
compiler.Parameters.References.Add(System.Reflection.Assembly.GetExecutingAssembly())
compiler.Parameters.Input.Add(IO.StringInput("code", code))
compiler.Parameters.Pipeline = CompilerPipeline()
compiler.Parameters.Pipeline.Add(BooParserStep())
return compiler.Run()
code = """
import metaboo.Units
import metaboo.Ranges
a = 3kg
print a
for i in 1..3:
print i
"""
result = parse(code)
assert 0 == len(result.Errors), result.Errors.ToString()
assert 1 == len(result.CompileUnit.Modules)
print result.CompileUnit.Modules[0].ToCodeString()
And the output is, of course:
import metaboo.Units import metaboo.Ranges a = Mass(3, 'kg') print a for i in range(1, 3): print i
mojoPortal 2.2.6.7 is now available on the download page.
This is primarily a bug fix release. There was a change in the search engine architecture in recent versions that did not work in Medium Trust hosting environments that has now been fixed.
It seems like a constant battle to avoid medium trust issues, so I started a small document here with some notes for developers about things to avoid that can cause problems under medium trust.
http://www.mojoportal.com/developing-for-medium-trust.aspx
Its not comprehensive so if anyone else has any suggestions for things to list on this page let me know. Sometimes its surprising when seemingly innocuous things don't work under medium trust. The problem we encountered was when we changed the search engine to use a queue for writing/updating the search index to ensure things happen in correct sequence. We were serializing our task object into a row in the database then our little task service would deserialize it and run it on a new thread in the background. As it turned out the SoapFormatter we were using to do the serialization throws a security exception under medium trust so you can't use it. I had to re-work the code to use the XmlSerializer.
Since a lot of people are hosted in medium trust I thought it important to get this fix out quickly.
This release also fixes a few other minor bugs as mentioned in the forums. I was surprised how many people are experimenting with our WebStore feature. Several bug fixes and improvements have been made in WebStore. Most of the bugs were only affecting the MS SQL version, whereas the store on this site is runningunder MySql
UPDATE: I've just uploaded a new set of files versioned 2-2-6-7-b because a significant bug was found today in the task framework. The changes I made to the way we serialize tasks to fix the medium trust issue introduced a bug that allowed multiple instances of the same task to run at the same time and this would use up additional threads from the threadpool, potentially causing hangs and performance problems. I also upgraded to FCKeditor 2.6.3.
at 8/4/2008 7:49:47 PM poupou said... Back from (gray and rainy) vacations. Tweaked some of Gendarme maintainability rules to lower false positives, use recent rocks (better readability) and, probably (not timed), a bit more performance (since memory requirements should be decreased). |
at 8/3/2008 12:32:58 PM poupou said... Simplified Gendarme's ConsiderUsingStopwatchRule using the new Instruction rocks. Also make the rule work with Ref and Out parameters and added full coverage by unit tests. |
at 7/28/2008 8:36:31 PM poupou said... Fixed a few buglets in Gendarme console runner to show specific error messages instead of depending on the global catch-all exception. |
MonoDevelop has a code navigation history. When you switch views, or jump around between definitions, it logs the history, and you can browse back and forth like a web browser. However, it has some major issues -- the history it generates is unintuitive and erratic. It seems like it should be a really useful feature, but in practice is frustrating to use, so I recently decided to give it an overhaul.
Unfortunately, navigation isn't an easy thing to get right in an IDE. It's easy to log too many points. For example, if navigation points are logged every time the user switches between all their open document tabs looking for something, it gets very cluttered.
The most important thing is how it fits into the users' code navigation, so I decided to blog in order to get some feedback on my current thoughts.
In my opinion the following actions should not trigger logging of navigation points:
Whereas the following points should be logged:
In summary, only direct interaction with the document -- and in particular, large jumps -- should be logged.
How will this fit into your coding flow?

<devtrackextensionconfiguration >
<dtlinkplusurl>
http://192.168.1.237/LinkPlusWebService/WSDTIncident.asmx
</dtlinkplusurl>
<user>terry-j</user>
<projectid>daveProject</projectid>
<systemid>daveSystem</systemid>
<branchprefix>issue</branchprefix>
<dtbuginfobrowserurl>
http://192.168.1.237/scripts/texcel/devtrack/buginfo.dll
</dtbuginfobrowserurl>
</devtrackextensionconfiguration>
<devtrackextensionconfiguration>
<dtlinkplusurl>
http://192.168.1.237/LinkPlusWebService/WSDTIncident.asmx
</dtlinkplusurl>
<user>terry-j</user>
<projectid>daveProject</projectid>
<systemid>daveSystem</systemid>
<branchprefix>issue</branchprefix>
<dtbuginfobrowserurl>
http://192.168.1.237/scripts/texcel/devtrack/buginfo.dll
</dtbuginfobrowserurl>
<workingmode>
TaskOnBranch
</workingmode>
</devtrackextensionconfiguration>
As the new task is created, it is on state “NEW” and assigned to a developer. “


This article mostly explains correctly why MySpace and Facebook are not accepted by Japanese.
Yes, when Facebook people visited Japan and explained their strategy to expand their market in Japan, by advertising "trusted by real name" network, we found it mostly funky. As the article explained, it is already achieved by mixi. And by that time, mixi is already regarded as dangerous "by exposing real name too widely".
One of the example accidents happened in 2005 August, at the comic market. Comic market place is usually flooded by terrible numbers of otaku people, and they used to be looking bad in general. One of a part time student workers at a hot dog stand wrote an entry in "mixi diary" like: "there was a lot of ugly otaku people there. eek!"
While it is pretty much straightforward, those otaku guys got hurt (at least some of them loudly claimed so), upset and started "profiling" who is that student. It was very easy in mixi, because mixi at that time encouraged to put real-life information with real name. No sooner she was then flooded by a lot of blaming voices, she disappeared from mixi.
OK, she was too careless, or ideally she should not write it (it is always easy to say something ideal). But she was not a geek and does not really understand how the network (mixi) is "open" to others (it is not really "open" by invitation filters, but as mixi grew up to have millions of users, it is of course not "trusted network" anymore). She didn't blame a specific person, and hadn't felt guilty until the company forced her to apologize. This kind of "careless" accidents has kept happening in mixi and it became a social problem.
Nowadays we have the same issue around "zenryaku-prof", where not a few children has faced troubles (for example sexual advances) by the face that the network is "open" to the web by default, while they think it isn't.
Though there must have been similar incidents outside Japan too (for example people fired by his or her blogs), the above (I believe) is the general understanding of the situation in Japan.
Another obvious point for Japanese, but would not for else, is that Japanese mobile web support is more important than anything, to get more people joined. Mixi is of course accessible from our cell phones. Even more funky example is "mobage-town", which used to limit access only from cell phones(!). (It is done by sending "contract ID", which is terrible BTW.) Mobage-town is one of the mega hit site in Japanese mobile web. It is mostly for games on the cell phones, but also has a huge SNS inside. It is also funky that the network used to be mostly filled by under-20 children. (Now children grew up to above 20, so the number is not obvious.)
Typically Japanese people spend a lot of boring time, between home and their offices or schools, on trains or buses. They can only do some limited "interesting" stuff. It used to be readings for example, and nowdays it is the mobile web.
Twitter was very successful unlike those failing players. Though I don't think the explanation on the TechCrunch article is right. Twitter had spread by "movatwitter", which is designed as the mobile web UI (and twitter is fully accessible by the API) as well as some additional values such as on-the-fly photo uploader (like Gyazickr for iPhone). It also filled our need (microblogging is a very good way to fill our boring time during our daily move). It lived very well in the mobile web land: no Javascript, no applets, no requirements for huge memory allocation.
When facebook is advertised with its API, what came to my mind was: "Is it even possible to make it for Japanese mobile web? nah"
While we, as a member of "open" world wide web, do not really like this mobile-only web (probably we should read Jonathan Zittrain), it is not a trivial demand that a cell phone is accessible to the mobile-only network. For example, iPhone 3G does not support it (iPhone BTW lacks a lot of features that typical Japanese people expect: for example, camera shake adjuster, it does not provide mobile TV capability, the mobile wallet etc.). It is often referred as "Galapagos network", which is intended as failing to expand their businesses abroad (one of the commentor on the TechCrunch entry mentions it. It is even funny that those iPhone enthusiasts try to claim that their web applications are "open" (as compared to Japanese mobile-only network).
BTW a commentor on the TechCrunch entry tries to object the fact written by the article by quoting google trends worldwide. But (including the graph on top of the article) it is a typical failure on measuring Japanese web access statistics: it does not reflect mobile web access. It is already explained (in Jaanese) very well. The simple fact is that it is becoming less ambient through Alexa, google trends or whatever similar.
We would have seen similar phenomena in everywhere else. In China it is QQ. Orkut quickly became SNS for Brazil. There is no universal best.
What other SNSes find business chances in non-mainland countries is some specific purpose. For example, MySpace in Japan is good for producing musicians with its rich UI (many of them would also use mixi as well though).



Always ingenious, John Stewart delivers one of the best reviews of what went on this week with McCain's campaign reaching for new lows with their attack adds aimed at painting a picture of an "elitist Obama"
Update: Priceless comment from reddit:
http://www.reddit.com/comments/6uis9/jon_stewart_mccains_celebrity_attack_add_is_the/c04wkkx
Our first preview for Mono 2.0 is out; It has been almost six months since we branched version 1.9 so this is a gigantic update to Mono.
Many of the features are listed on the release notes, but the release notes do not even begin to capture the enormous number of fixes, performance improvements, tuning and work that went into this release.
As usual, this is our "best release ever", but it is also the longest we have gone without doing interim releases, so it is possible that we might have regressed where our test suite lacks tests. We would love to get folks to test this, with their code, and to bug reports on any issues they find before our final 2.0 release.
See our Roadmap for more details on the release schedule and the upcoming post-2.0 releases.
Marc Christiensen has announced the release of our first preview for Mono 2.0. You can read our preliminary release notes for this release.
The preview release is available from our preview download directory. The source code for this release is available here.
Please report any bugs that you may find using our Bugs page, AND reply to this thread with the bug numbers so we can track them! http://www.mono-project.com/Bugs
You can see the bugs we're tracking for Mono 2.0 here: https://bugzilla.novell.com/buglist.cgi?bug_file_loc_type=allwordssubstr&bug_file_loc=http%3A%2F%2Fwww.go-mono.com%2Farchive%2F2.0%2F&order=bugs.bug_status%20
The earlier you file the bugs and reply to this message, the more likely your bugs will get fixed.
Special attention is given to regressions, so if you can tell us a version of Mono where the bug worked and you tag the summary of the bug with [Regression], then it is much more likely your bug will get fixed.
Please help the Mono team to make 2.0 the best ever.
Two days ago, I was sharing what I was foreseeing for C# 4 and .net 4, and the integration with the DLR.
Turns out that today, by reading this post, my eye was caught by the namespace I was thinking about: System.Scripting.
But this post is about the beta 4 of IronPython 2, that hasn’t been released yet. But heh, it’s easy to forget that latest IronPython code can be downloaded from CodePlex’s TFS.
And it indeed turns out, that in the latest revision, Microsoft.Scripting.Core namespace has been renamed to System.Scripting, and that the DLR AST has been merged into System.Linq.Expressions.
So yeah, I guess we can safely admit that C# 4 will have statements support inside expression trees.
And that .net 4 will contain very cute features for dynamically generating programs, without resorting to emitting plain IL, simply using the DLR, contained in a new assembly (or namespace, if they move some to parts to System.Core), System.Scripting.

<JiraExtensionConfiguration>
<HttpUrl>http://192.168.1.14:8080</HttpUrl>
<User>root</User>
<Password>root</Password>
<Projectkey>PR</Projectkey>
<Branchprefix>SCM</Branchprefix>
<workingmode>TaskOnChangeset</workingmode>
</JiraExtensionConfiguration>


I made a minor bugfix + minor feature release of Smux together with packages for Debian, Ubuntu and Windows. Big thanks for all the feedback I received from the users!
But at the same time I seek possible Smuxi contributors for things like artwork (logo, icons, theming, etc), translations, package maintainers for Linux distributions (OpenSUSE, Gentoo, ArchLinux, ForeSight, etc), patches, frontend and protocol developers are very welcomed and wanted ![]()
If you are interested in helping the project in any way, just join #smuxi on irc.oftc.net
Back to the topic, here are the release notes of Smuxi 0.6.1 and the downloads.
UPDATE: turns out that there’s some true in those previsions, a small follow up.
I’ve been thinking a bit about the discussion in this video, about the future of C#, and specifically about its next version. If nothing is said clearly and loudly, as they’re most probably waiting for the PDC, you can still get a glimpse of what C# 4 and .net 4 will get as new features.
I’m mostly interested in one aspect of those new features. It’s the possible integration of the DLR inside the framework, and in the C# language.
The DLR, as we used to have it in IronPython, has been split into two separate assemblies, Microsoft.Scripting, and Microsoft.Scripting.Core a few months ago.
Microsoft.Scripting.Core is probably the part that will make it into the framework. It’s the part that contains a generalist AST, a compiler for this AST, using both LCG and traditional SRE for the debug scenarios. It also comes with a fast dynamic call site implementation, and an hosting API. So are we going to have a new System.Scripting assembly?
An interesting change in the DLR, is the naming of the AST factory and nodes. I’ve spent the last months working on LINQ and the LINQ compiler in Mono, and comparing the LINQ expression AST with the DLR AST is an interesting thing to do.
The DLR AST is now basically the LINQ expression AST, with statements added. And it looks like the current DLR AST has been tinkered around what has been already shipped inside .net 3.5 in the namespace System.Linq.Expressions.
Here’s a small example. In System.Linq.Expressions, pretty much all node from the AST extends the type Expression. Each Expression has a NodeType property, of type ExpressionType.
And you can find the same thing now in the DLR, but with some stuff added.
public enum ExpressionType {
// some traditional expressions
Add,
AddChecked,
// ...
Call,
// ...
IfStatement,
SwitchStatement,
// ...
}
So for the DLR, a statement is an expression. It makes kind of sense for a dynamic language you’ll tell me, but it looks a bit weird to be implemented this way.
Anyway, C# 3 already has a way to create expression trees to support some basic meta programming features, I guess we can only wonder if C# 4 will extend the meta programming features to support not only expressions but also statements, using the DLR tree.
I have no idea how they’ll deal with the fact that the existing stuff is in System.Linq.Expressions. Are they going to obsolete the whole namespace, and redirect everything to a possible System.Scripting.Ast (sounds less likely)? Are they moving the DLR AST to System.Linq.Expressions (sounds more likely)? Who knows? Not me (I’ve never lost control).
Interesting speculations anyway :)
So for now, the only change I can foresee for C# 4, is that you’ll be able to get full code blocks instead of only expressions when asking for an Expression of T.
But here’s another interesting one we can have a glimpse here, is duck typing support based the DLR.
At the language level, it’s difficult to say if they’re going to rely
All in all, it looks like C# 4 will have some nifty stuff, let’s wait for the PDC.
I'm happy to announce the release of mojoPortal 2.2.6.6
This is a minor upgrade and bug fix release. There is a new option to show or hide any content instance based on whether the user is signed into the site or not. There is a new Traditional Chinese translation, thanks to Alex Ho!
There are a couple of bug fixes for the MS SQL version of WebStore and a few mnior improvements to a few admin pages in the WebStore.
There is a bug fix for a forums error that would occur if anonymous posting is enabled, though I still don't recommend allowing anonymous posting.
As usual, be sure and backup your site and database before upgrading, and post in the forums if you run into any troubles.
UPDATE: I've released a new set of files versioned 2-2-6-6-b, there was a packaging bug in the first set of files and it was missing some .htm files used by TinyMCE editor. I also fixed a few more bugs in the WebStore that were discovered today.



at 7/27/2008 10:02:44 PM poupou said... Fixed the Gendarme wizard to be more usable on high-DPI display (bnc 392556). Not perfect since some UI elements don't resize wrt to DPI - but I'm not sure it's an easy job to achieve better using straight SWF. |
at 7/26/2008 9:05:18 PM poupou said... Fixed two issues in Gendarme AvoidUncalledPrivateCodeRule. First one is about (unreported) unused properties (bnc #410000). The second is another case with generics. |
at 7/24/2008 8:51:07 PM poupou said... Two quick fixes for today (dull gray day with enough rain this evening to affect my net connectivity). First fixed a false positive for DoNotRoundIntegerRule and a bug that affected the Gendarme wizard when analyzing more than once an assembly with debugging symbols. |
at 7/23/2008 10:15:28 PM poupou said... Fixed generic and explicit interfaces support for Gendarme's BadRecursiveInvocationRule. Took some extra time to make it a bit faster and to reduce it's memory requirements. |
at 7/23/2008 12:17:42 PM poupou said... On vacations and... lots of rain ahead :( Slowly fixing issues being reported with the Gendarme preview release (many thanks to all reporters). I'll try to sneak in a few optimizations as well ;-) |

<JiraExtensionConfiguration>
<HttpUrl>http://192.168.1.14:8080</HttpUrl>
<User>root</User>
<Password>root</Password>
<Projectkey>PR</Projectkey>
<Branchprefix>SCM</Branchprefix>
<workingmode>TaskOnBranch</workingmode>
</JiraExtensionConfiguration>



State employees were routinely diverted from their jobs to provide political services and, in the case of Mr. Veon, to transport his motorcycles to South Dakota for his vacation and to provide dinners to members of Mr. Veon's informal basketball league.
Jon Udell interviews Joshua Tauberer on his service GovTrack.us that helps citizens track legislation and voting in the US.
A very unfortunate update was pushed to openSUSE 11.0 update servers. As of a week ago today, new Intel packages were pushed which changed the default AccelMethod from XAA -> EXA. This has the unfortunate side effect of making text 10% as performant, and most compositing operations ~80-90% as performant. The reason for the change is obscure crashes on i965 with XAA and Intel opting to no longer support XAA. I personally think this never should have been pushed in an update, but should have moved to a point release, and as such I looked into the reasoning behind this change. (NOTE: I'm on i915 so the crashes have absolutely no bearing to me). It turns out the only problem with XAA+i915 is unsupported XV, but this can be worked around by a patch from the Ubuntu folks. I've side ported that patch and provided patched RPMS here. I've also fixed a crash in the default xorg server packages using EXA that could crash your moonlight or firefox.
If you decide to use my packages I strongly suggest adding the following lines to your xorg.conf to make your desktop usable again:
Option "