Dolphin 5.1 Patch Level 1 Release

Folks,

We've now released a Live Update patch for Dolphin Smalltalk XP 5.1. This
contains some fixes for a small number of bugs that were present in the
original 5.1 release. Most of these issues have been discussed in recent
posts to the newsgroup but you can view the full list of updates here:

http://www.object-arts.com/Lib/Update/Dolphin/5.1/Professional/PL1.htm

The patch is a free update that can be applied to your current image using
the Live Update facility available from the icon of the same name in the
Dolphin system folder. We recommend that you apply the update to a fresh
image (which you can then save and backup for future use) before installing
your own development packages. Note that there is no need to download a
complete new installer from the website since these files have not been
changed.

Once again, thank you for your continued support of Dolphin Smalltalk.

Best Regards,

Andy Bower
Object Arts Ltd.
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

The new version is a free update to existing Dolphin 5.0 users and can be
installed using your current version 5 serial number. Trial users may also
upgrade to 5.1 for the remainder of their trial period. If you wish, the new
version can also co-exist alongside previous installations. This may be of
use if you need to continue to run with an earlier system for whatever
reason.

Downloads are available from our software library at:

http://www.object-arts.com/Downloads5.htm

Thanks to everyone who tested the 5.1 Release Candidate software and
provided feedback. If you have any of the Release Candidates on your machine
you should uninstall them first before installing the final 5.1 release
version.

Thank you for your continued support of Dolphin Smalltalk.

Best Regards,

Andy Bower
Object Arts Ltd.
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Hi...

hum, was there a problem putting
defect #1260 "Prepared statements give Error 3700 using SQL Server 2000"
in this Patchlevel (or is it just missing from the description page)?

If the missing DBConnection>>views method were also added it would let me
delete my "Database Fixes" package altogether :-).

Ciao

...Jochen

"Andy Bower" <[hidden email]> wrote in message
news:3edb3e01$[hidden email]...
> We've now released a Live Update patch for Dolphin Smalltalk XP 5.1. This
> contains some fixes for a small number of bugs that were present in the
> original 5.1 release. Most of these issues have been discussed in recent
> posts to the newsgroup but you can view the full list of updates here:

It seems 'Pause' has gone missing from the VirtualKeys class variable of
Keyboard.  I get the following walkback when I try to open a new class
browser after the live update.  I believe that I only experiance this
because I use Tools+, which uses the 'Pause' key.  What I find slightly
puzzling is that the 'Pause' number seems to have changed a bit in various
Dolphin versions.  Pause = 19 in Dolphin 5.0.x, but Pause = 144 in a D5.1
virgin image, however it is 19 again in my working Dolphin image, then PL1
removes it.

1:12:24 PM, 6/2/2003: 'Unrecognised virtual key: ''Pause'''
Keyboard class(Object)>>error:
[] in Keyboard class>>virtualKey:
LookupTable>>at:ifAbsent:
Keyboard class>>virtualKey:
AcceleratorTable class>>keyCodeFromString:
CommandDescription>>acceleratorKeyString:
[] in ClassBrowserShell(Shell)>>registerAdditionalAccelerators
OrderedCollection>>do:
ClassBrowserShell(Shell)>>registerAdditionalAccelerators
ClassBrowserShell(Shell)>>onViewOpened
....

Anyone using Tools+ may want to hold off on this patch, or get around the
problem by adding 'Pause' back after the patch is applied.  Whatever you do
make sure you can open new class browsers before you snapshot your image.

Chris

"Jochen Riekhof" <[hidden email]> wrote in message
news:[hidden email]...
> Hi...
>
> hum, was there a problem putting
> defect #1260 "Prepared statements give Error 3700 using SQL Server 2000"
> in this Patchlevel (or is it just missing from the description page)?

Yes, there is a bug in #paramInputOutputTypeAt:default: that was spotted by
inspection. Also we didn't have time to define tests for the change, since
we wanted to get the patch level out quickly to fix a couple of high
priority issues.

>
> If the missing DBConnection>>views method were also added it would let me
> delete my "Database Fixes" package altogether :-).

That eluded our bug system, so I'll record it for the next patch. It is
likely that we will release smaller patch levels more often in future.

