I wrote a money class on Pharo 1.x a few years back. Didn't use it beyond simple calculations as my financial computing needs are met using a spreadsheet-and-wiki combo. I've now reached the limits of that approach so looking to restart my business/finance-oriented programming with Pharo.
Here are other money-related implementations for Pharo/Squeak that I found:
Money - "The money package from Squeaksource. Originally from Smalltalk Best Practice Patterns." Most recent commit in Apr 2016. Installs cleanly on Pharo 5. 10 of 11 tests pass. The failed test looks like a minor bug. Older versions exist on Squeaksource.
Aconcagua-Money - "Aconcagua units for common domains - Time, Money, and Weight at the time of this writing." Most recent commit in May 2015. Installs cleanly on Pharo 5 with Aconcagua already installed. Has no test. Presumably relies on Aconcagua's own tests, as the classes are small and look simple.
FixedDecimal - "A FixedDecimal is similar to a ScaledDecimal, but different in certain select ways. It's (sic) primary purpose was to be able to represent precise decimals for such things as representing money - where ScaledDecimals leave something to be desired. [...] Forked from http://www.squeaksource.com/FixedDecimal.html Credits to Chris Cunningham." Most recent commit in Dec 2013. 11 of 12 tests pass. My money class uses FixedDecimal.
ScaledDecimal - Part of the image.
SmallPOS - "Framework for fast building of accounting, trading (including Points of Service), CRM and so on software. Based on GLORP, Magritte and Seaside." Contains a class CMACurrency.
From Kent Beck, here, "Re: Money in particular, I have implemented this one five times. The only intersection of the five implementations is a Money object whose amount is some kind of number, and which has a currency. Everything else is different. [...] Therefore, I carry around in my head a pattern language for creating Money and I reimplement it every time from scratch."
I've migrated this site to Pharo 5 from Pharo 3. One notable behind-the-scene change is that content is now deployed using Fossil, the "simple, high-reliability, distributed software configuration management system". Fossil is usually compared with DVCS such as Git and Mercurial.
This server runs the published version of this site. (Of course.) The development version is on my laptop. Now, when I wish to publish changes from my development version, say, when I have written a new blog post, I 'fossil commit', then 'fossil push', whereupon the new blog post and associated artefacts such as images are deployed into the published version on this server.
There are any number of articles on the web describing using Git hooks to automate deploying web content. In this post, I describe using Fossil to do the same. Some familiarity with Fossil is assumed.
To begin, build Fossil with TH1 hooks and Tcl integration. Deploy it both locally and on the server, by copying the single Fossil executable to appropriate directories.
Create a new repostory locally. Take note of the admin user ID and generated password. Let's assume that the admin user ID is 'laptop-user'. Be aware that Fossil has its own user IDs, passwords and roles, distinct from the underlying operating system's.
Check out the repository locally:
Add new content:
Upon commit, the repository, ~/repo/webtree.fossil, is updated. Note that the repository is a single file that can be copied, renamed, moved to other computers, etc. Let's scp it to our server and set up the following directory structure there. Here I use /x to keep path names short for this post.
To populate /x/webtree:
The file .fslckout is Fossil's checkout database.
Create the shell script /x/bin/fossilupdate:
Run the Fossil server. Here I use port 8081.
With your web browser, navigate to the Fossil server and login using the admin user ID and password you noted down earlier. Go to Admin > Settings. Disable autosync, enable tcl, enable th1-hooks, and click 'Apply Changes'. Go to Admin > Transfers > Push. Enter below command into the text box and click 'Apply Changes'.
This sets up the Fossil transfer hook, which will fire after your Fossil server processes a 'fossil push' request.
Back on the laptop, commit another file:
The push from the laptop will trigger the abovementioned transfer hook configured in the server's Fossil server instance, which will update /x/webtree on the server. Viola!
Automatically starting the Fossil server
It is often desirable to start the Fossil server automatically upon server startup. On my server, I use daemontools. However, for some reason daemontools' setuidgid program is unable to run 'fossil server' in the correct directory. So I use Ubuntu's start-stop-daemon instead, and this is the daemontools run file:
Create a new user, say, 'cms', and set up ownership of /x:
Link /x/repo into daemontools, and 'fossil server' runs as the 'cms' user in /x/webtree.
/x/webtree/.fslckout is Fossil's checkout database. If your web server serves content directly from /x/webtree, you should configure it to not serve the .fslckout file.
An alternate practice (according to those Git hook articles) is to rsync the content of /x/webtree to another directory, and it is this second directory that the web server reads from. In such a case, it is still necessary to avoid rsync'ing the .fslckout file.
Users in Fossil
As mentioned, Fossil maintains its own user IDs, passwords, and roles. In this post, I assumed that the Fossil admin user is called 'laptop-user' and used it for 'fossil push'. It is preferable to set up a separate lower privileged Fossil user and use that instead.
I'm pleased to announce the release of Glorp-SQLite3 for Pharo 5.
Developed and tested on Linux. Known working on Windows 7. Your Pharo 5 VM needs to be able to find libsqlite3.so or the Windows equivalent.
Take a fresh Pharo 5 image. Run the following:
Run the Glorp tests in TestRunner. All tests should pass, with 12 tests skipped. The database file is sodbxtestu.db in your image directory.
SQLite 3.9.0, released in Oct 2015, introduced the json1 extension that provides functions to manage JSON content stored in an SQLite database. The extension source code is included in the SQLite source amalgamation and is enabled by the -DSQLITE_ENABLE_JSON1 option.
The following assumes that the json1 functionality is available. As sample data, I use the stocks data set from jsonstudio.com. Here's what the wrapped first line of the JSON data file looks like partially:
To load the file into an SQLite database using NBSQLite3:
Note the invocation of the json() SQL function, which verifies that its argument is a valid JSON string and returns a minified version of that JSON string.
Let's inspect the created database with the sqlite3 shell tool:
The json_extract(X, P1, P2, ...) function extracts and returns one or more values from the JSON structure X:
The json_each() table-valued function walks the JSON value provided as its argument and returns one row for each element. The schema for the table returned by json_each() is as follows:
Here's json_each() in action:
Let's run the same query in Pharo:
Transcript displays thusly. As we can see, SQLite and NBSQLite3 handle numerical values in the JSON data properly.
Notice that the first row is well-formed JSON. If we use json_tree() instead of json_row(), that JSON structure will be returned as a key/value row as well.
Finally, let's read the first JSON record using NeoJSON:
This is powerful stuff. Well worth a look.