palaso.org

Which WeSay?

Author John Hatton | 06.01.2009 | Category WeSay

Our approach to software development requires that we “ship early, ship often”. We listen carefully to you, and try to quickly respond to your requests (though at this point, we’re way behind on many requests for new capabilities).

The down-side of this approach was that the newest version is not always the safest. We don’t have any “testers”, so if a release had great, sweeping new features, it could come with related bugs.

This has now changed. We now make two versions available to you. One is the safest (”stable release”). The other has the latest stuff (”development release”). If you are checking out WeSay’s capabilities or willing to help guide us, you want the dev release. If you are deploying WeSay to less computer-savvy or less network-connected users, you want the stable release.

When we hear of a serious bug, we will normally fix it on both releases. New features and non-serious bugs only get added to the development release. Make sense?

To make it easier to track which is which, we use the old Linux-kernel numbering approach. The stable track uses even numbers, the development track uses odd ones.

Our current “stable” releases are 0.4, and the “dev” releases are 0.5. And remember, there are new versions, especially of dev releases, several times a week. So if it’s not too inconvenient, it helps if you can check with a recent release before reporting problems. Thanks!

0 comments Read

New Dashboard

Author John Hatton | 05.01.2009 | Category WeSay

It’s been a wild year for our team, and if all you do is follow this blog, you’d think we disappeared. Eric has moved to Microsoft (lucky them!), I’ve moved from Thailand to the USA and then Papua New Guinea, and two new guys have joined our team in Thailand. Amidst all that, I’ve fallen behind in blogging about our progress. In this post and others which should follow shortly, I’ll try to catch up.

Starting with version 0.4, we’ve changed the “dashboard” you see when WeSay opens up. With this change, we get more on the screen, lessening the need to scroll down. Also, the new design organizes tasks into groups so that users can have a sense of the workflow. Some of this will become more clear as we add tasks to the various sections.

You can see from this screenshot that we have some work to do on this still… the Word List task should display a “progress indicator” like we see in the second row. “Review” and “refine” are two more sections, which I hope to see populated in the future.

0 comments Read

WeSay on the Eee 900

Author John Hatton | 26.08.2008 | Category WeSay

The Eee is, so far, the best selling of the new wave of “4P” computers; laptops which are characterized by low Price, adequate Performance, portability, and low electrical Power requirements. Now, this is no OLPC; it costs around $500 and isn’t as rugged. It does not aim at the same ultra-low power usage. But it does have two things over the OLPC today: you can buy them on Amazon and you can get them with Windows XP. (Yes, sadly we’re still waiting on some open source pieces to mature on the Linux side before we can get WeSay running on the OLPC and other Linux boxes).

So, how would WeSay run on this relatively slow (900 Mhz), relatively low-wattage machine? Getting Windows installed and running, the Eee felt very sluggish. Because of delays, I found it easy to make errors when using a web browser. Very slowly, I grabbed .net 3.5 sp1, then WeSay build 1451. Very slowly, I ran the installer. By this time, I wasn’t expecting to have a happy WeSay experience.

To my surprise, WeSay runs GREAT on this box! Changing records, finding words, and bringing up new tasks were all pretty snappy.

Note: I only did a quick walk-through using the sample data, so please don’t go out and purchase a hundred Eee’s to run WeSay based on this blog post.

0 comments Read

Git notes

Author admin | 23.06.2008 | Category Developers, WeSay

Now that I’ve used git for a couple weeks, I thought I’d make a few notes of commands I’ve found helpful.

To make a local branch for development
git checkout -b name_of_new_branch

To commit changes to the local repository (although I usually use the visual gittk for this)
git commit -a

To commit changes back to subversion
git svn dcommit

To uncommit
git reset HEAD~1

To keep a local branch up to date with subversion (use git stash to hide away local uncommitted changes for later)
git svn rebase

To move the master branch up to trunk
git checkout master
git svn rebase

to handle conflicts with merge
git mergetool path_to_file_needing_merge
or
git mergetool -t toolname path_to_file_needing_merge

To remove untracked files (like the temps that get created during a merge resolve)
git clean -n to see what it would do
git clean -f -d (-d if you want to remove untracked directories as well)

0 comments Read

Git, Subversion and a CRLF mess

Author admin | 23.06.2008 | Category Developers, WeSay

