Recent blog entries for jluke

Reading the OsNews "article" on stetic I noticed someone posted that MonoDevelop had stalled and things like completion didn't work very well. Well neither is really true anymore.

Since 0.5.1 almost all know code-completion bugs have been fixed. If you have C# code that you think should be completing but isn't please file a bug with a small example. We also fixed many of our non-wishlist or feature request bugs. These will be in our 0.6 release.

I posted what I know to not work at the MonoDevelop list. A recap:

Things I know about:

  • C# 2 features will likely mess up completion
  • enter/double-click should complete
  • 0xdead type numbers are not parsed correctly (because of code that depends on an apparent .net 1.1 bug)

If no serious bugs come up with completion, I plan to start looking into adding C# 2 support to the parser which could involve going a few different directions.

Since 0.6 was branched, I have mostly finished the C# port of the docking widget and we have enabled that. This should make building simpler, and will allow us to be self-hosting.

10 Jan 2005 (updated 10 Jan 2005 at 21:11 UTC) »

I was strangely motivated to port some old MonoDevelop code to GtkAction and GtkUIManager today. Something still seems awkward about that API. I'm not sure it is much of an improvement, if any, from the old way of doing menus and toolbars and it seems to make some things slightly harder.

My main beefs are the callback-based adding of the widgets seem to force me to playing with PackStart/PackEnd tricks and that adding non-button ToolItems seems to take an extra step.

I think the second might be able to be "fixed" in a similar way as [Glade.Widget].

Regarding the recent revival of C# v. Java". I disagree that there are trivial language differences. To put it another way, cvs and svn are awfully similar from 50,000 feet also. I think if anyone discounts the advantages of svn over cvs would need their head examined. You might notice that the Java portion of the article lists several small stumbling blocks, this adds up when you are dealing with medium to large applications.

I do hope they actually start using Java instead of Python, however. I am confident that I will be able to run those programs via mono (IKVM kicks ass) at some point anyways. Will you ever be able to say the same for the other way?

I will agree that debating the language can take a definite back seat to more important reasons that I would favor an ECMA 334 and 335 based environment for adoption in GNOME.

  • ISO and ECMA standards
  • being used in applications today, and ever increasing
  • language-neutral
  • runtime (JIT) instead of static compilation
  • the great people who work on it

