Command line SUMP logic analyzer client

So, I've been trying to poke around on this modem I received. One problem, I don't have an oscilloscope. I do however have an FPGA. And, FPGAs and be almost anything they wanted to be, so mine became a SUMP logic analyzer, thanks to the porting effort at gadget factory

Anyway, problem is the official Java client doesn't appear to work on Linux 3.x, or on 64-bit machines. I avoid having to do multilib (running 32bit programs on 64bit linux) like the plague, so I decided this will not do. On my quest I also found a half working python logic analyzer client. This one I got to work, but it's quite clunky and the code is GPL licensed. Where's the fun in that?

So, I wrote my own client, apparently in only a week. It's called monosump. It has zero external dependencies and as long as mono/.Net4 works, this client works. I've even tested it on the raspberry pi and it worked fine.

Here are the big features:

  • API-centric. The command line client is just a separate project consuming the easy to use API
  • Command line. Ever wanted to do some analysis with awk and friends? now you can
  • Plain text and JSON data output. Easy to consume.
  • BSD licensed. Have a commercial project in mind? Go ahead and use my code
  • Works everywhere there is a mono implementation(which is everywhere with the processing power to use this)
  • Simple (but limited) command line interface and powerful configuration file interface

Of course, this all being said. It sucks currently. I have a v1.0 release, but that's because I'm impatient. Next steps are getting analysis plugins, serial support at the command line, and maybe a simple web-app interface to take advantage of existing cross platform javascript libraries for graphing.

Posted: 5/29/2013 4:59:33 AM

A preview of my next project

Not going to go into details just yet, but here is a teaser of what I've been working on recently

It's all HTML5/Canvas, including the way I actually created it (ie, I created it in a browser).

If you look at the code, notice it's in no way open source right now. It may be though at some later point.

Posted: 5/8/2013 7:15:28 AM

LightVM + MbedConsole = Not Dead Yet!

So, I've recently been wanting to really get MbedConsole to a all-in-one system, complete with a programming environment. After spending a few months shifting around different ideas on the best way to implement a programming language in such a small amount of resources, I've decided to go another route.

Yesterday, I created a new bitbucket repo called LightVM. Here, I will implement a very lightweight VM complete with a self-hosted assembler with bootstrapping. After getting it to run good on my PC I'll port it to the mbed and eventually also see if it'll work on an ATMega16 or some such.

So, what all will be added to MbedConsole?

  1. LightVM implementation complete with system calls
  2. Assembler for LightVM which runs in LightVM
  3. A very basic file editor. It'll probably be as horrible as ed
  4. "real" filesystem access.
  5. Because the semi-hosted filesystem sucks horribly, I'll be trying to add SD card support

So again, not dead! Check out LightVM. When it gets to a usable state, I'll start working on the bootstrapping assembler and then the actual assembler. The file editor will probably not be made in LightVM for performance and cost of implementation reasons.

Posted: 4/5/2013 12:16:46 AM

BarelyMVC now LucidMVC

So, finally decided to rename the project. However, I decided against ClearMVC as being a bit too plain. So, a close synonym to Clear is Lucid, hence LucidMVC. There is some small MVC PHP framework that was last updated last year that goes by the name of "lucid-php", but I bet I can beat his google page rank :)

Anyway, so there you have it. Update your repository URLs and such to use https://bitbucket.org/earlz/lucidmvc

Also, the BarelyMVC bitbucket repo still exists, but I had to create it from new. So, now it just has a single commit saying "this has been renamed"

Posted: 3/3/2013 6:40:21 PM

BarelyMVC meet ClearMVC

So, I think BarelyMVC isn't just a tiny minimalistic framework anymore. It's goals have changed. It's scope has changed. So, it's getting rebranded to ClearMVC. Hopefully, this will better reflect the primary goal of "no magical black box"

Posted: 2/19/2013 4:40:50 AM

BarelyMVC Roadmap

