Planet Squeak

Torsten Bergmann: A cave built in Smalltalk

Torsten (noreply@blogger.com) — Fri, 03 Feb 2012 12:17:04 +0000

LShift Ltd.: “Duck-finding” for testing your Theories

Frank Shearar — Tue, 31 Jan 2012 12:44:53 +0000

A while ago I wrote a semi-port of Haskell’s QuickCheck. Easy enough - a property is like a test method but with arity 1, into which you inject data - potential counterexamples to your theory. In Haskell, the type system can, through unification, figure out the type of the generator required for that property. What to do in a dynamic language?

There are a number of type inference techniques for dynamic languages - k-CFA, demand-driven type inferencing with subgoal pruning, RoelTyper. I’m going to use a very simple technique.

First, some terminology. In Smalltalk, “protocol” usually means one of two things: either “what messages does this object understand?” or “does this object understand the Foo protocol?”, where Foo might be “Stream”, or “Collection”. We’re going to use the latter meaning. In particular, given a JUnit-like theory, we want an answer to the question “What objects - what instances of what classes - satisfy the protocol sent to the datum injected into this theory?”

With a decompiler to hand, it’s easy enough to generate an AST of the theory over which we can walk: walk the MessageNodes and look for things with a receiver 't1' which will be the name given to the first temporary variable, i.e., the argument of the unary method. This won’t work for anything hidden through a #perform: - think of this as the eval of Smalltalk code.

    ParseNodeVisitor subclass: #SenderToArgCollector
    instanceVariableNames: 'selectors classSelectors'
    classVariableNames: ''
    poolDictionaries: ''
    category: 'SqueakCheck-SUnit'

    visitMethodNode: aMethodNode
        classSelectors := Set new.
        selectors := Set new.
        ^ super visitMethodNode: aMethodNode.

    visitMessageNode: aMessageNode
        (aMessageNode receiver name = 't1')
            ifTrue: [selectors add: aMessageNode selector key].
        (aMessageNode receiver isMessageNode
            and: [aMessageNode receiver selector key = #class]
            and: [aMessageNode receiver receiver name = 't1'])
            ifTrue: [classSelectors add: aMessageNode selector key].
        ^ super visitMessageNode: aMessageNode.

    selectors
        ^ selectors.

    classSelectors
        ^ classSelectors.

and invoked by our TheoryTyper (which could be called a DuckFinder…)

    messagesSentToDatum: aUnaryCompiledMethod
    "Answer a pair of Sets of all the message selectors sent by this method to its argument.
    The first Set contains messages sent to the argument, and the second contains messages
    sent to the argument's class."
    | collector |
    collector := SenderToArgCollector new
        visitMethodNode: (Decompiler new
            decompile: aUnaryCompiledMethod selector
            in: aUnaryCompiledMethod methodClass).

    ^ {collector selectors. collector classSelectors}.

Let’s try out our new toy. To recap, we wish to write a theory and have the system automatically find the right types of things to test the theory. So let’s try the “monadic laws”:

    Object subclass: #TheoryTyper
    instanceVariableNames: ''
    classVariableNames: ''
    poolDictionaries: ''
    category: 'SqueakCheck-SUnit'

    monadsObeyLeftIdentity: m

    self
        assert: (m class return: m value) >>= [:t | m class return: t]
        equals: ([:t | m class return: t] value: m value)

    monadsObeyRightIdentity: m

        self assert: m equals: (m >>= [:a | m class return: a])

And lo! our duck-finder says, with the Maybe and Either monads loaded:

    TheoryTyper new typeOfDatum: (MonadTheories >> #monadsObeyLeftIdentity:)
    "=> a Set(Maybe Either)"

The keen-eyed will notice a law missing from the above - the associativity law for monads. Given monadic blocks f and g - that is, unary blocks that take some value and return a value wrapped up in whatever monad you’re using - we can express this law as

    monadsObeyAssociativity: m
    | f g |

    self
        assert: ((m >>= f) >>= g)
        equals: (m >>= [:x | (f value: x) >>= g])

but from where do we get f and g? Our naive duck-finding fails: we would need to extend our “type inference”. One possible (and fairly ugly) solution is to make m’s class responsible through helpers: add sampleBlockF and sampleBlockG messages to the protocol and we could write:

    monadsObeyAssociativity: m
    | f g |

    f := m class sampleBlockF.
    g := m class sampleBlockG.
    self
        assert: ((m >>= f) >>= g)
        equals: (m >>= [:x | (f value: x) >>= g])

Also, typing m is a bit harder than in the previous examples:

    TheoryTyper new typeOfDatum:
        (MonadTheories >> #monadsObeyAssociativity:)
    "=> a Set(Either Nothing Maybe Left Right Just)"

because all we have to work with is the send of #>>=. Arguably it would be clearer to return a Set(Either Maybe) because the other classes are subclasses of these two.

However, despite the limitations of this technique, one can express theories in a nicely modular way. The monadic laws will simply run against any monadic classes (that is, any classes that understand #>>= on the instance side and return: on the class side) present in the image.

Torsten Bergmann: Smalltalk and Git

Torsten (noreply@blogger.com) — Tue, 31 Jan 2012 06:29:15 +0000

Want to use Git versioning system with Smalltalk code? Then read more here.

Pharo News Blog: Zodiac Alpha Release 2012-01-26

board (board@pharo-project.org) — Sun, 29 Jan 2012 15:26:45 +0000

Sven Van Caekenberghe announced an alpha release of Zodiac, an open-source, cross-smalltalk implementation of regular and secure socket streams.

Features:
- ZnSecureSocketStream
- HTTPS client access
- HTTPS server (not on Mac OS X though)
- ZdcSecureSMTPClient
- ZdcSecurePOP3Client

Read the announcement here.

Torsten Bergmann: Pharo sprint in Brussels

Torsten (noreply@blogger.com) — Fri, 27 Jan 2012 16:28:02 +0000

There is a Pharo sprint in Brussels on Feb 4th. Read more.

Pharo News Blog: Pharo Sprints in February

board (board@pharo-project.org) — Fri, 27 Jan 2012 14:35:35 +0000

There will be two sprints in February

1) Brussels on Feb 4th: Link...

2) Bern on Feb 18. (with moose dojo Feb 19): Link...

Pharo News Blog: Moving debuggers between images with Fuel

board (board@pharo-project.org) — Mon, 23 Jan 2012 13:51:57 +0000

Mariano writes: ... and suddenly I thought: “What happens if I try to serialize a living debugger and materialize it in another image?” After 5 minutes, really, you will see it takes only 5 minutes, I notice that such crazy idea was working OUT OF THE BOX.

read more...

Squeak Oversight Board: Squeak Oversight Board minutes – 01/17/12

smalltalktelevision — Wed, 18 Jan 2012 16:02:57 +0000

Squeak Oversight Board minutes – 01/17/12

Attending: Chris Muller, Colin Putney, Levente Uzonyi, Chris Cunnington

it was agreed that was nice to see Eliot exploring the SqueakCore image, as we hope this is a direction the community will take up
a long conversation was had about how to distribute the next version of OmniBrowser, as existing tools don’t seem quite right
a long Installer script could be written, but that meant every version would have its own, and managing them would be a nuisance
Metacello was seen as good, but that it would be better if the metadata/dependency info could be accessible; so you could ask questions of the metadata
the difference between the needs of users and developers was raised
the next OmniBrowser will have around 30 packages to co-ordinate and likely more
Colin’s working on a DSL and tool to manage the task for his own personal use: a tool that reads a spec and creates an Installer script
Levente suggested a tool to read a Metacello configuration to make a spec to feed into Colin’s tool and then produce an Installer script
it was mentioned that a build server factors into these problems and could assist the process

LShift Ltd.: Unifying parts of structures

Frank Shearar — Mon, 16 Jan 2012 22:05:59 +0000

Those with even a passing familiarity with Prolog should recognise statements like [H|T] = [1,2,3]. In particular, = here is not “is equal to” but rather “unifies with”. So that statement causes the variable H to unify with 1, and T with the rest of the list, [2, 3].

Clojure’s abstract bindings provide much the same capability - (let [[h & t] ‘(1 2 3)] <do stuff>) - modulo the difference between pattern matching and unification, of course.

There’s a subtlety in something like [H|T] = [1,2,3], at least, if your lists aren’t built of nested cons cells. Consider Smalltalk arrays. Suppose we have some ListUnifier that will rip a SequenceableCollection’s head off, like #(1 2 3). We’d like the tail to unify with #(2 3) in other words. But that’s not a node in the original structure - it’s an entirely artificial node we wish to construct from the original collection. Firstly, how can we unify with only part of a structure and, secondly, how can we determine a solution from that partition?

Let’s try model the parts:

    DestructuringUnifier subclass: #ListUnifier
        instanceVariableNames: 'head tail'
        classVariableNames: ''
        poolDictionaries: ''
        category: 'Unification-Destructuring'.

    ListUnifier >> head: anObject tail: anotherObject
        head := anObject.
        tail := anotherObject.

    ListUnifier class >> headNamed: headSymbol tailNamed: tailSymbol
        ^ self new head: headSymbol asVariable tail: tailSymbol asVariable.

    "Various helper constructors like #head:tailNamed:, #head:tail:, etc.
     elided for brevity."

Then we can write the original Prolog statement as

    (ListUnifier headNamed: #x tailNamed: #y) =? #(1 2 3)

As mentioned above, first we want to be able to construct an equivalence relation on the above (or, expressed differently, partition the set of nodes in the structure together with the artificial nodes we create) such that #x asVariable and 1 are in the same class, and ditto for #y asVariable and #(2 3).

    unificationClosureWith: anObject in: termRelation
        | h t partition |
        anObject isMetaVariable
            ifTrue: [^ termRelation union: self with: anObject].
        anObject isCollection
            ifFalse: [^ self failToUnifyWith: anObject].
        anObject isEmpty
            ifTrue: [^ self failToUnifyWith: anObject].

        h := head isCollection
            ifTrue: [anObject first: head size]
            ifFalse: [1].
        t := head isCollection
            ifTrue: [anObject allButFirst: head size]
            ifFalse: [anObject allButFirst].
        partition := head unificationClosureWith: h in: termRelation.
    ^ tail unificationClosureWith: t in: partition.

The mild complication around head isCollection lets us support a head that is itself a collection. So let’s check that we can construct a partition using parts of things:

    | left right partition |
    left := (ListUnifier headNamed: #x tailNamed: #y).
    right := #(1 2 3).
    partition := VariableTrackingUnionFind
        usingArrayType: PersistentCollection
        partitioning: Dictionary new.
    partition := (partition find: left)
        unificationClosureWith: (partition find: right) in: partition.
    partition elementsOfClass: #x asVariable. "=> {1 . (#Variable #x)}"
    partition elementsOfClass: #y asVariable. "=> {#(2 3) . (#Variable #y)}"

We see that the partition that originally would only hold nodes in the structures may now hold parts of the original structure.

The original algorithm for determining the most general unifier from some partition as described in Baader & Snyder (pp. 461-462) runs the solution finder starting from the left operand in the unification. Consider the partition we have above. What elements are in the equivalence class of ListUnifier? Well, just the ListUnifier itself! Clearly we need to adjust the solution finder a bit. The obvious approach would be to start the solution-finding from an element in each class, and merge the partial solutions:

    findSolutionFor: aVariableAvoidingUnionFind
    ^ aVariableAvoidingUnionFind
        inject: MostGeneralUnifier new
        into: [:mgu :node |
            mgu addAll: (self new
                findSolutionFor: aVariableAvoidingUnionFind
                starting: node)]

where #addAll: merges the various MostGeneralUnifiers generated and #inject:into: folds over the representative node in each equivalence class. (Remember, a union-find always has a representative for each equivalence class, namely, myPartition find: someObject.) And it works, at the cost of turning a linear algorithm into a (worst case) quadratic one:

    | left right |
    left := (ListUnifier headNamed: #x tailNamed: #y).
    right := #(1 2 3).

    left =? right "=> MostGeneralUnifier((#Variable #x)->1 (#Variable #y)->#(2 3) )"

But “finding a solution” really means “to what must we assign each variable?”. So we can at least speed things up by only solution-finding in those classes in which variables occur:

    findSolutionFor2: aVariableAvoidingUnionFind
    ^ aVariableAvoidingUnionFind variableContainingClasses
        inject: MostGeneralUnifier new
        into: [:mgu :node |
            mgu addAll: (self new
                findSolutionFor: aVariableAvoidingUnionFind
                starting: node)]

This makes finding a solution O(NM), where N is the number of nodes in the structure, M the number of classes containing variables.

Torsten Bergmann: SqueakSource down

Torsten (noreply@blogger.com) — Mon, 16 Jan 2012 20:54:38 +0000

SqueakSource is often down, this time due to a network error.
But there is help by using a mirror.

Torsten Bergmann: DrGeo running on Pharo running on iPad

Torsten (noreply@blogger.com) — Mon, 16 Jan 2012 14:51:16 +0000

And DrGeo is running on Pharo - and Pharo is running on iPad. The result is shown here.

Torsten Bergmann: Scratch running on Pharo running on Android

Torsten (noreply@blogger.com) — Mon, 16 Jan 2012 14:48:42 +0000

So Scratch is running on Pharo - and Pharo is running on Android. The result is shown here.

Torsten Bergmann: Amber Smalltalk 0.9.1 is out!

Torsten (noreply@blogger.com) — Mon, 16 Jan 2012 14:40:59 +0000

Torsten Bergmann: Significance of 1.1.1753

Torsten (noreply@blogger.com) — Mon, 16 Jan 2012 14:11:42 +0000

When working in IT you often have "magic" numbers or dates. Remember the year 2000 bug (Y2K)?

One interesting date is is 1.1.1753 - which is a limit in SQL-Server. Interesting to know.

Sean DeNigris: Squeak VM: Compiling for Xcode

Sean DeNigris — Wed, 11 Jan 2012 17:17:32 +0000

When compiling the VM for Xcode, one has to switch back and forth from the image to the command line. To make things easier, here’s a little script that:

empties the build directory
generates the sources and cmake info
Configures with cmake
Opens the project in Xcode

First, load PipeableOSProcess via:

Gofer it
	squeaksource: 'MetacelloRepository';
	squeaksource: 'CommandShell';
	package: 'ConfigurationOfOSProcess';
	package: 'CommandShell-Piping';
	load.
(Smalltalk at: #ConfigurationOfOSProcess) load.

Then, execute this script (also available as a gist) whenever you want a fresh Xcode project:

PipeableOSProcess waitForCommand: '/usr/bin/osascript -e "tell application \"Xcode\" to quit"'.
 
buildDir := FileDirectory on: '/Developer/cogvm/cog/build/'.
buildDir entries do: [:e | e name = 'vmVersionInfo.h' ifFalse: [ 
		e isDirectory
			ifTrue: [ e asFileDirectory recursiveDelete ]
			ifFalse: [ e delete ] ] ].
 
StackCocoaIOSConfig new
  addExternalPlugins: #( FT2Plugin );
generateForDebug;
  generateSources; generate.
 
PipeableOSProcess waitForCommand: 'cd /Developer/cogvm/cog/build/; /opt/local/bin/cmake -G Xcode'.
PipeableOSProcess waitForCommand: 'open /Developer/cogvm/cog/build/StackVM.xcodeproj'.

Tweet This Post

Sean DeNigris: Programming Language Rankings

Sean DeNigris — Tue, 10 Jan 2012 18:31:58 +0000

The Tiobe index is total rubbish. But it’s worse than useless. It’s actually harmful. As Tyler Cowen mentioned in his TED Talk, “Be suspicious of stories”, feeling like you know what’s going on is way worse than admitting you don’t have a clue:

The most dangerous people are those that have been taught some financial literacy

Undoubtedly, there are people out there choosing careers and technologies based on the information age’s “divining by chicken bones”. Tiobe is based on search engine hits for goodness sake. In the uber-democratic-everyone’s-a-technical-blogger web, of what is “talking about a language” a good indicator? Here is a primary one: that the language and its tools are not sufficient to support development. In other words, the Niobe Index (i.e. search engine results) is inversely proportional to language quality, as seen below:

Since the equation above is obviously scientific (because it seems “mathy” and nerdy), it must be true. Furthermore (another great smart-people word), if one believes in (yes, like Santa Claus) the Niobe index (which can only be believed because it superficially seems scientific), one must believe my equation, which creates a paradox (another great science-y term).

In a live, open, dynamic environment (like Smalltalk*), the programmer has at their fingertips most of the things they would otherwise be force to search the internet for, which is succinctly described by Torsten Bergmann. Also, working in a low level language, like C++ (e.g. manual memory management), guarantees search engine love. I used to need a Safari Books membership just to make sure I didn’t shoot myself in the foot.

Torsten Bergmann: Smalltalk/X tour

Torsten (noreply@blogger.com) — Tue, 10 Jan 2012 14:59:43 +0000

There is now a "Guided tour on Smalltalk/X (Part 2) video available.

The Weekly Squeak: Finding More News About Squeak

Ron Teitelbaum — Mon, 09 Jan 2012 16:35:40 +0000

Need more news? If waiting for a blog post is not your thing, join the Google + Group.

https://plus.google.com/115950529692424242526/posts

Torsten Bergmann: Who needs the JVM - Tomcat on Smalltalk/X

Torsten (noreply@blogger.com) — Sun, 08 Jan 2012 18:50:15 +0000

The software engineering group from the czech university in Prague is running Tomcat on Smalltalk/X. So who needs the JVM? ;)

Torsten Bergmann: Impress.js

Torsten (noreply@blogger.com) — Wed, 04 Jan 2012 12:44:43 +0000

Somehow I like small JavaScripts for effects like these. code is here.

Squeak Oversight Board: SOB Minutes – 3 Jan.

smalltalktelevision — Tue, 03 Jan 2012 18:11:36 +0000

- The bulk of the meeting addressed a sudden change to DNS that has shut down our mailing lists

- The problem resulted from the domain squeakfoundation.org which made a change to its DNS configuration 2 Jan.

- After the problem is solved, the SOB is resolved to switch over to squeak.org and make squeakfoundation.org redundant to needs

- The relationship with the Software Freedom Conservancy was discussed in terms of who is a signatory for the Board. It seems the SFC is the signatory and not SOB memebers

- an important bug fix by Colin Putney will be incorporated into the release of Squeak 4.3

- Some final tasks related to the release of Squeak 4.3 were discussed: the creation of an All-In-One release; uploading a zipped version of that and a zipped SqueakCore image to http://ftp.squeak.org /4.3; and then linking from the homepage of squeak.org to that All-In-One app

LShift Ltd.: Translating a persistent union-find from ML to Smalltalk

Frank Shearar — Sat, 31 Dec 2011 23:24:35 +0000

When I wrote my unification library a while back, I tried to add an “or matcher”. That is, something that would allow

    | matcher mgu |
    matcher := OrUnifier
        left: (TreeNode left: #x asVariable)
        right: (TreeNode right: #x asVariable).

    mgu := matcher =? (TreeNode left: (Leaf value: 1)).
    mgu at: (#x asVariable) "=> (Leaf value: 1)".

    mgu := matcher =? (TreeNode right: (Leaf value: 1)).
    mgu at: (#x asVariable) "=> (Leaf value: 1)".

Easy enough… until one tries to use an OrUnifier as an operand on the right hand side. See, as the unification progresses, if the first option fails, you’d like to backtrack part of the equivalence relation calculation, and with the imperative union-find in Nutcracker that’s not possible. What to do, what to do?

The standard solution is to reach into one’s toolbox of functional data structures. Sadly, noone knows (as far as I can see, at least) how to implement a functional union-find. At least, not an efficient one. However, Conchon and Filliâtre tell us how to implement a persistent union-find.

The implementation - originally in ML - uses a persistent array to get its rollbackability. Further, it uses “rerooting”, a trick Henry Baker wrote up, to improve efficiency. I couldn’t improve on the pictures Conchon and Filliâtre use to illustrate rerooting, so I won’t try, and just point you to their artwork, pp. 18-27. The structure makes massive use of side effects, but presents an apparently purely function API. First, the basic data structure:

    type 'a t = 'a data ref
    and 'a data =
        | Arr of 'a array
        | Diff of int * 'a * 'a t

Note the ref there - it’s an updatable reference to something. Since everything’s mutable by default in Smaltalk, I tried ignoring the ref and just translate things. However, I quickly ran into difficulties. The “massive use of (hidden) side effects” quickly bit me (see section 4 of the paper), as I attempted to translate the following:

    let set t i v = match !t with
        | Arr a as n ->
            let old = a.(i) in
            a.(i) <- v
            let res = ref n in
            t := Diff (i, old, res);
            res
        | Diff _ ->
            ref (Diff (i, v, t))

It all looks quite simple. But look at t := Diff (i, old, res). Ignoring it at first, the obvious translation would be (ignoring noise like class declarations):

    Diff >> set: index to: anObject
        ^ Diff index: index value: v in: self

    Arr >> set: index to: anObject
        | old res ref |
        old := a at: i.
        a at: i put: v.
        res := self.
        self become: (Diff index: i value: v in: self)
        ^ self.

Did you feel a shiver there? #become: is deep Smalltalk magic. Its operation is simple enough: it swaps two object pointers. Here, we will change self to a new object. Oh, did I say “swap two object pointers”? I meant to say “swap two object pointers throughout the entire image”. Deep, dangerous magic indeed. And I thought, as I tried to figure out what was going on, that there had to be an easier way. What if I modelled the ref itself?

    Object subclass: #Ref
        instanceVariableNames: 'value'
        classVariableNames: ''
        poolDictionaries: ''
        category: 'PersistentUnionFind'.

    Ref class >> wrapping: anObject
        ^ self new wrapping: anObject.

    Ref >> value
        ^ value.

    Ref >> value: anObject
        value := anObject.

    Ref >> wrapping: anObject
        value := anObject.

Now you can have an immutable reference to something that, itself, may change to what it points. (Yes, that sounds a lot like “well done, you’ve invented a pointer!”) With that in hand, let’s hide the gory bits - Arr and Diff - behind a nice clean PersistentCollection interface:

    Ref subclass: #PersistentCollection
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: 'PersistentUnionFind'.

    PersistentCollection >> at: index put: anObject
        t := value. "The equivalent of !t"
        ^ t isDiff
            ifTrue: [Diff index: i value: anObject in: self]
            ifFalse: [ | old |
            old := t array at: index.
            t array at: index put: anObject.
                self value: (Diff index: i value: old in: self)]

which doesn’t look too bad, in comparison to the original!

The code’s published at SqueakSource, in the PersistentUnionFind package:

    Installer ss
      project: 'Nutcracker';
      install: 'PersistentUnionFind'.

Torsten Bergmann: A Mentoring Course on Smalltalk

Torsten (noreply@blogger.com) — Fri, 30 Dec 2011 07:47:23 +0000

The book "A Mentoring Course on Smalltalk" is available on Lulu.

Torsten Bergmann: Scripy

Torsten (noreply@blogger.com) — Thu, 29 Dec 2011 08:50:22 +0000

Scripy - a way to share Workspace scripts with others right from within you Smalltalk image. Read more at http://www.scripy.org

Randal Schwartz: Squeak 4.3 released / SOB minutes — 23 Dec. « The Squeak Oversight Board Blog

Tue, 27 Dec 2011 17:04:00 +0000

Welcome to the release of Squeak 4.3.

There aren’t any applications bundled with this release. Instead of working on applications to bundle with the image, core developers have been inspired by the Cog virtual machine to look deeply into the image for things they wanted to change. As a result, the image is becoming smaller, tidier, and nimbler.

via squeakboard.wordpress.com

Permalink | Leave a comment »

Torsten Bergmann: JavaFX and SWT

Torsten (noreply@blogger.com) — Tue, 27 Dec 2011 12:13:15 +0000

Cool: JavaFX integration with SWT. Something new to play with over the weekend!

Torsten Bergmann: Phoseydon Beta released

Torsten (noreply@blogger.com) — Tue, 27 Dec 2011 07:40:06 +0000

Phoseydon - a tool aimed to model and create applications easily in Smalltalk, as Ruby does with Rails or python with Django. You describe a model, and from that model a relational database plus an object model plus an ORM mapping are fed from that model.

Torsten Bergmann: Squeak 4.3.

Torsten (noreply@blogger.com) — Tue, 27 Dec 2011 07:27:55 +0000

Squeak 4.3. is available.

Torsten Bergmann: Teleplace gone

Torsten (noreply@blogger.com) — Tue, 27 Dec 2011 07:27:09 +0000

The company Teleplace is gone, the software (written in Squeak Smalltalk) is still available and continues to live.

Ben Coman: Windows 7 Pharo DBXTalk – “my hack”

Ben Coman — Sun, 25 Dec 2011 13:32:22 +0000

Having just got ConfigurationOfODBC working from Pharo Smalltalk, I had some trouble determining exactly how to get at the individual data items. So I thought I’d check out DBXTalk for comparison. DBXTalk is a lot more comprehensive solution leaveraging OpenDBX which includes its own ODBC interface along with several other backends. However all the ODBC connection examples I saw were for database servers with connection strings that were not of the “DSN” form that I think is required for Microsoft Access – so I ended up returning to ConfigurationOfODBC and resolving the issue above.

Yet I was most of the way through getting DBXTalk working, so I record my experience here for posterity. It is the “hack” version since to resolve library dependencies I simply copied everything next to virtual machine executable. I’ll look into resolving these more correctly later. So I…

Created a new folder Pharo-1.3-13315-cog2522-dbxtalk and into it:
a. Extracted the “Contents” folder only from Pharo-1.3-13315-OneClick.zip
b. Extracted all files from cogwin_r2522.zip
c. Updated croquet.ini file with: ImageFile=Contents\Resources\pharo.image
.
Ran croquet.exe and then:
World Menu > Monticello Browser.
.
From the Monticello Browser opened:
http://www.squeaksource.com/MetacelloRepository

and loaded:
ConfigurationOfOpenDBXDriver-GuillermoPolito.13
.
then from a Workspace executed:
(ConfigurationOfOpenDBXDriver project version: #’stable’) load.
.
From a Workspace found the required OpenDBX library to be 1.4.4 by executing:
OpenDBX currentOpenDBXVersion
.
Extracted all nine files from http://linuxnetworks.de/opendbx/download/opendbx-1.4.4_win32.zip into folder Pharo-1.3-13315-cog2522-dbxtalk
.
From a DBXTalk developer I asked which version of PostgreSQL to try, and the prompt response came back as 8.3. I installed the current version at this time (postgresql-8.3.17-1-windows.exe) choosing all the defaults.
.

Now possibly step 3 is made redundant by the following, but this post is a record of what I actually did.
.
In Monticello Browser I opened repository:
http://www.squeaksource.com/DBXTalk
.
then loaded:
ConfigurationOfGlorpDBX-GuillermoPolito.70
.
then in a Workspace I executed:
(ConfigurationOfGlorpDBX project version: #’stable’) load.
.
which left the following message in Transcript

IMPORTANT FOR GLORP AND OpenDBXDriver DRIVER
In order to run sucessfully Glorp tests you should need to change the database connection settings used by them. To do this, change the following methods:
-GlorpDatabaseLoginResource>>defaultPostgreSQLInternetLogin
-GlorpDatabaseLoginResource>>defaultPostgreSQLLocalLogin
-GlorpDatabaseLoginResource>>defaultPostgreSQLLoginForGlorpStore

After doing this all Glorps tests must be green.

Evaluated -> GlorpOpenDBXDriver >> postLoadGlorpDriverDBXTalkPharo

…finished 2.4

Looking at GlorpDatabaseLoginResource>>defaultPostgreSQLLocalLogin shows:

defaultPostgreSQLLocalLogin
“To set the default database login to PostgreSQL, execute the following statement.”
“self defaultPostgreSQLLocalLogin.”

^DefaultLogin := (Login new)
database: PostgreSQLPlatform new;
username: ‘sodbxtest’;
password: ‘sodbxtest’;
connectString: ’127.0.0.1:5432_sodbxtest’.

Now rather than changing these connection settings, for a first attempt I thought it might go easier the other way making the database match the tests, so…

From the Windows Start Menu ran pgAdminIII.
.
From pgAdminIII created a new user sodbxtest:
Servers > PostgreSQL 8.3 (localhost:5432) >Login Roles > New Login Role.
with the widest privileges possible.
.
From pgAdminIII created database sodbxtest:
Servers > PostgreSQL 8.3 (localhost:5432) > Databases >> New Database
Name=sodbxtest
Owner=sodbxtest
Privileges=ALL, Role Public
.
Then for later comparison I checked that the number of tables in this new database is zero: Servers > PostgreSQL 8.3 (localhost:5432) > Databases > sodbxtest > schemas > public > Tables
.
Now “the hack” (since I was in a rush and would have needed to log out and back in as Admin to adjust the search paths.)
.
In Pharo I ran some Glorp Tests and got an error “could not find libpq.dll.” After finding this file in folder PostgresSQL/8.3/libs, rather than properly resolving the lookup, the quick fix was copying everything from that folder next to the virtual machine in folder Pharo-1.3-13315-cog2522-dbxtalk. A subsequent error “could not find ssleay32.dll” was fixed similarly by copying the contents of folder PostgresSQL/8.3/bin next to the virtual machine.
.
Then in Pharo from World Menu > Test Runner all 823 tests for GlorpTests-Models, GlorpTests-Database & GlorpTest are successful.
.
In addition, if I recheck the number of tables noted in Step 14 and find there are now 75 tables – full of data.
.
Excluded from this are GlorpTests-DatabaseTypes, GlorpTests-Extras, GlorpOpenDBXDriverTests since they seem to cycle through testing databases that I don’t have installed – in particular OCI.dll for Oracle.

One small annoyance is that once a “missing OCI.dll” error occurs, it continues to occur even when the previously successful tests are rerun. This remains until reset by: GlorpDatabaseLoginResource defaultPostgreSQLLocalLogin.

So this is a good result and I’ll be glad to further DBXTalk later on. However for now, for my current requirements (a one-time one-way import from an mdb file into Pharo) I think that ConfigurationOfODBC is more suitable.