A plea: When submitting code for inclusion we encourage people to include
SUnit tests, as this reduces the amount of work we have to do to incorporate
the patch. Frankly it is often the case that writing the tests for a patch
takes several times as long as writing the patch itself. For a third party
submission we also need to add the time to understand the purpose and scope
of the code before we can write the tests. If code is submitted with tests,
then it will be more difficult for us to find an excuse for not including it
in the next patch :-)

Regards

Blair

"Christopher J. Demers" <[hidden email]> wrote in
message news:bbg2jg$90s24$[hidden email]...
> "Andy Bower" <[hidden email]> wrote in message
> news:3edb3e01$[hidden email]...
> > We've now released a Live Update patch for Dolphin Smalltalk XP 5.1.
This
Sorry about that, but you've hit on the reason for its removal. The old
table included quite a lot of incorrect values, and indeed the precise
content of the table sometimes varied depending on which machines (and, more
importantly, OS) was used to bootstrap the image. For example the names of
the numeric pad keys vary between Win98 and WinXP. The purpose of this table
is to provide a consistent set of English names that can be used in code to
map between a unique, readable, key name and the corresponding numeric key
code. Where there were ambiguities in map generated by the old code (the
cause of the virtual key codes being incorrect for the numeric pad keys in
fact) these were either resolved, or were excluded from the map if they
either varied depending on keyboard layout, or were considered to be
"system" keys that wouldn't be used as accelerators. 'Pause' (and
Scrolllock, etc) fitted into this latter category, most of which can't be
entered into a HotKey control (AcceleratorPresenter), or don't display
anything when entered (as in the case of Pause).

We'll restore it in the next PL, but first we need to determine the correct
value:
1) VK_PAUSE is defined as 19 in WinUser.h, but...
2) 'Keyboard keyNameFromVKey: 19' ==> Error 'invalid virtual key' (because
the Win32 API function MapVirtualKey() returns 0 to indicate that there is
no scan code for that virtual key).
3) 'Keyboard keyNameFromVKey: 144' ==> 'Pause'.
4) 144 is the code for VK_NUMLOCK as defined in WinUser.h !

There's certainly something odd going on there :-). Anyway the correct value
does seem to be that defined in WinUser.h, even if the system APIs have a
problem with it, so:

(Keyboard classPool at: 'VirtualKeys') at: 'PAUSE' put: (Win32Constants at:
'VK_PAUSE' put: 19)

Regards

Blair

> Yes, there is a bug in #paramInputOutputTypeAt:default: that was spotted
by
> inspection. Also we didn't have time to define tests for the change, since
> we wanted to get the patch level out quickly to fix a couple of high
> priority issues.

Huh, its pretty short?!

> A plea: When submitting code for inclusion we encourage people to include
> SUnit tests, as this reduces the amount of work we have to do to
incorporate
> the patch. Frankly it is often the case that writing the tests for a patch
> takes several times as long as writing the patch itself. For a third party
> submission we also need to add the time to understand the purpose and
scope
> of the code before we can write the tests. If code is submitted with
tests,
> then it will be more difficult for us to find an excuse for not including
it
> in the next patch :-)

Sound like an interesting idea :-)

Ciao

...Jochen

"Jochen Riekhof" <[hidden email]> wrote in message
news:[hidden email]...
> > Yes, there is a bug in #paramInputOutputTypeAt:default: that was spotted
> by
> > inspection. Also we didn't have time to define tests for the change,
since
> > we wanted to get the patch level out quickly to fix a couple of high
> > priority issues.
>
> Huh, its pretty short?!

You should be able to spot it easily then :-). A clue is that
Dictionary(IdentityDictionary)>>at: raises an exception if the key is not
found, it doesn't return nil.

Of course it is easily fixed, but the point is that it needs testing against
SQL Server and other DBs.

Regards

Blair

Blair McGlashan wrote:
Bravo! I wish more vendors would issue such a statement - and I wish
more developers would take it to heart.

--
--
Joseph Pelrine [ | ]
MetaProg GmbH
Email: [hidden email]
Web:   http://www.metaprog.com

"If you don't live on the edge, you're taking up too much space" -
Doug Robinson


--
--
Joseph Pelrine [ | ]
MetaProg GmbH
Email: [hidden email]
Web:   http://www.metaprog.com

"If you don't live on the edge, you're taking up too much space" -
Doug Robinson

> Dictionary(IdentityDictionary)>>at: raises an exception if the key is not
> found, it doesn't return nil.