This is what the masses of internal IT departments and 3rd party developers want. As far as I can tell, these groups are adopting .NET (both C# and VB.NET) in great numbers, in particular through the colleges and universities. I don't think it would be wise to underestimate this effect if you intend to be statistically significant in desktop market or mind share.

Then again, if they don't see the language as very important why do they insist on making it harder for me as an independent person to do what I want with free software. I'm not going around telling them they can't use Java or Python. Hopefully, we can go back to moving forward instead of ignoring the issue entirely. It's extremely disconcerting that I even feel compelled to have to argue about this.

I'm probably wasting my time just writing this.

Hmm, it seems I have totally forgot to mention I got "Cross-Platform.NET Development" from Apress. It has a wealth of good advice for dealing with .NET, mono, and Portable.NET in a portable fashion. It covers very well the basic differences and probably more importantly the strategy and way to think about portability in the .NET world. Should be of particular use to Windows/.NET projects looking to migrate to more platforms and also Java people (who always seem very concerned with how portable something is) thinking about migrating and wondering if they will lose portability. If this sounds like you I would encourage you to check it out at All this and I have only had time to go half way through it.

I also recently did some more work on monocop, and I think it is ready to be released to the public.

26 Oct 2004 (updated 26 Oct 2004 at 04:13 UTC) »

I was always jealous of FxCop, the more automated tools the better I say. That was one of the things I wanted to get working on MonoDevelop a few months ago. You see, SharpDevelop wrote this AssemblyAnalyzer thing that works sort of in the same way. At the time, I hadn't quite finished the GUI portion of the AddIn so its not enabled in MonoDevelop.

However, I thought why not just slap a little command-line driver in front of it and then everyone can use it. So that is what I did. Temporarily called monocop (because AssemblyAnalyzer was too long, and I haven't bothered to think of a real name yet). It can output either plain text or xml. It should work with make, nant, others fairly well in an automatable way.

It works like this. You specify an assembly or assemblies to analyze, and it will warn you of possible design and naming problems. It also supports custom rules and looks to be fairly easy to add more. It only has about 87 rules right now.

Some example output: $ monocop -xml -output:results.xml hello.exe

<?xml version="1.0" encoding="utf-8"?> <Assembly Path="hello.exe"> <Resolution Certainty="95" Priority="Error"> <Item>/home/jluke/hello.exe</Item> <Description>Assemblies should be strong named</Description> <Details>Assemblies with a strong name can be placed in the GAC. Furthermore only strong named assemblies can be referenced by a strong named assembly (Your assembly cannot be used by a strong named assembly if you do not sign it).</Details> <Text>Sign the assembly hello.exe with a strong name.</Text> </Resolution> ....

Florida lost to Mississipi State, hopefully this will end the Ron Zook fiasco at Florida. When someone is demoted to Special Teams coach 10 years ago, how can you expect him to be a successful head coach. I know I didn't.

Things an application may need to do during installation:

  • Add a menu entry
  • Register mime-types it handles
  • configuration data
  • add documentation to monodoc/yelp/others
  • various others I missed (i18N)

For example, MonoDevelop needs to add a few mime types and occasionally syntax definition to gtksourceview to work fully. It works without installing (unpack it and type make run), but just enough is missing to potentially make things harder on you.

For some reason GNOME and others seem to increasing the dependence on $prefix and path specific files for the above things. You put a .desktop file here, an app.xml file there and run update-mime-database /some/path/, put a gconf schema here and do something else. Then if PATH, LD_LIBRARY_PATH, PKG_CONFIG_PATH aren't set right or you don't have root permission it doesn't quite work.

It really seems like there should be a better way. Here are some options:

I used to think we would be lucky if we could get to the point where autopackage was widely accepted in addition to rpm/deb. Now I am hoping for more. In particular, bundles seem rather appealing without me having had the chance to play with the Mac and discover its shortcomings. It certainly seems doable to me.

18 Oct 2004 (updated 18 Oct 2004 at 01:31 UTC) »

I wrote a C# implementation of the Recent Files spec today that seems to work ok with existing gnome programs. It is not very well tested, so be careful. For those interested it is here, even though it is not MonoDevelop specific. You want just the RecentFiles.cs file if you want to try it, please dont add comments to the bug unless it is about MonoDevelop. Specific things about RecentFiles.cs can come straight to me, including where it should eventually live if people find it useful.

My TV broke, but luckily things like tvtime and mythtv exist.

Seems to be good news on what me and Todd talked about the other day. Doesn't seem to mention the other bills though. Link is to slashdot because of those stupid newspaper registration things. Draft bill shot down You can probably find a better link through google though.

I watched the VP debate which was lackluster at best, still wish each party didn't conflict with themselves so much. I guess it is much easier to find faults, than fix them.

Laszlo sounds interesting without me really reading anything about it, sort of Flash MX-ish but now open source. If it only didn't require the hopelessly complicated J2EE. Looks like they plan to integrate with Eclipse (only speculation on my part because they chose the same license).

I messed with some more bite-sized mcs stuff today, small error fixes and stuff. Most of the test failures now seem to be where mcs reports a generic parser error, instead of a more specific one, which would be nice to fix but probably not a high priority. I think I am getting to the point that I understand (most) of the process now, but not enough to write a compiler yet.

4 Oct 2004 (updated 4 Oct 2004 at 06:20 UTC) »
Todd, I cant get to the first link, so I will assume it is to the Charles Rangel bill. The other bill is by Fritz Hollings (a RIAA/MPAA favorite). Since the two Senators who have written these bills are democrats, who are you advocating voting for? I was sure you were against Bush (who does not plan on reinstituting a draft). As far as I can tell neither bill has much of a chance of passing, but who knows.

I just spent 10 minutes writing a tool to generate a Makefile for a directory of .cs files, I have to wonder why I didn't do so a very long time ago.

Updated: I didn't assume anything and I am not naive. Just mentioning a related fact in case anyone believes the conspiracy theories going around that Bush and/or Republicans are secretly planning what Democrats are doing in plain sight. In any case, (most) politicians are members of a party in which they both have influence and are influenced by, so it is related to the presidential vote.

20 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!