BlogEngine.NET 1.5.1.1 r27024 on Mono Patch

by Ivan Hamilton 4/23/2009 4:25:00 PM

I've been seeing an increasing amount of comment spam lately. BlogEngine.NET isn't a large target, but the spammers are starting to find it and I'm getting sick of manually culling the comments.

Before investing more time into my current install, I figured it was worth looking at an upgrade. This isn't something I'll do lightly. In the past, the BlogEngine.NET project hasn't been very responsive to my bug reports & fixes. It has taken about 6 weeks from a bug report (with an attached fix) to being committed to the repository. 6 weeks is a little beyond my attention span.

There's been a fair bit of updating since the 1.3.1.30 release that I'm currently running and the idea of switching to 1.5.1.1 is a little scary. My past experiences with Mono and BE haven't been smooth, and hunting down bugs in both Mono & BE again just to get a minor upgrade, is far too much effort. But since my previous logged issues had been fixed, I felt it was time to give BE another upgrade shot.

With my notes still lying around from last time, I decided to grab the latest BE source (r27024) and see how it went. To my surprise it not just compiled (previous versions would not even compile)... but it also ran.

I headed off to download Justin Etheredge's Akismet Extension for BlogEngine.NET. I wasn't too familiar with Akismet, but it requires you to have a WordPress API key. I headed off to WordPress to create an account and get an API key (just a blog, just an account with an API key).

I wasn't too familar with BlogEngine.NET Extensions, so after setting the Akismet Extension options, I clicked the "View" link for that extension... "Source for [/opt/blog/BlogEngine/BlogEngine.NET/App_Code\Extensions\AkismetExtension.cs] not found" Doh! Clash of the Slash!

It appears that BlogEngine.NET still doesn't have enough of a *nix following to have ironed all the bugs out. But I've reported what I've found, and just put my latest patch for BlogEngine on Mono up. You'll find it on the BlogEngine.NET Mono Patches page.

From your BlogEngine directory:

host:/opt/blog/blogengine-27024.dev# patch -i /tmp/blogengine-27024.patch -p1
patching file 'BlogEngine.NET/admin/Extension Manager/Editor.ascx.cs'
patching file DotNetSlave.BusinessLogic/API/MetaWeblog/XMLRPCRequest.cs
host:/opt/blog/blogengine-27024.dev#

P.S. I haven't actually switched my live blog to the new 1.5.1.1 code... yet. I want to test it in a development environment a little more first.

Currently rated 1.5 by 178 people

  • Currently 1.5287/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

.NET | BlogEngine.NET

BlogEngine.NET r11405 on Mono Patch

by Ivan Hamilton 5/22/2008 5:45:00 PM

I've just put my latest patch for BlogEngine on Mono up.

You'll find it on the newly created BlogEngine.NET Mono Patches page.

From your BlogEngine directory:

host:/opt/BlogEngine# patch -i /tmp/blogengine-11405.patch -p1
patching file BlogEngine.NET/App_Code/Controls/Blogroll.cs
patching file BlogEngine.NET/App_Code/Controls/MonthList.cs
patching file DotNetSlave.BusinessLogic/BlogEngine.Core.csproj
patching file DotNetSlave.BusinessLogic/Web/HttpHandlers/FileHandler.cs
patching file DotNetSlave.BusinessLogic/Web/HttpHandlers/ImageHandler.cs
host:/opt/BlogEngine#

Currently rated 1.5 by 104 people

  • Currently 1.519231/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

.NET | BlogEngine.NET

Tuning my PID controller 2

by Ivan Hamilton 5/10/2008 10:44:00 PM

I've mentioned previously that I think it's beyond me to visually judge the performance of the PID tuning values in use in my servo controller.

I had created a simple program to test the response, but wasn't happy with the point to point style test it was carrying out. It's more important for a CNC machine to follow curves closely, than have outright movement speed.

To fix this, I've added a feature to the microcontroller, a sine wave test. The test was added to the controller, because for a good test, a position update needs to be present every time the PID loop recalculates. By placing the sine wave path generation in the controller, a new movement value is present every single PID update. I couldn't achieve this sort of high performance timing by sending updates down a serial line.

Also, the standard point to point test produces massive errors when the set-point jumps, masking the fine detail of an "error" plot. I've added it now (on it's own axis), and it's very helpful in seeing exact levels of error (the large scale of the movement would otherwise hide this relatively small error). 

 
Rotate 1 revolution forward and back in 1 second

 
Rotate 1 revolution forward and back in 5 seconds

In the above images you can see the reduction in error during a slower test (from +/-10 to +/-3). On the slower test, that's within 0.9 degrees.