Uh, I frequently fail on this one as it behaves differently from Java that I
have to use 95% of the time.
Well, actually the ST behaviour (of at:ifAbsent:) makes the code even
simpler .

However, I have to say that the posted code was meant as an example, I never
expected it
to be used as is in a patchlevel (but I like the idea that  you plan to use
the solution :-).

What I still am surprised about is that the hardcoded INOUT parameter was in
for such a long time. There is some performance difference to have any OUT
parameter or none, so the "big" databases are usually quite picky about it.

Ciao

...Jochen

Blair McGlashan wrote:
> A plea: When submitting code for inclusion we encourage people to
> include SUnit tests, as this reduces the amount of work we have to do
> to incorporate the patch. Frankly it is often the case that writing
> the tests for a patch takes several times as long as writing the
> patch itself.

Hi Blair,

If it is not confidential, could you provide some information on the
TestCases and testing approaches you use for Dolphin? Any information would
be interesting, but some specific questions:

 - What is the coverage of your tests? Which parts of the image have
less/more coverage than average?

 - Do you have tests for the ToolShells, like the CHB and SystemBrowser? If
so, how do you setup these tests?

 - Do you have tests for the Dolphin MVP package? and if so, do you use Mock
objects?

 - Are there any parts of the system where you make use of Mock objects?

 - Is a class like ImageStripper tested? If so, how?

Any info you can share is appreciated,
Thanks,
Steve

--
Steve Waring
Email: [hidden email]
Journal: http://www.stevewaring.net/blog/home/index.html

Steve

You wrote in message news:bbr8gq$cdeio$[hidden email]...
>
> If it is not confidential, could you provide some information on the
> TestCases and testing approaches you use for Dolphin? Any information
would
> be interesting, but some specific questions:
>
>  - What is the coverage of your tests? Which parts of the image have
> less/more coverage than average?

The coverage of our SUnit tests is patchy. Excluding the RB tests, etc, we
currently have somewhat over 1700 test methods spread through 84 TestCase
classes. Many of the test methods contain a substantial number of individual
tests - a typical approach is to have a TestCase associated with each class,
and then a test method per method. We have quite a lot of re-use in our
tests, so for example we have an abstract SequenceableCollectionTest class,
and below that test classes for the concrete subclasses of
SequenceableCollection. Some of these subclasses, such as ArrayTest,
currently contain only a single method that answers the class of collection
being tested, Array in this case. Some of the tests are higher level, and
test some function or operation.

I haven't analysed it but I would guess that the tests for core classes tend
to be of the "TestCase per class with test method per method" sort, and
those for presenters, tools, etc, tend to be broken down on more functional
lines.

Anyway we know that we have way under the actual number of tests needed to
give good coverage of the whole image - we didn't start using SUnit with any
rigour until fairly late in the D5 development cycle. Our policy now is to
add tests when doing new work, when refactoring an older subsystem, or to
reproduce a reported bug. As a result of this policy (and history), the
older
and more stable parts of the image, especially the core classes, are only
sparsely covered, whereas some more recent additions have comprehensive
tests.

Actually I have high hopes for the Camp Smalltalk ANSI compatibility test
suite providing a useful core set of tests for the base classes, but as far
as I can tell it has been published only informally and I'm not sure I've
been able to find the latest version. The one I do have doesn't load without
some fiddling, and it is clearly a work in progress. Until this work is
published in a known state, e.g. from SourceForge, it isn't likely to move
forward much between CS events. Certainly I'd like to contribute to it.

>
>  - Do you have tests for the ToolShells, like the CHB and SystemBrowser?
If
> so, how do you setup these tests?

Yes, we do. The tool tests themselves are not that comprehensive, but we do
have pretty comprehensive tests for a number of the components used within
the browsers such as class and package selectors, and the published aspect
inspector. Actually it was only by writing a comprehensive set of tests for
the PAI that we were able to get it to work satisfactorily, as the
interactions within it are very complex and we found that fixing one issue
created (or recreated another). D5 beta testers may remember how unstable
the PAI was in the first couple of beta releases.

As in the VP tests (see below) we use setUp/tearDown to create/destroy the
component or tool which we store in an instance variable of the test case.
We use TestResources to hold test classes, packages, etc, that we create and
manipulate as part of the tests. In the case of a tool test such as that for
PackageBrowserShell, the majority of the tests revolve around asserting that
the various tabs remain up to date as classes, methods, resources, etc are
added, renamed, moved and deleted from the system. The various common
components used by the package browser are tested separately.

