Older blog entries for jluke (starting at number 13)

Like many others I have been playing with IronPython since its release. Not having really used python before I find it interesting, at least, but it doesn't look like I will stop using C# as my preferred language anytime soon. I am just very happy that people who have wanted a really dynamic language on mono/.NET now have one. It is one less excuse in the world for not using mono.

Last week I got interested in watching the convention, which is the first time I had really paid attention to politics in quite a while. I am looking forward to the republican one so I can choose between two parties that I see no advantage in supporting one over the other.

For the people that are interested, the next Gtk# release should have a significant amount more of documentation. Not as good as it needs to be, but much better. It would be wonderful if more people spent just a _little_ bit of time to document something. If there has been something preventing or stopping you from doing this, contact me and let me know john.luke@gmail.com or mono-docs-list if you prefer that.

I fear the takeover of usability (over?)designers. That is all.

13 Jul 2004 (updated 14 Jul 2004 at 06:02 UTC) »

Today has seen an unsuspected turn of events. What started out as another persons licensing question, looks like it will lead to me no longer working on MonoDevelop. That is, if the original authors believe that all AddIns are a derivative work and must be GPL'ed, I wish to respect that opinion and not try to argue about it. Even though I have no plans to write one (AddIn in another license), nor know of any that exist, I simply cannot support that position. It's probably my fault for not realizing this situation myself, and I will take all the credit for that.

Currently, I feel I might walk away from it in either case. (In case it sounds like I am mad at them, I am not, they are still good people.) I am a firm believer in co-existance of software and that platforms should allow for this. Oh well, it was fun, and hopefully others will come to work on it in my absence. It was becoming time for me to move on anyways, back to Gtk# docs!

13 Jul 2004 (updated 13 Jul 2004 at 01:10 UTC) »

Lots of interesting things a'happenin, but nothing worth mentioning on its own.

  • Bug fixing in MonoDevelop.
  • Doc'ing Gtk# and filing/fixing bugs.
  • Noticed some things in MonoDoc that need fixing.
  • Started to look for a job
  • I've been playing with gstreamer Gtk# bindings thanks to Owen Fraser-Green who delved into the gstreamer source and made the necessary changes to parse it, and fixed everything up for it to be moved to its own module in cvs: gst-sharp. I have now updated platano a simple video player, which was originally writted by Alp Toker to work with it. I need to fix a few small bugs but then it should be working as a good example. Overall most things seem to be working well in the binding.

    In case people aren't aware of it Ben wrote a neat little tool called monop that uses reflection to list information about a given type. Very handy when you need quick little bits of info and don't have monodoc runnning. It's my new favorite tool.

    It works like this:

    monop System.String

    The GNOME book is out, and it includes a bunch of samples under the GPL. It might be a good source of information for someone to convert them to C# and put in monodoc. There is a lot of other fun things to do with regards to documentation, so join #mono or post to mono-docs-list and start writing. Most of this can be done right from the comfort of MonoDoc.

    One thing that would be great in my opinion is to take small examples, like from the ported GtkDemo, the above book, applications and find places in the API docs that they would fit. It took me less than 30 minutes to do this yesterday for Gtk.TreeSelection, Gtk.DrawingArea, and Pango.Layout. Also, if you find existing examples that no longer compile please let us know (or fix them in monodoc and contribute them).

    I think Erik and others have the monkeyguide under control, but I am sure they would like help in some areas if people are interested as well.

    Nemerle has a new release, and Pawel Rosanski has been doing a terrific job making it work well with MonoDevelop. Thanks Pawel.

    I am pleased to hear of the meeting between some of the GNOME and mozilla guys, although I am not entirely thrilled about anything in the transcript except for the very bottom entry by Marco. He also outlined not long ago ways to improve using Mozilla in GNOME and has been forced to take this on himself it appears. I fully agree with him. Also it appears the GRE has once again been pushed back, to me this is the single most important step in increasing GNOME/Mozilla cooperation. In the end I only hope good things come out of this, which I think they will. My personal advice to mozilla is to focus on the GRE, and write native platform GUIs on top of that, but I don't expect anyone to listen to me.

    Although I use Firefox as my browser, I do not think it could be the included browser for distros unless it integrates with native widgets and dialogs better (whether this is a gtk+ or mozilla deficiency I do not know).

    In smaller news, the ILAsmBinding should be working with MonoDevelop in svn. Try it out and let me know if something doesn't work, and file bug reports in bugzilla (not your blog). :)

    I just finished reading this, which makes me wonder if Red Hat will now remove the GIMP and other programs that use JPEG, like they did for mp3, and why they apparently won't package mono. Things like this really make me angry, especially when they waited so long to make these claims. Apparently their internal discussion on Java/mono/others was moved onto a public mailing list, but I haven't been able to find any archive of it yet.

    MonoDevelop can now run java using ikvm instead of a java runtime. I need to allow choosing between javac, and gcj for compiling and a couple other preferences still but here is a screenshot You will need to have setup yourself:

    • a wrapper script in your path called ikvm that executes 'mono ikvm.exe args', similar to the mcs one
    • run 'mono netexp.exe your.dll' for all the dlls you want to use and put them in /usr/lib or edit the locations to them in your project options classpath
    • something else that I likely forgot

    Hopefully sometime soon ikvm will be included in red carpet so the manual stuff won't be required, and we can have some way of checking if it's installed and what version it is. I have to say I haven't used Java in a long time, and this little monodevelop + ikvm + mono + Gtk# project was the most fun I've ever had with Java. I wouldn't want to use it instead of Gtk# and C#, however.

    I have been reading the Coco/R docs and looking at SharpRefactory tinkering with the idea of porting it to work for Java. I'm not too sure I will ever do this, but it looks interesting at least. I will have to learn all of this grammar terminology before I understand what is really going on.

    4 Apr 2004 (updated 4 Apr 2004 at 21:56 UTC) »

    So i wasted yesterday trying to debug a binding that should be working but just doesn't. The C# code works, the C code works. One function just always returns false. I wish I knew how to use gdb better. Same thing with the vte-binding, it breaks in the managed/unmanaged boundary and I haven't yet figured out how to debug that very well.

    Perl is so unreadable if you did not write it. Even when written by very smart people.

    Source Editors

    It's a tough choice to make, but we are fortunate to have 2 rather good choices with support from both groups (SD and gtksourceview). One thing is that the SourceEditor implementation is different enough from the SD TextEditor that adding the language bindings from SharpDevelop you have to port it instead of just copying it over and it works. Not terribly difficult but an area that being compatible would be nice.

    update I fixed vte with two lines of metadata, which makes me feel really stupid. cvs up and try out the sample in gtk-sharp/samples/vte-test.exe

    4 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!