I've also included a "steady state" option. This doesn't instruct the controller to make any movement, but it does record and display it. This lets you see the response to an external disturbance on the servo (the handy shifter!).

Armed with this new information... I still haven't gone back and re-tuned the PID values.

Currently rated 3.0 by 2 people

  • Currently 3/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

.NET | CNC | Electronics

Tuning my PID controller

by Ivan Hamilton 5/9/2008 4:21:00 PM

The nice thing about making your own PID controller, is that it's easily modified to add extra features. The nice thing about having PC software development skills, is that it's easy to whip up a small program for a particular task.

I've mentioned on a number of occasions, that I hadn't yet tuned the PID settings in my controller. I didn't want to do this because I could spend all day tinkering with values without being able to accurately judge the exact effect. What I needed was a way to monitor the servo response.

It took less than a dozen extra lines of microcontroller code, and a couple of dozen lines of C# (WinForms) to make a GUI application to test and monitor the servo. Once I had this, I could change values and with a mouse-click see the results. This made it very quick to tune by trial and error.


Step response before tuning


Step response after tuning

The best "simple" explanation I've heard for these values are:

  • P - Proportional - Spring - The greater the error, the more correction applied
  • I - Integral - Accuracy - The longer the error, the more correction applied
  • D - Derivative - Dampening - The more the error changes, the more correction applied

The best "simple" tuning method I've heard is:

  1. Set P, I & D gain values to 0.
  2. Increase P until it becomes unstable (post-step oscillations don't fade).
  3. Halve P.
  4. Increase D until overshoot is removed.
  5. Increase I until it settles quickly enough when disturbed

I used this method and it appears to work well, but this was a simple test on an unloaded motor. It will be interesting to try this once fitted to a more complicated system.

There is an issue with the current test... this a step-response scenario. That's great for a system which needs to move from A to point B as quick as possible. But in a CNC machine, it doesn't just move from one point to another. The motion controller (e.g. Mach3 or EMC2) will produce "smooth" motion with a constant stream of position updates. What is more important, is that the servo accurately follows this acceleration, than achieve high outright point to point speed.

In the future, I think I'll need to add a "Curve Follower" tuning option. Instead of jumping from point to point, this will drive the servo as if it was tracing a circle (a sine wave pattern).

Currently rated 2.0 by 24 people

  • Currently 2.041667/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

.NET | CNC | Electronics

More Mono & BlogEngine issues

by Ivan Hamilton 5/8/2008 2:34:00 AM

I've recently submitted to the Mono team (and had accepted) a few patches to fix the issues I've found running BlogEngine.Net under Mono on Linux.

At this point, you will need the very latest Mono release (r102737) from SVN to get the fixes. These fixes are for Windows/Linux interoperability, cross directory master page & user controls, and Forms authentication.

With these fixes now applied, I now know of no problems with Mono running BlogEngine.Net on Linux. (I say "know of" because I haven't tested everything yet).

No problems with Mono, but there are problems with BlogEngine.Net.

The BlogEngine.NET code makes a number of assumptions (like a Dictionary will retain the order of items that are inserted) that aren't part of the .Net runtime's specification. I have 3 issued logged in BlogEngine.Net's Issue Tracker on CodePlex. All of the issues I've reported include the code changes required to fix them. Three weeks later, and they still sit there. There are three weeks worth of issues between mine and the latest one resolved. I expect we'll see them applied in about three weeks.

But on my system... all problems appear fixed.

Currently rated 3.0 by 1 people

  • Currently 3/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

.NET | BlogEngine.NET

There was an old lady who swallowed a fly

by Ivan Hamilton 4/21/2008 12:39:00 PM

In my effort to get BlogEngine.NET running under Linux I've been chasing a few issues...

I had Mono 1.2.5.
Had a problem with HTTP file uploads from Windows based browsers.

I upgrade to Mono 1.9.
Fixed the problem with HTTP file uploads from Windows based browsers.
Introduced a problem with URL rewriting.

I upgrade to Mono from SVN r101230.
Fixed the problem with URL rewriting.
Introduced a problem with master pages in a different path from the content page.

I hacked up System.Web.UI.TemplateParser.cs r101177 with an ugly work-around.
Fixed the problem with master pages in a different path from the content page.
Introduced... who knows what else.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

.NET | BlogEngine.NET | Pragmatism

BlogEngine.NET... now with extra arsehole!

by Ivan Hamilton 4/17/2008 1:02:00 AM

I've pointed out before that I'm going to take a crack at this blogengine.net thing. That all started in November. It's now March and I thought I'd update to the latest release. Just before Xmas, 1.3 was released, and included the tagline "Mono is now fully supported out of the box". Woohoo!

But, it's not quite right.

Four months after "Mono is now fully supported out of the box", I went and grabbed the latest released source and did an install. Disappointing. Many bugs and issues are still there. A number of pieces of functionality fail outright. The code is still littered with Windows reference paths and other assumptions. Bugs exists that only surface under a different implementation (like Mono on *nix).

I've started submitting to the Issue Tracker on CodePlex. I'm not hopeful as the issue tracker is full of n00bs screaming about how they couldn't get something to work. Let's see how it goes.

Currently rated 1.5 by 4 people

  • Currently 1.5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

.NET | BlogEngine.NET

Generic Obscenity

by Ivan Hamilton 12/12/2007 6:33:00 PM

I've been trying to fix outstanding issues in my MonoMerge build and most problems appear to resolve around generics.

I have 3 test assemblies (1 EXE, 2 DLL) that I use to test. The EXE references the two DLLs and they reference each other. To test, I build the 3 assemblies, Merge the three assemblies into 1, disassemble the 3 original and 1 merged assemblies. I then run a custom little tool over the IL text to compare the method bodies. The custom tool is needed because the order of items in the merged assembly isn't preserved.

My little test assemblies only cover what my mind can come up with... and I'm pretty gentle. For a final test, I use "the most terrifying assembly for generics stuff: the great C5 library". I was introduced to the C5 Generic Collection Library by a jbevain post. He was happy that Cecil could round-trip C5 (I don't know how he tested the result). So that seemed like a good test for MonoMerge. My god, C5 IL looks like an exclamation mark factory exploded. Here's a couple of examples:

.method public virtual  hidebysig  newslot instance default class C5.IList`1<!!V> Map<V> (class C5.Fun`2<!T, !!V> mapper)  cil managed
IL_0015:  call instance class C5.IList`1<!!0> class C5.ArrayList`1<!T>::map<!!0> (class C5.Fun`2<!0,!!0>, class C5.ArrayList`1<!!0>)