We haven't historically been very good at SUnit testing correct command
enablement/disablement (i.e. the queryCommand method), relying instead on
manual testing of the UI. This is probably why we get a relatively high
number of bug reports relating to commands being incorrectly enabled!

>
>  - Do you have tests for the Dolphin MVP package?

Yes, we have reasonably good coverage there now, especially for the
"selectable item" presenters and views.

>...and if so, do you use Mock objects?

We do not use Mock objects, but drive the actual views directly (or
indirectly through the Presenter/Model). The views typically have sufficient
capability to assert that the end result of some operation (as it affects
the view) is correct, with the exception of the actual visual appearance,
i.e. we can test that the view should be displaying correctly, but not that
it actually has painted itself correctly. Since the views we are driving are
mostly external controls we make the basic assumption that they take care of
the correctly rendering themselves onto the actual display medium. Even if
we were able to test this we probably wouldn't since we don't really regard
it as our reponsibility to undertake comprehensive testing of the external
controls themselves, especially since we can't actually fix them. An
exception to this is where bugs are reported that are determined to be due
to issues in the external controls and we develop a workaround. We will
usually try to have a test that shows the workaround is working correctly,
if at all possible.

Even in the case of custom views rendered in Smalltalk, such as the
MoenTreeView (the luck owner of two test classes), our tests assert that the
internal data structures are correctly maintained, and we have to rely on
observation to check that it displays correctly.

A typical view or presenter test will have an instance variable for the
view/presenter being tested, with the window being opened during #setUp, and
closed in #tearDown. This arrangement avoids leaving behind loads of old
test views from debugging sessions, without the need to sprinkle #ensure:
blocks in the test methods themselves.

A very important aspect of testing the MVP system (and the component
presenters we use to assemble our tools) is the testing of events, for which
we use our own SUnit extensions that ship in the image.

In summary I can see no particular advantage of using Mock objects to test
MVP, since its component based nature makes it pretty amenable to testing as
it stands. I'd be interested in any contrary views of course.

>
>  - Are there any parts of the system where you make use of Mock objects?

Nope.

>
>  - Is a class like ImageStripper tested? If so, how?

Not using SUnit. We have to fall back on manual testing for that at present,
which is time consuming, error prone, and generally unsatisfactory. I've had
some thoughts about how we could script it with SUnit (since the image is
saved before deployment, it is possible to kick off something that continues
on image restart after deployment). In D6 we have an XML manifest generated
by the deployment process that details the complete contents of the deployed
application, and this could form the basis of a set of automatic regression
tests.

I think if we were building Lagoon again, we would have it work on a model
of the system. This would have a lot of advantages, not the least of which
would be the ability to test it with SUnit.

Regards

Blair

Hi Blair,

Thanks for the informative reply.

<big snip>

>> ...and if so, do you use Mock objects?
>
> We do not use Mock objects, but drive the actual views directly (or
> indirectly through the Presenter/Model). The views typically have
> sufficient capability to assert that the end result of some operation
> (as it affects the view) is correct, with the exception of the actual
> visual appearance, i.e. we can test that the view should be
> displaying correctly, but not that it actually has painted itself
> correctly.

Creating and showing views from my test cases is something that I have
avoided. I think I have had a preconception that this was not a good
practice. I was considering writing some mock view classes in order to test
presenter-model interactions, but whenever possible I do try to avoid the
use of mock objects as I find the tests that use them to not be as resilient
to changes in the code.

Setting up a complete MVP and testing it would be a stronger test, and
require much less work than writing and maintaining mock view classes.

> A very important aspect of testing the MVP system (and the component
> presenters we use to assemble our tools) is the testing of events,
> for which we use our own SUnit extensions that ship in the image.

Thank you for these extensions, I have found them handy for testing events
triggered from models.

> In summary I can see no particular advantage of using Mock objects to
> test MVP, since its component based nature makes it pretty amenable
> to testing as it stands. I'd be interested in any contrary views of
> course.

No, I have just had a mental block against doing this. Time to start writing
some tests and see some views flashing open and close!

Thanks,
Steve

--
Steve Waring
Email: [hidden email]
Journal: http://www.stevewaring.net/blog/home/index.html