PicSol – a .net Nonogram/Picross Solver Library

Nonograms – also known as Griddlers, Picture Crosswords, or Picross – are pretty cool puzzles, kind of like a more visual Crossword puzzle or Sudoku. Of all the games on my New 2DS XL, Mario’s Picross and the Picross e series are near the top of my Activity Log (beaten only by Smash Bros).

I got curious about algorithmic solutions to those Nonograms, which seems deceptively easy, but is actually NP-complete. When trying to solve a Nonogram, often I can to only fill in one or a few cells of a group, which then leads to another cell that can be filled in (or X-ed out), and step by step, cell by cell, I solve the Nonogram. Now, that assumes that the Nonogram is properly designed – if that’s the case, then there is always at least one cell that either must definitely be filled or definitely be empty.

All of Jupiter’s games are well designed – even the most tricky ones (with a bunch of 1’s and 2’s and no big numbers) always follow the mantra of There’s always at least one cell that has a definitive solution. There are a lot of other games on the market (Steam returns about 15 games when searching for Picross or Nonogram), and some are not well designed and actually require guessing.

I ended up (after a bunch of googling approaches and other existing solvers) with a solution that’s mostly brute force – generate all possibilities for a row and column, then eliminate those that can’t be correct, rinse and repeat until there’s only 1 possibility left for each row and column, or until we determined that the Nonogram is actually unsolvable. There are some shortcuts that we can take, e.g, when a row/column is empty, completely filled, or completely filled with gaps in-between them.

I’ve created PicSol, a library for .net Standard 2.0 and .net Framework 4.0 (or newer) and available on Nuget which offers a Solver for Nonograms.

Check out the README for information on how to use it, or look at the Console project in the GitHub repository.



Simplexcel 2.0.5

It’s been a few month since I released Simplexcel 2.0.0, which was a major change in that it added .net Standard support, and can be used on .net Core, incl. ASP.net Core.

Since then, there have been a few further feature updates:

  • Add Worksheet.Populate<T> method to fill a sheet with data. Caveats: Does not loot at inherited members, doesn’t look at complex types.
  • Also add static Worksheet.FromData<T> method to create and populate the sheet in one.
  • Support for freezing panes. Right now, this is being kept simple: call either Worksheet.FreezeTopRow or Worksheet.FreezeLeftColumn to freeze either the first row (1) or the leftmost column (A).
  • If a Stream is not seekable (e.g., HttpContext.Response.OutputStream), Simplexcel automatically creates a temporary MemoryStream as an intermediate.
  • Add Cell.FromObject to make Cell creation easier by guessing the correct type
  • Support DateTime cells
  • Add support for manual page breaks. Call Worksheet.InsertManualPageBreakAfterRow or Worksheet.InsertManualPageBreakAfterColumn with either the zero-based index of the row/column after which to create the break, or with a cell address (e.g., B5) to create the break below or to the left of that cell.

Simplexcel is available on Nuget, and the source is on GitHub.

Simplexcel 2.0.0

A couple of years ago, I created a simple .net Library to create Excel .xlsx sheets without the need to do any COM Interop or similar nonsense, so that it can be used on a web server.

I just pushed a major new version, Simplexcel 2.0.0 to NuGet. This is now targeting both .net Framework 4.5+ and .NET Standard 1.3+, which means it can now also be used in Cross-Platform applications, or ASP.net Core.

There are a few breaking changes, most notably the new Simplexcel.Color struct that is used instead of System.Drawing.Color and the change of CompressionLevel from an enum to a bool, but in general, this should be a very simple upgrade. Unless you still need to target .net Framework 4 instead of 4.5+, stay on Version 1.0.5 for that.

Simplexcel – simple .xlsx library for .net