Ugly as it may seem, it is a very good test. There have been quite a number of possible generic usage scenarios that I wouldn't have thought up myself.

At this point, I'll state that there's no way in the world I could debug the issues I'm having without ILDasm, PEVerify & MonoDis. If you ever try assembly manipulation, you can not live without these.

After undoing some work (that I shouldn't have done), my own tests appear to pass (again), but C5 brings everything crashing down (in new and interesting ways). Argh!

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

.NET

Mergin', mergin', mergin', Though the GC's purgin'

by Ivan Hamilton 12/10/2007 6:36:00 PM

Call me old-school, but one thing that I miss in all this new fangled .NET world is the neat single EXE solution. If you grew up with C object or Pascal unit files, then you might miss the ability to combine pre-compiled code into the target file under .NET.

Static linking it's called, but it's fallen terrifically out of fashion in these days of dynamic linking with DLLs and shared objects.

Mono has a linker project that aims to produce the minimal possible set of functions that a program might require to run (as opposed to the full libraries). It creates a set of reduced assemblies that can fulfill the needs of the program.

That's part of the way... I like the reduction in code size through linking, but I also want a single file solution (mainly because I'm too lazy to think about multiple files).

There's tool over at Microsoft Research, ILMerge, which can combine multiple assemblies into one. But it's proprietary, so usage is restricted and source is unavailable... meaning no derived tools can be created.

Enter MonoMerge, a tool that takes a set of assemblies, and merges them in a single one. But it appears that it's been abandoned. What's a geek to do?

I had a look at this tool and it appeared good enough during a simple test. A little more testing, and it started to fall apart. There appears to be two areas where the code falls down: name clashes & generics.

If two assemblies had private classes with matching names (like the ubiquitous <PrivateImplementationDetails>), then all code would incorrectly refer to only one of the classes. This would result in either an inability to resolve members during merging, or resolving to a similarly named member in the wrong class! This is a real problem as the compiler will often use such classes for array initializers or caching dictionaries used in switch statements. I originally tried to make a few small changes to the existing code to add class renaming support, and while this partially worked... a complete implementation along those lines would just scatter if/else statements throughout the code. It also didn't help resolve the generics issue.

Generics were a problem because in resolving MethodReferences equality was judged upon the ToString() result of MethodReferences. This causes problems because two different calls can share the same ToString() signature. A simple example:

    public class CalledGenClassClass<U>{

        public static void CalledMethodMethod(){}

    }

    public class CalledGenMethodClass{

        public static void CalledMethodMethod<V>(){}

    }

    public class GenMethodClass{

        public static void DemoMethod<T>(){

            CalledGenMethodClass.CalledMethodMethod<T>();

            CalledGenClassClass<T>.CalledMethodMethod();

        }

    }

    public class GenClassClass<T>{

        public static void DemoMethod(){

            CalledGenMethodClass.CalledMethodMethod<T>();

            CalledGenClassClass<T>.CalledMethodMethod();

        }

    }

