Tuesday, May 22, 2012

Ordinary Differential Equations Solver

I've started the translation of the odeint-v2 boost library to SciSmalltalk. So far, I have defined the basic portions, a Stepper base class, an ExplicitStepper subclass which is for the time being masquerading as an Euler Stepper, an ExplicitSystem class which is a thin wrapper over a block, and some test cases for it.

Things should ramp up as I get into the flow of things. I'm not committing any of these to public repositories until I have something looking moderately useable. I may use this as an opportunity to make a branch on github (have been working straight to master so far).

Sunday, May 20, 2012

SciSmalltalk Updates

I updated SciSmalltalk's Metacello configuration to version 1.01. This version incorporates new bugfixes in the GeneticOptimizer submitted by Werner Kassens, and includes 200 unit tests. Test coverage is about 65-68% right now. This number is difficult to gauge as TestRunner and Monticello are having some confusion about which package some methods reside in, so the coverage is registered once, but the methods are shown twice. Though I have an internal guess about which these are, I have a hard time justifying the firm numbers. Once I have 100% test coverage, it will likely still show several methods in the list. C'est la vie. The broad majority of uncovered methods are in DHB-Numerics (a little over 400 methods need tests.)

I'm tempted to look into incorporating Nicolas Cellier's Arbitrary Precision Floating Point package (already included his Quaternion, Complex, and Number Extensions). I'm a little sad that there are no Doubles in Pharo/Squeak.

I need to start in on the ODE system solvers. I'm looking into odeint-v2 as a source of inspiration. Un-templating the C++ code into a dynamic language looks to be a fun time for me! I'm not certain I need to involve the generality of arbitrary algebras that they did, a good portion of this looks like it was built in to add support for CUDA operations.

I had a fun time this morning, as I did a pull merge in the wrong order and had to play some games to get my work from last night brought back into line. All the code from the commit was still visible, and all the packages were in the cache, so it wasn't more than a well learned lesson for the future. At least my own commits are visible in the timeline on my github person page.

Wednesday, May 16, 2012

Shared Experience

A real talk about smalltalk

This is a great post. I completely understand the revulsion when loading Squeak for the first time (esp. if you get Squeak 3.9 from your Linux distro). Like the author here, I feel that seeing Squeak 4.3+ or any Pharo image is a huge relief after using the coloring book releases of Squeak 3, with the drag and drop scripting tools everywhere.

And like the author, I have to say a dozen nice things about the debugger. Really the power tool that separates Smalltalk from any other language. Why doesn't gdb have an editor, compiler, and on-demand dynamic linker built in as a standard feature? I can think why.

He links also to 10 reasons why I'm using smalltalk as a starting point for his investigations, and points to James Robertson's screencasts at Smalltalk for you as being a useful jumpstart into using the system. I really hate screencasts, since I want to click on the 'desktop' but only end up pausing the video! But Robertson's continuing efforts at education are a treasure, and deserve a wide audience.

Sunday, May 13, 2012

Bug Fix

I think I may have submitted my first bug fix. Or I just added to the noise level.
In Pharo, the TestRunner tool allows for determining how much coverage your test suite has over some package. Basically, it records all the messages sent during execution of the tests, and compares this against all the messages implemented in that package. My personal goal is 100% test coverage, though that sometimes leads to a few seemingly meaningless tests.

Development on Pharo-2.0 is moving to restructure the basic tools and frameworks in the system, which has the unfortunate side effect of sometimes breaking the tools you are using. Something happened in the past week that broke the Run Coverage tool in TestRunner. I noticed that I could patch around it by undoing a few small changes that the developers made in the system dictionary (basically, the method for finding which tool handles which class of tasks). This worked for a few days, until the tool I moved it back to was removed from the system by another patch.

I spent a couple days working in Pharo-1.4 because of this, which is stable and unlikely to have more new problems. Today, I updated a clean 2.0 image and just let the debugger show me what was wrong. Four new methods later, I was able to get a coverage list running. The Smalltalk debugger is such a useful tool!

Rather than simply emitting a message, it gives you the entire call stack. Each stack frame is live, that is, you can look at all the passed arguments, change them, inspect them, send methods to them, etc. All of the errors I received were ultimately of the form X does not understand Y (trying to call a function on an object that doesn't implement it). Rewinding 2 stack frames showed me the call site in TestRunner's collectResultsFor method, and in the debugger, I could click on the does not understand error, click create, tell it which class in the hierarchy of X to implement the message in, choose a protocol, write the (very short) code to handle the method, and restart the stack frame where the call failed, and try over.

Honestly, as a very inexperienced programmer, to have a system so immediately supportive as to allow fixing a problem with the system tools in a few button clicks, test it, confirm that it's working, and move on with my life, is a huge relief. Having a system so understandable that it takes about 10 minutes and 10 lines of code to fix a problem in the IDE is exhilarating.

The next process involved feeding this back to the developer team. In Pharo, issues are tracked on google code, and if you've opened a ticket, you can automatically document your patch. In Nautilus, I clicked create a slice, which asked me for an issue number (mine was 5839), then automatically inserted the issue description in the slice. Submitting to PharoInbox was one more click away, and if what I did was useful, that's a bug fix!


Wednesday, May 09, 2012

Milestones for this week

Well, it's already Wednesday. I plan to get as much test coverage and documentation sorted out by Friday as possible. Then on to building/reconstructing/thinking about ODE's and their solutions.


SciSmalltalk Progress and github concerns

Today, I've been working on getting better test coverage for the packages in Math for SciSmalltalk. I have documented and completed coverage for DhbFloatingPointMachine. It looks like (following Didier Besset's Book) DhbPolynomial will be next, in chapter 2.2.

I added the complex class, and it looks like there are a lot of failing tests for Trigonometric/Circular functions.

Werner Kassens is interested in adding a KDTree implementation, and I'm excited to incorporate this when it materializes.

Does anyone know how to refork/synch a fork with upstream master on git/github? I've made the mistake of committing directly to upstream, and want to catch up with the changes I've made, but don't see the way to refresh a fork once upstream has gotten ahead of me. I think in the future what I want to do is push to my fork, then pull into master.

Also, has anyone had an issue with github deciding to use korean text in button images? The hover text is english, but all the graphics are now Hangul. Though I'm open to learning new powerful magics, I'm more of a Roman/Cyrillic/Hellenic reader, and Asian scripts always strike me as too foreign.

Lastly, I created a dummy-repo to test inline images in markdown. This is nowhere as easy as it should be! Dummy Repo

Tuesday, May 08, 2012

Ubuntu woes

Urgh, once again I struggled through the semiannual fight to bring a new ubuntu release onto my machines. It looks like my laptop adapted just fine, no loss of data or functionality, and apparently multiscreen display started working again.

My desktop had an issue where the soundcard module wasn't loaded into the kernel at boot. lsmod and modprobe showed tons of good things, but sound preferences was sending all my output to dummy device... well, reinstall from disk and thank heaven I partition /home far from /bin and /boot, and a fresh install is never more than a few hours of synaptic from yesterdays machine.

Since I've moved well away from Unity, I sometimes forget how little I like it, it's like a cute little jail, with a non-configurable dock, stupid invisible scrollbars, and garish colors. Gnome 2 on the laptop and WindowMaker on the desktop are the winners, still.

Only thing left is to set static ip on boot, not sure why the 'friendly' installer doesn't ask these questions anymore. Time was, installation was full of more questions than an income tax form.