As part of almost every application I work on, I need to create Excel sheets one way or the other, usually from an ASP.net MVC application. During the years, I’ve tried several approaches, and they all sucked one way or the other:

  • COM Interop: By far the worst option. Requires an installed Excel. Slow. Error prone. Resource-intensive. Not supported in a server environment.
  • CSV or HTML Tables: Only supports a single worksheet, not much formatting, prone to break Excel’s heuristics (e.g., the string “00123” is interpreted as a number, stripping the leading zeroes. For big numbers, Excel loves to use scientific notation, which sucks for Barcodes which should just be interpreted as strings) and hard to create (CSV is a pain if you need to escape quotes or have newlines)
  • Excel 2003 XML/SpreadsheetML: A crutch. Uncertain future, limited options, big files. But actually, not too bad.
  • One of the many Excel 2007+ .xlsx libraries: I tried about 4 or 5, and they all sucked in a different way. No offense, but some library authors try to cover the entirety of Excel’s capabilities, leading to an awkward API. Many don’t catch specific Excel limitations that aren’t part of the standard (e.g., Sheet name length or invalid characters), which means I’m creating sheets that cause Excel to tell me there was invalid data, leaving me puzzled how to fix that.
  • Going Low-Level with the OpenXML SDK 2.0. Believe me, you don’t want to go down that road. There is very little help creating the documents, and if you want certain features that seem obvious (e.g., setting the Author of a document, which requires adding the creator element to core.xml) you will find that there is actually no way to do it.

So, all solutions I tried sucked. Which means that I set out to create another solution that sucks slightly less. Armed with some spare time, the ECMA-376 standard and Excel 2007 and 2010 to actually test against, I created a library that has a limited set of features, but implements them well, handles errors properly and (hopefully) has a good API for you guys to work against.

Features

  • You can store numbers as numbers, so no more unwanted conversion to scientific notation on large numbers!
  • You can store text that looks like a number as text, so no more truncation of leading zeroes because Excel thinks it’s a number
  • You can have multiple Worksheets
  • You have basic formatting: Font Name/Size, Bold/Underline/Italic, Color, Border around a cell
  • You can specify the size of cells
  • Workbooks can be saved compressed or uncompressed (CPU Usage vs. Network Traffic)
  • You can specify repeating rows and columns (from the top and left respectively), useful when printing.
  • Fully supported in ASP.net and Windows Services (The documentation contains an example ActionResult for ASP.net MVC)

Usage

You can get the Simplexcel Nuget Package for .net 4.0 Client Profile or higher – https://nuget.org/packages/simplexcel

Documentation can be found at http://mstum.github.com/Simplexcel/

Source Code

Licensed under the MIT License, the code can be found at https://github.com/mstum/Simplexcel

A few more thoughts about SWiki

It’s been some time since I wrote a post about me re-thinking SWiki. In the meantime, I have experimented a bit with several approaches, and the recent announcements of IIS Express and SQL CE 4 sparked some new interest in this project.

As I said earlier, my problem was that I can’t display Images that don’t have a URL in the hosted Internet Explorer, but that I wanted to keep HTML-compatible pages. The first approach is to have a local web server that delivers the pages. There is however a second approach, which involves actually having the images in the file system. I could either store them in the database and “extract” them to a temporary directory when SWiki starts, or I could keep them externally and only “register” them in the database.

I think I like that approach as well, because it solves any corporate networking concerns (IT usually isn’t too happy with people running their own rogue web servers within a corporate network…).

I’m busy with some other projects and I have to find a new name for SWiki (someone else had the name before :)), but I do now have a good idea on what I want to do with it and how to achieve that.

TimeSpan.js Version 1.2 released

I’ve just pushed a new Version of my TimeSpan Library to GitHub. Version 1.2 contains a new “static” constructor TimeSpan.FromDates which takes two dates and returns the difference between them as a TimeSpan. If the second date is earlier than the first date, the TimeSpan will be negative. Pass true as third parameter to force it to be positive.

Usage example:

var date1 = new Date(2010, 3, 1, 10, 10, 5, 0);
var date2 = new Date(2010, 3, 1, 10, 10, 10, 0);
var ts = TimeSpan.FromDates(date2, date1);
var ts2 = TimeSpan.FromDates(date2, date1, true);
alert(ts.totalSeconds()); // -5, because we put the later date first
alert(ts2.totalSeconds()); // 5, because we passed true as third parameter

A simple .ini File parser for C#

Okay, so back in the old days, we had INI Files to store settings in. Those files are very simple:

[Section]
Key=Value
SomeOtherKey=SomeOtherValue

[AnotherSection]
Hello=World

Hardly exciting, but it gets the job done very well. Today I wanted to work with INI Files in my C# Application, both for reading and writing. But as I just found out, .net does not have built in functions for working with .ini files. It looks like they want everyone to work with XML Files now. Well, apart from the fact that XML looks like my keyboard puked on my hard drive and that the format is unneccesarily complicated for this purpose, I also found that reading and writing them is rather complicated, especially since the XmlSerializer has some stupid restrictions (one being that the class needs to be public – have they never heard of reflection?).