We've got four calls, happening here. A generic method & generic class call, each using a generic method & generic class parameter. The problem is both calls have the same ToString() signature from a Cecil point of point (CalledGenMethodClass::CalledMethodMethod<T>() & CalledGenClassClass`1<T>::CalledMethodMethod()). Which is fine, but the parameter T is only valid within the scope of the body calling the reference, you can't use it outside of a method body, because T might mean something different.

In IL these signatures differ using the (!) notation:
GenMethodClass.DemoMethod: CalledGenMethodClass::CalledMethodMethod<!T>() & CalledGenClassClass`1<!T>::CalledMethodMethod()
GenClassClass.DemoMethod: CalledGenMethodClass::CalledMethodMethod<!!T>() & CalledGenClassClass`1<!!T>::CalledMethodMethod()

I originally tried to change Cecil to return !T or !!T in ToString(), but then realised the notation wasn't the solution. There would still be a deeper issue of resolving references.

I set off to find a better way to resolve MemberReferences...

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

.NET

Generics Variance: Covariance, Contravariance and Invariance

by Ivan Hamilton 12/6/2007 5:23:00 PM

There's alot of things you don't think about until... you have to think about. I recently came across generics variance in C# (or lack of it). Best explained with a quick example.

Firstly get yourself a simple structure:

    class Animal { }

    class Mammal : Animal { }

    class Dog : Mammal { }

    static void AnimalMethod(Animal animal) { }

    static void AnimalArrayMethod(Animal[] animal) { }

    static void AnimalListMethod(List<Animal> animal) { }

Then do something very simple:

    AnimalMethod(new Dog());

    AnimalArrayMethod(new Dog[0]);

    AnimalListMethod(new List<Dog>());

Just think about that for a moment. Is it safe to pass a reference to a Dog for an Animal parameter? Can a Dog[] be treated as an Animal[]? Does it make sense to pass a List<Dog> for a List<Animal>?

Yes, no & maybe. (Compiler: AnimalMethod & AnimalArrayMethod calls are valid and AnimalListMethod call is invalid)

Let's look at the above examples:

  • AnimalMethod - Simple reference conversion: Nothing new here.
  • AnimalArrayMethod - Array Covariance: A controversial C# feature. If I pass a Dog[] thru an Animal[] parameter, it's valid at compile time for that method to assign a Cat into the array. Because of array covariance, assignments to elements of reference type arrays include a run-time check that ensures that the value being assigned to the array element is actually of a permitted type.
  • AnimalListMethod - Generic Covariance: A non-existant feature... but does it make sense? Well... as much sense as array covariance.

The compile time validity of array & generic variance would depend upon the action being performed. If we were to only read an element, covariance is safe (each Cat can be treated as an Animal). If we only write, contravariance is safe (into Animals we can place a Cat). If we read and write, then invariance is safe (only Cat into Cats and Cat from Cats).

C# array variance is broken. Why? Because it's unbalanced: covariance is supported while contravariance is not. For every instance you may want covariance to support passing in subtypes, there's a case for contravariance to pass out to supertype referenece.

C# generic constraints are broken. Why? Because it's unbalanced: subtypes are supported while supertypes are not. For every instance you may want subtypes to support passing in subtypes, there's a case for supertypes to pass out to a supertype referenece.

I don't know if variance be can "fixed". Any changes to existing array covariance, would probably make far too many people have to think about their code. Compiler designers hate breaking changes (new compiler won't compile old code). You'd also need language extensions to allow you to declare whether you permit covariance/contravariance at certain points.

I doubt it will get addressed... we must learn to live with what our compiler allows. Human sacrifice, dogs and cats living together - mass hysteria.

P.S. Eric Lippert has a brilliant set of posts on Covariance and Contravariance.

Currently rated 3.0 by 5 people

  • Currently 3/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

.NET

Powered by BlogEngine.NET 1.3.1.30
Original theme by Mads Kristensen

About the author

Name of author Ivan Hamilton
"My inner nerd can beat up your inner nerd."

E-mail me Send mail

Adsense

Calendar

<<  October 2014  >>
MoTuWeThFrSaSu
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

View posts in large calendar

Recent comments

Tags

None

    Entropy

    Disclaimer

    The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

    © Copyright 2014

    Sign in