So, I've been working on BarelyMVC recently and established that there isn't a formal roadmap. I think that's a bit of a disgrace and wish to change that. So, here is the road map target for version 1.0(in order sorta)

  1. Rework to use IServerContext so the entire framework is easily mocked and unit testable(and as a result, the application built on top of it) (note, API should be fairly stable throughout this conversion)
  2. Strive for better unit test coverage(Don't plan on measuring it, but a lot better than right now)
  3. Get session support built into FSCAuth
  4. Integrate CacheGen into BarelyMVC
  5. Documentation and a tutorial or two
  6. Visual Studio and/or MonoDevelop project templates
  7. Compare and contrast document between ASP.Net MVC and BarelyMVC
  8. Setup a CI and/or nightly build server
Posted: 1/20/2013 7:50:03 PM

Making Caching Awesome Again

So, I've recently began a new project. It's no where near stable, or even usable. But I think it's a good enough time to introduce it.

It's called CacheGen and it's hosted at bitbucket and BSD licensed.

Basically, it's a T4 template that generates really awesome helpers for caching. It's geared at ASP.Net, but my goal is to make it so it can be used in other ways as well. So, how does it work? You give it a list of specifications for something you want to cache. Let's say you have a string that's really expensive to generate, but doesn't belong in a database. To go on my theme of markdown being slow, let's call it MarkdownTranslation

You tell the T4 template to create a cache item for it like this:

var tmp=new CacheObject
{
  Name="MarkdownTransform",
  ValueType="string";
}
var cache=new CacheGen("Earlz.Example.MyCache");
cache.Items.Add(tmp);
Write(cache.ToString();

And then, you can use the MyCache class like this:

var text=MyCache.MarkdownTransform ?? (MyCache.MarkdownTransform=Markdown.Translate(foobar));

Much much easier. But, there is a flaw in this. It's possible that we could consume double the server resources required for this. This wouldn't be a problem in this case, but imagine a very heavy SQL query or something. This isn't quite what we want when things are really expensive. So, let's use some other fancy syntax

var text=MyCache.MarkdownTransformCache.LockGetOrLoad(()=>Markdown.Translate(foobar));

What this will do instead is raise a flag so that requests for MarkdownTransform will block and during this time, it will execute the expensive code and other threads will sleep. This way, it only gets executed once. And, when it finally gets the results back, the cache will be loaded with it and the other threads will be able to access it. So, instead of computing the expensive thing multiple times, instead we just hold out other requests for a little while so the expensive thing is done only once.

Sure, you can do this same thing with ASP.Net's cache, but how much code would it require for each time you did this? Hence why it's T4. Also, it's completely statically typed. No casting!

Now, what if you wanted to cache the markdown for multiple posts? Or just want to cache entire post objects? Well, I thought of this too:

You'd make the CacheObject like this in T4:

Name="Transforms";
KeyType="ObjectId";
ValueType="BlogPostData";

Then, you could apply the same lock-first type behavior like so:

var post=MyCache.TransformsCache.LockGetOrLoad(objectid, ()=>LoadPost());

Or, if you prefer the (probably safer) possibly execute twice behavior:

var post=MyCache.Transforms[objectid] ?? (MyCache.Transforms[objectid] = LoadPost());

These are the ideas anyway. None of it is actually implemented yet, and a lot more research must be done to ensure that this is a sane way to go about it. But, you can expect to get something similar to this.

Posted: 12/6/2012 5:17:43 AM

Get REAL memory usage for a type in C#

So far, the using direct IL is very seldom required with how powerful C# is. However, I found a good need: C#'s sizeof operator sucks!

So, I wrote a tiny library to use the sizeof IL instruction.

Differences:

  • Doesn't throw an error on reference types(returns size of pointer for platform)
  • Accurately gets the size of an object IN MEMORY, not just the used size of the type.
  • Has no problems dealing with mixed structs containing references and fields
  • Works exactly how you would expect it to and will work on any type

Also, the IL is extremely simple, boiling down to 2 actual instructions sizeof and ret. It also is verifiable and runs on Mono and .Net, and of course works on any platform (probably including Mono For Android and friends and compact framework?)

It's BSD licensed and here is some example code showing how to use it:

using System;

using Earlz.BareMetal;
namespace Testfoo
{
  class MainClass
  {
    public static void Main (string[] args)
    {
      Console.WriteLine(BareMetal.SizeOf<int>());
      Console.WriteLine(BareMetal.SizeOf<string>());
      Console.WriteLine(BareMetal.SizeOf<Foo>());
      Console.WriteLine(BareMetal.SizeOf<Bar>());
      Console.ReadKey();
    }
  }
  struct Foo
  {
    int a, b;
    byte c;
    object foo;
  }
  class Bar
  {
    string foo;
    string bar;
    AssemblyLoadEventArgs meh;
    DateTime d;
  }
}

You can get the precompiled library (and see the source) at bitbucket

Posted: 11/14/2012 3:17:15 AM

Next project: TranslationMatrix

Yes, I completely stole that name from Dr. Who. But, it's very fitting.

Basically, my next project will be a way to magically modify any .Net program so that, given translation strings, it should be capable of being translated to another language, requiring no changes to the source code at all!

Pretty exciting stuff! I'll have more news about it as I implement it. First off, it won't be open source, at least not initially. Other details will surface later.

Posted: 11/9/2012 5:11:47 AM

BarelyMVC -- Awesomeness on a framework

So, I've recently been putting in some really really awesome improvements to BarelyMVC. So much so, that I'm beginning to think it should be renamed because it's not longer "barely" an MVC framework. It still goes by the principal of minimalism, but my second principal now though is as little magic as possible. And also as few "magic strings" as possible in a web framework.

Magic strings I think are quite horrible. Magic strings can take a few different forms. All of them are equally evil in my opinion. Examples:

  • Using Dictionary<string, object> instead of a strictly typed class
  • Specifying method or property names of a strictly typed class as a string for the purposes of reflection and it "magically" working
  • other strings which semantically mean something and can't be changed at whim (ie routing strings)
  • Anonymous classes in some cases are really just magic strings in disguise. Particularly throughout ASP.Net MVC.

Now of course, not all magic strings are avoidable... and of course some magic strings are avoidable, but it'd be a super huge pain to do by static typing. This should be the exception, not the rule.

So, instead of using anonymous methods and magic strings that point to methods, in BarelyMVC I make everything very explicit and statically typed. The only thing close to magic strings are:

  • Route URLs... I actually have a plan to eradicate that problem even
  • Mappings of HTTP POST and route parameters to static classes. It isn't really possible to do this without sorta magic strings.. at least not and your code be easy to read

So, instead of relying on reflection that no one can intuitively figure out, and referencing filenames and methods as strings to keep code as small and "concise" as possible, I make you type a bit more. But, in exchange for typing a bit more, it's blisteringly easy to figure out why things work like they do... and when you decide to refactor and change your method names in your controller to something else, you're not left wondering why it no longer works because if you do that with BarelyMVC, it will give you a good ol' fashion compiler error.

Also, have I mentioned statically compiled and typed views. VIEWS.

Of course, BarelyMVC is definitely still going through a huge metamorphosis to become something really cool to use. It's API is breaking each day right now, but these changes are beginning to get wrapped up(I don't even have this website using the latest version anymore).. However, when it finally hits 1.0, you're going to wonder why someone didn't make such a thing earlier!

Posted: 10/28/2012 1:19:49 AM