It’s great that the .net Framework is so powerful – I believe I can write a function that downloads an MP3 off the internet and uses it to generate a gradient in an image which then gets encrypted and sent per e-Mail in maybe 5 lines or so, but when it comes to something simple as saving some Key/Value Pairs, I still need a crapton of code. So I binged the internets a bit and found some code that uses P/Invoke to call Kernel functions to handle ini files, but I want to avoid P/Invoke at all costs. So in the end I simply wrote a class to Load/Save Ini Files.

It’s a simple class to interact with a simple file format that was created to store Key/Value pairs and that just works. Seriously, don’t change what isn’t broken. The class is licensed under WTFPL and can be downloaded here.

SWiki 0.12 released

Okay, a little change of plans. Originally, I wanted SWiki 0.12 to be localizable, but due to the fact that I’m not satisfied with the built-in features of Visual Studio I’m rolling my own framework now. This will however take a little longer.

Also, because SWiki is still under heavy development, I would have to chase translations first before I can release. So for the time being, I moved it to a later version in the road map.

Instead, I have added a feature to 0.12 that I really needed now that I’m actually using SWiki to create some documents, and that is re-parenting of pages. This allows you to move pages within the tree to other pages. You can not turn a page into a root page at the moment (that was an oversight, to be fixed in 0.13).

Additionally, the Page view now allows copying text through CTRL-C or Right Click => Copy, and in the navigation tree on the left, the Main Page will always be the first page. You can download SWiki 0.12 on the CodePlex Download Page.

Reinventing The Wheel, this time it’s a localization framework

If you look at the SWiki Roadmap, you will see that translated versions are planned for Version 0.12, which is incidentially the next version of SWiki. SWiki is intended to be just a bit outside of my reach, so that I can learn and grow from it. As I have no experience with creating a localized WinForms application, that allows me to learn how to do it 🙂

Unfortunately, Localization support in Visual Studio 2008 left me somewhat unimpressed. So I set the “Localizable” property of my Form to true and then automagically it creates the resources I need and allows me to change any form settings, including Text, Position, Size etc. That is so far a great idea and works very well, but it has several drawbacks:

  • One resx file per form and language means exponential growth of files
  • The resx files are tied to the form – which means I cannot just put them in a “Localized” Folder
  • While it’s great that Forms are supported, I still have to find another way for my Exceptions and other Non-Form Code
  • Translations are stored in satellite assemblies. The Goal of SWiki is to have as few files as possible, preferably only one.
  • No way to share strings between different parts

In short: The built in support is unsuitable for SWiki. I have put my requirements in a StackOverflow question, but the answers were somewhat discouraging. I have looked around a bit and naturally also ended up at GNU Gettext which handles strings, but does not solve the problem of a) non-string content (Images, Location/Sizes of Controls) and b) the actual application of resources to the target.

One of the main issues is that the InitializeComponent() function is somewhat untouchable, as the designer will break if you change it too much and will replace your code with it’s own anyway. Visual Studio is certainly not lying when it tells you to not mess with the function.

So anyway, I have just decided to build my own localization framework for use with the SWiki UI. Finding a name was reasonably easy, I just called it “The Wheel”. I don’t know if it’s going to be much use, but just in case, it’s going to be licensed under Microsoft Reciprocal License (Ms-RL). Release Date? I don’t know, I hope by the end of the week.

SWiki 0.11 released

Another blog post – another SWiki update. That’s the good thing about starting with a small feature set, it allows for rapid expansion 🙂 Along with many smaller fixes, there are two big points in this release.

Export Wiki into HTML Files
Using the now-functional export button in the button bar, you can export your wiki to HTML files. This will generate one file per page, complete with navigation.

Diff between Revisions
There is now a new “Diff” Tab on the main screen. This allows you to pick any two revisions of a page and quickly compare them.

SWikiDiff

Other changes
Apart from these two big points, there are some other changes. In the doc folder, you will find a more elaborate user manual in .swk format. The navigation menu on the left has a context menu now to add new pages. The Syntax Help window should no longer open outside of the screen if the SWiki window is too close to the edge.

Download SWiki for free on http://swiki.codeplex.com/