Status update for GeoGebra.

My contributions for the first part of the first part of GSoC 2010 can be divided in two: general improvements and coding.

General improvements

I made a few general improvements on GeoGebra:

  1. Refactored build.dir in ant build file. Previously, build.dir wasn’t in the root directory.
  2. A few ant tasks were added, such compile-grammar, compile-oe (outside Eclipse), run-easyb and run-easyb-outside-eclipse.
  3. SVN properties were set in order to work outside Eclipse. This way, .class files will be kept out of the repo without the intervention of any Eclipse plugin.
  4. Easyb, a BDD groovy-based framework, has been included in order to test GeoGebra. It is not RSpec, but I guess it’ll do.

Coding

First, I started creating a few EquationPoint classes,  currently there are six EquationPoint children classes:

EquationPoint type hierarchy

  • EquationFreePoint represents an independent point.
  • EquationSymbolicPoint represents a dependent point,  EquationSpecialSymbolicPoint standing only for the locus point.
  • EquationNormalPoint and EquationPointVectorPoint are only auxiliar elements.

Then, a few EquationElement classes were added, these stand for the different constructions:

EquationElement type hierarchy

EquationElement is an abstract class containing a few basic methods:

  • forPoint: Given an EquationPoint, returns a String with the equation that means that the point is in the construction.
  • isAlgebraic: returns true if the construction is algebraic, and false otherwise.

Both EquationGenericCircle and EquationGenericLine are abstractions of specific line and circle contructions, all of them algebraic. EquationGenericSegment is to segment what EquationGenericLine is to lines. Obviously, EquationGenericSegment is not algebraic.

All of these classes are used together by EquationScope.

A pause for a screenshot.

Screeenshot

Click for enlarge.

A glimpse into the future.

What to do next?:

  • Maybe Equation should be a proper class, not just a String.
  • More equations.
  • Working out the locus equation.
  • Not using an algorithm twice.

Status Update: RMagick4J, Nokogiri, ruby2java and a possible MagickWand4J

It’s been long time since last status update, but there are some things to tell, so here I am.

Thankfully, this year I’m a GSoC student again (and my mentor is Tom too). The main part of my project would be porting Nokogiri to JRuby, so I haven’t code for RMagick for a while now.

Let’s start with the status update then.

Nokogiri

I’ve been working on Nokogiri for a while. I forked Charles’ repo in Github, and I’ve implemented some cool features. For example, today I got my XML::Reader implementation to pass all tests in test_reader.rb. I hope I’ll be able to make a release this month (cross your fingers).

On the other hand, I got my first patch accepted in Nokogiri’s main repo.

RMagick4J

Not to much work done here, sorry. I haven’t code anything for a while now. Migrating from mercurial to git is already planned, but before that I would like to do a few commits more. Anyway, I’m quite happy with this project. Some people are using it and reporting bugs (in the end, those little things are all that matters). What else can I ask for?

Please, if you find a bug, report it here.

MagickWand

Tim Hunter (creator of RMagick) released MagickWand recently. I’ve been considering porting it to JRuby too. I have to take a deeper look at the C code, but, by now, I think it could be a good way to lead RMagick4J development. If finally I port it, I will split RMagick4J in two projects (Magick4J and RMagick4J). This way, MagickWand4J and RMagick4J would share the same java codebase, as MagickWand and RMagick share ImageMagick.

ruby2java

Take a look here. Awesome, isn’t it? And as soon as I have some time to work on it, siesta will be out too…

P.D. By the way, no more personal stuff in this blog. That stuff is now here, and only in Spanish (sorry about that).

Google, you are not doing it right.

Today, I woke up with a quite sad and disgusting new. Google doesn’t let ADPs (Android Developer Phones) see and download neither copy-protected nor paid apps. Why? Because Google protects the apps using a simple method: “Let’s put the apps in a folder the user cannot see”. But there is the problem, ADP’s users can see every folder, and can copy from and to them. I don’t know who the security guys are but avoiding developers to use that kind of apps is not the solution. If hiding the folder is the new super-safe state-of-the-art piracy-avoiding technique let me say that it sucks. This kind of decisions makes me wonder what’s the actual reason the apps cannot be installed in the sd card. Maybe because it is harder to hide a folder there?

G1: A good gadget.

Finally, I received my brand new G1 (dev edition) yesterday morning. It was love at first sight, even with some sentences for the memory I won’t tell here. Anyway I like it, so here you are some advices to make the battery last longer:

1.- Delete all APN you are not going to use (in my case, all T-Mobile access points).

2.- Turn off Wi-Fi, bluetooth and GPS unless you need them.

3.- Use only 2G networks if you do not need 3G.

4.- Screen brightness is fine at 25% (at least for me).

I tell you more when I have enough time to play with my new gadget.

By the way, it cost 430€.