When initializing from WeSay’s Subversion repository, (git svn init -t tags -b branches -T trunk http://www.wesay.org/code/WeSay) I found that I was then told that I had a ton of files that had changed. Turns out on Windows, git has core.autocrlf = true by default — a good thing. But git-svn apparently doesn’t take this into account and if you have crlf’s stored in the svn repository, they will be pushed into the git repository as well. So for now we have a repository that has crlf’s in it instead of just lf’s which get translated depending on the platform. Setting core.autocrlf to false and then doing a hard reset will make this work for now, although not as nicely as we would like. (git config core.autocrlf=false; git reset –hard)

0 comments Read

Merging with git

Author admin | 12.06.2008 | Category Developers, WeSay

Git still doesn’t have good unicode support so to merge unicode files that git has labeled binary, I wanted to use a visual merger. Finally figured out how to do it — add the following lines to config:

[merge]
   tool = tortoise

[mergetool "tortoise"]
   cmd = \"TortoiseMerge.exe\" /base:\"$BASE\" /theirs:\"$REMOTE\" /mine:\"$LOCAL\" /merged:\"$MERGED\"

[mergetool "p4"]
   cmd = \"p4merge.exe\"  \"$BASE\" \"$REMOTE\" \"$LOCAL\" \"$MERGED\"

If you don’t have TortoiseMerge.exe in your path then you can replace that with the full path (c:/Program Files/TortoiseSVN/bin/TortoiseMerge.exe).

0 comments Read

Upgrading user settings in C#

Author Tim | 10.06.2008 | Category Developers, WeSay

In the course of development we found it necessary to migrate an old user setting into a new one and to then remove it. This brought with it a few problems which I hope to shed some light on below.

In order to get the value of the old setting we used the Property.Settings.GetPreviousVersion() method. Initially we were getting a SettingsPropertyNotFoundException() although the setting was verifiably present in the user.config file. As it turns out we had removed the Property from the Settings designer which removed the Property in the Property.Settings class. In order for Settings to be found, they have to have a property that is tagged with the [UserScopedSettingAttribute] attribute. This tells the GetPreviousVersion() method to look for the setting in user.config. So far so good…

At this point however, the base.Upgrade() method is called to move old settings into the new file. This causes the old, unwanted setting to be moved in right along with all the old settings that we want to keep around. In order to avoid this behavior the [NoSettingsVersionUpgrade] attribute must also be used for the unwanted Property.

public override void Upgrade()
{
string lastConfigFilePath = (string) GetPreviousVersion(”LastConfigFilePath”);
base.Upgrade(); // bring forward our properties that are the
// same (but also will bring forward LastConfigFilePath)
}

[UserScopedSettingAttribute]
[DebuggerNonUserCode]
[DefaultSettingValueAttribute(”")]
[Obsolete(”Please use MruConfigFilePaths instead”)]
[NoSettingsVersionUpgrade]
public string LastConfigFilePath
{
get
{
throw new NotSupportedException(”LastConfigFilePath is obsolete”);
}
set
{
throw new NotSupportedException(”LastConfigFilePath is obsolete”);
}
}

0 comments Read

An enchant provider for LIFT

Author admin | 13.05.2008 | Category Developers, WeSay

We wanted to allow users to edit their dictionary and use that same dictionary for spell checking. Since WeSay uses LIFT as the file format for the dictionary and keeps that file up to date, all we needed was an enchant provider that can read LIFT files.

I took the spell checking engine I had written a while back, Ascens, and refactored it so that it could read files of various formats. Currently it supports line based and XML based formats. For line based formats, the words are entered one per line. For XML based formats, an XPath expression determines what text from within the file should be selected to constitute correctly spelled words.

Ascens looks for a settings file with the same name as the language identifier that is passed to enchant. Within the settings file, the location of the dictionary and the type of the dictionary are specified. If the type is xml then the xpath expression should be defined.

The following is an example settings file for Ascens referring to a Lift file:

# This is the settings file for Ascens [Dictionary] # Type is either xml or line # for xml you also need to set the XPath #Type=line Type=xml

# path to the dictionary # (can be absolute or relative to the directory that this file is in) #Path=c:\documents and settings\user\my documents\dictionaries\fr_FR.dic #Path=fr_FR.dic Path=..\..\..\My Documents\WeSay\French\French.lift

# XPath gives the Xpath that selects the words to be used as dictionary # it must all be on a single line XPath=//entry[not(citation-form/form[@lang='fr'])]/lexical-unit/form[@lang='fr']/text | //entry/citation-form/form[@lang='fr']/text# this xpath selects the forms with the language id of 'fr' from the # citation form when there is one and from the lexical unit when # there is no citation form (it will not select both)

Enchant looks for user Ascens settings files in the following locations:

The ascens subdirectory of the value found in the registry at HKEY_CURRENT_USER\Software\Enchant\Config\Data_Dir, if there is one.
%APPDATA%\enchant\ascens, where %APPDATA% is shorthand for the C:\Users\<username>\AppData\Roaming\ folder (Windows Vista) or the C:\Documents and Settings\<username>\Application Data\ folder (Windows XP/2000).
The enchant\ascens subdirectory of the directory value found in the registry at HKEY_CURRENT_USER\Software\Enchant\Config\Home_Dir, if there is one.
%USERPROFILE%\enchant\ascens, where %USERPROFILE% is shorthand for the C:\Users\<username> folder (Windows Vista) or the C:\Documents and Settings\<username> folder (Windows XP/2000).

Enchant looks for shared Ascens settings files in the following locations:

Using the value found in the registry at HKEY_CURRENT_USER\Software\Enchant\ascens\Data_Dir, if there is one. Otherwise, using the value found in the registry at HKEY_LOCAL_MACHINE\Software\Enchant\ascens\Data_Dir, if there is one.
<enchant>\share\enchant\ascens, where <enchant> is the location of libenchant.dll.

0 comments Read

WeSay Tests on Mono Status

Author admin | 22.04.2008 | Category Developers, WeSay

One step toward getting WeSay to run on the OLPC is to verify that it can run with Mono. We already reported all the System.Windows.Forms bugs that we could find by running MWF on Windows as documented here. The next step has been to run all the tests under Mono. As you can see from the diagram (that actually lives on our whiteboard) at left, we have found and fixed and reported quite a few bugs that have made the number of failing tests plummet. We’re still not there yet, but I’m making good progress.