The log produced by running regression tests would benefit from including some details of the time taken to run each test, perhaps sorting the output by run time, and/or including only tests that individually run for more than 100mS (or some other threshold).

The test packages would also be better separated from other code and placed in separate folders. The
current folder structure makes it difficult to look for recent changes to just the tests. A parallel hierarchy
would be best for this purpose.

The 'Default view' claims to support two lines but the second line is cut off.
The 'No cancel view' does not have a caption and does not support text.
The operation defaults to nil, so ClassSelector>>#'showPresenter:' produces a walkback.

There is a known failing unit test for this.

After building the most recent image with BootAll.cmd, I've noticed that the only IDB Goodies package that is installed into the DPRO image by default is the package "IDB Method History", even though I do see a lot more of the IDB Goodies under /Core/Contributions/IDB

Any reason, why those other Goodies are not installed into the image?

The ViewComposer inspector isn't really fit for purpose at either end of the property complexity scale. At the complex end (e.g. for editing Scintilla text styles) it no longer displays any custom presenters, making it necessary to open a separate inspector on the aspect in question.
At the simple, e.g. scalar property, end of the scale it is too clunky. Although the edit capability of the editable list is nice at times, very often too much clicking is necessary. One shouldn't have to double click to open a text editor and then press OK just to edit a simple property value. A more lightweight in-place edit is needed.
It also no longer offers the option of low-level editing at the instance variable level - again one has to open a separate inspector.
It was never that great, but I don't think its current incarnation is an improvement on what went before. Quite the reverse in fact.

There seem to be (at least) two instant messaging rooms that are popular for teams; HipChat and Slack. There's a comparison between the two here. Although Slack appears to come out on top, I think we should try HipChat first for two reasons:

1. Guest access (i.e. not via invite) requires a paid account in Slack
2. Only the last 1000 messages are archived in a free Slack account, whereas HipChat saves everything (I think).

I've created a HipChat room with guest access that you can [sign up to here] XXXX - I've changed my mind - let's try Gitter.im first.. see below.

For the moment, while we are evaluating the room, let's only advertise it here or by inviting known developers who will be interested in expanding/contributing to the core product. Later on we can post it up to comp.lang.smalltalk.dolphin and I'll place a link on the website.

The Win32 GetVersionEx function has been deprecated. It has been replaced with a series of Version Helper functions.
Note that these functions are implemented as inline functions in a header file. They'll need to be exported from the VM.

Hi everyone, (I'm RichardR on c.l.s.dolphin)

Here is my first contributing issue+fix to Dolphin 7.
I will continue later with a Github fork and pull request, also a first for me.

Issue:

Dolphin7.exe, when started without arguments, fails to open the default image "Dolphin.img7" in the same folder.
This functionality is good to have in VM development, when you want to be sure you are using the right (development) VM exe.
It's also handy for (test) deployments that don't use Lagoon. E.g.: Where you deploy an image without stripping the dev env.

The fix is in two places, specified below, with original code commented out.
1 - Change assert that there must be at least two command line arguments
2 - Check before parsing over the "image" command line argument if it was given.

Any comments before proceding?

Cheers,
Richard

==== Proposed sourcecode:

CommandLine>>initialize: anArray

argv := anArray.
"self assert: [2 <= argv size]."
self assert: [argv size >= 1].  "Fix: argv size 1 is OK, open default image"
optIndex := 1.
optionPrefixChars := '-/'.

CommandLine>>parse

arguments := OrderedCollection new.
options := OrderedCollection new.
parsingArgStream := (ReadStream on: argv) 
    next;   "exe"
    "next;"     "img7"   "Fix: Don't assume image name is 2nd argument"
    yourself.

parsingArgStream atEnd ifFalse: [   "Parse and discard image name" 
    parsingArgStream next. ].

[parsingArgStream atEnd] whileFalse: [  "iterate over the argv array"
    self parseNextArg.
].
arguments := arguments asArray.

ViewComposer openOn: (ResourceIdentifier class: TextPresenter selector: #resource_Masked_edit).

Unhandled exception - a GPFault('Invalid access to memory location. Reading 0x0, IP 0x1001B3B8 (M:\Documents\Dolphin\DolphinVM7.DLL)')

ProcessorScheduler>>gpFault:
[] in ProcessorScheduler>>vmi:list:no:with:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>vmi:list:no:with:
IMSMask(ExternalStructure)>>invalidCall
IMSMask>>get_Text:
IMSMask>>text
MaskedEdit>>plainText
MaskedEdit(View)>>text
MaskedEdit(View)>>state
MaskedEdit(AXControlSite)>>state
STBViewProxy>>setView:
STBViewProxy class>>forView:
MaskedEdit(View)>>filerProxy
MaskedEdit(View)>>stbSaveOn:
STLOutFiler(STBOutFiler)>>basicNextPut:
STLOutFiler(STBOutFiler)>>writeInstanceVariables:
STLOutFiler(STBOutFiler)>>writeObject:as:withPrefix:
STLOutFiler(STBOutFiler)>>saveObject:
Array(Object)>>stbSaveOn:

indexOfAnyOf:startingAt: should work for any collection. The SequencedCollection implementation works as expected, but String has an optimized override that does not work if the argument is not a string. It needs a double dispatch...

PackageSelector (in PackagedClassSelector in SystemBrowserShell) has a context menu with the #'versionPackage' command (plus a couple others that don't work either). This method is implemented only in PackageBrowserShell, which is not present in SystemBrowserShell.

ColorRef>>asRGB sends #becomeA: to itself, a very nasty side effect.

In order to be able to support command line tool integration with Dolphin (such as automated testing) we need to be able to parse the command line passed to Dolphin7.exe.

IRegExp pattern: '[0-9]' . "inspect it"
"evaluating works fine"

This fails with a couple of doesNotUnderstad messages:
IRegExp>>argSizes
IRegExp>>interfaceCookie
IRegExp>>objectCookie
IRegExp>>vtbl

This seemed to surface with the VS2015 VM build but looks like it may have been a nascent issue all along. Initially the build and test scripts in AppVeyor were failing but these have now been changed to circumvent the issue (they can be revert when it is fixed).

Originally proposed by Vassili Bykov, Announcements are an improved take on the Observer pattern.

Due to a bug in the SysLink control, the text returned for a LinkButton has an extraneous null-terminator. The WM_GETTEXTLENGTH message is supposed to request the number of characters of text the will
be return by a WM_GETTEXT, excluding any null termination. However the SysLink control reports the
number of chars + 1.

Switching a ListBox into multi-select mode fails if there are pre-existing selections. This is because the style flag is changed before the listbox is recreated, and the recreation process attempts to record the
selected items. It does this by calling ListBox>>selectionsByIndex, which examines the style flags to
determine what selection mode is in force in order to decide which API to call to retrieve the selections.
If the ListBox thinks it is in multi-select mode, then selectionsByIndex attempts to retrieve the selections
from the control using the LB_GETSELITEMS API, which will fail if the ListBox is not actually in multi-select mode.
Really this is a bug in the View>>baseStyle:allMask:recreateIfChanged: method - it should not change the style until just before recreating the window, as any state retrieval operations that examine the style flags could give incorrect results. The same applies to the equivalent method for changing extended styles.
Oddly there is a regression test that covers this, and that is how I noticed the bug. It only seems to fail, however, when I run the tests over remote desktop.

Repro:

l := ListBox show.
l model: #(1 2 3) .
l selectionByIndex: 2.
l isMultiSelect: true.

Expected
List is recreated in multi-select mode, but preserving the selection

Actual

12:03:05, 05 March 2016: 'Index 12642821 is out of bounds'
ListBox(Object)>>errorSubscriptBounds:
ListBox>>selectIndex:set:
[] in ListBox(BasicListAbstract)>>selectIndices:set:
Array(ArrayedCollection)>>do:
ListBox(BasicListAbstract)>>selectIndices:set:
ListBox(ListControlView)>>basicSelectionsByIndex:
MessageSend(MessageSendAbstract)>>value
[] in MessageSequenceAbstract>>value
OrderedCollection>>do:
MessageSequence>>messagesDo:
MessageSequence(MessageSequenceAbstract)>>value
ListBox(View)>>state:
ViewState>>restore
ListBox(View)>>recreate
ListBox(View)>>baseStyle:maskedBy:recreateIfChanged:
ListBox(View)>>baseStyle:maskedBy:
ListBox>>selectionMode:
ListBox>>isMultiSelect:
UndefinedObject>>{unbound}doIt

Performing the BootXXX.cmds on a machine where Dolphin 6 is installed results in failure with an ever growing DBOOT.errors file. It appears to be an interference with the Dolphin 6 compiler COM object.

We need to come up with a workflow for D7 that caters easily for the following:

• There will likely be two classes of users. Those who wish to work on the core Dolphin product (let's call them coredevs) and those who want to treat Dolphin as a tool to build other projects (called them userdevs).
• Users may be in both categories (userdevs may make changes to the core system during their project work that they can easily contribute back as coredevs into the Core).
• We can assume that coredevs will always use GitHub. userdevs may not. They may chose to use another source control system like STS, git, mercurial or something else.

Workflow A - Emulate D6

One proposal is to emulate the Dolphin 6 workflow. D6 used a read-only "template" core image stored in Program Files that could be duplicated (unlocked) into any \User directory. All core packages would exist in the image but when externalised from it (by package save) would appear as a directory structure under \User. Core Dolphin packages would appear under \User\Dolphin and user packages would be, say, under \User\My Projects.

Typically the userdev would externalise packages from their image and manually place them into a SCCS. In such cases they would probably write a load script to install their project packages into a new image when required. The DPRO STS system would help greatly in this respect since it has the concept of Projects that can load versions of many packages to bring any project into the image.

A userdev working on multiple projects at once might choose to work in a single image, or multiple images in \User or maybe in multiple images in separate user directories (\User1, \User2).

Workflow A - for D7

1. The Dolphin core is downloaded into \Dolphin (by coredevs) from GitHub or (by userdevs) as a ZIP with the images prebuilt. GitHub users will have to boot the images before use.

2. A working DPRO image is copied to \User. This effectively (as it stands now) makes Dolphin think that all the core packages actually live under \User\Core. The link with the original \Dolphin\Core directory where the Git information is held is lost.

3. A userdev creates a project and the package source is held in \User\Projects. This may be a Git directory if the userdev is using Git/GitHub or it might be held in STS.

4. Any changes that are made to the Dolphin core will be saved to PAX files under \User\Core. If the Source Browser is used to write out changes only, then it is easy to see what is changed because only the changed packages will be present.

5. A userdev reloading a project will have to invent a loading scheme (ST fileIn?) to load all the changes into a virgin image. Of course, STS would make this significantly easier.

6. A userdev who is also a coredev will want to apply the changes saved under \User\Core back into the \Dolphin\Core directory (the GitHub repository) and then submit a pull request. This is the tricky and untidy bit. Two possibilities come to mind:

a) Copy the *\User\Core* sub-directories to \Dolphin\Core and then commit them using Git as normal.

b) Copy a virgin DPRO image from \Dolphin to \User. Load the project contents under \User\Core into this image and then copy the DPRO image back to \Dolphin. The Source Browser can then save out the core changes, which can be committed as usual.

I think this flow will work, although the copying of core information back and forth between \User and \Dolphin directories is unpleasant. It also occurs to me that such a flow will probably work better using STS as a sort of intermediate repository between the image and GitHub (or any other SCCS). This is not ideal because it would be yet another tool barrier for a new user to learn when getting started. This might not be appreciated if the userdev just wants to use GitHub anyway. Some additional Git related features in STS might make this more palatable.

Workflow B - Users never change Dolphin core

This workflow is identical to Workflow A above except it avoids the tricky moving of modification back from the \Work directory structure back to \Dolphin by disallowing them. So as above except:

1. Whenever a userdev find that a change is needed to the Dolphin core files they must stop and return to the \Dolphin directory and make the changes in a (DPRO) image there.

2. The Source Browser is used to emit the core changes under \Dolphin and GitHub can then be used to commit them and submit a pull request (if the this is a coredev role).

3. A new core DPRO image is built using BootDPRO or BootAll and copied to the \Work folder.

4. From there, the userdev reloads projects and continues work with the new Dolphin core changes in place.

This is perhaps a neater workflow that A, especially as userdev changes to the Dolphin core should be rare. Remember, using Dolphin's package system and loose methods it is still possible to extend the core classes without having to modify the core packages.

Workflow C - Clone Dolphin Core for each project

The idea here is to have a full \Dolphin installation for each project (or set of projects).

1. The Dolphin core image is unzipped or cloned into \User\Dolphin. Again coredevs must use GitHub and will have to build the product images using BootAll.cmd.

2. User project packages are held under \User\Dolphin\Projects and sit alongside the Core directory. The .gitignore file will have to be modified in \User\Dolphin to ignore files under Projects - these would be cloned from a separate user GitHub repository (if using GitHub).

3. During development the user makes changes to his/her own packages and possibly to core packages.

4. The Source Browser is used to write out source changes to PAX files under \User\Dolphin\Projects and \User\Dolphin.

5. Git can then be used to push changes to the core and project repos separately.

The above workflows are proposals. Comments and alternative proposals are welcome.

Once we have one (or maybe two) definitive workflows we should publish them on the Wiki.

Reported by John Brant (24 Jul 2015).

I noticed a bug in the RB code while I was
working on SmaCC. In RBAbstractClass>>instanceVariableNames: it sends
"aCollectionOfStrings asOrderedCollection" which in VW & VA copies the
collection. For Dolphin this should be changed to "OrderedCollection
withAll: aCollectionOfStrings".

StsAdminShell>>#'versionSnapshotPackagesList:' references missing ProgressDialog 'Timer view'.

DCE is no longer relevant since pro is OSS. It is slowing down the BootAll script so should be removed.

From MSDN.
"The behavior of the C Runtime when an invalid parameter is found is to call the currently assigned invalid parameter handler. The default invalid parameter invokes Watson crash reporting, which causes the application to crash and asks the user if they want to load the crash dump to Microsoft for analysis."
This is inconvenient, since a small mistake crashes the dev image or app, and inconsistent with the usual behavior when calling other external APIs from Dolphin, which is generally that a the error is detected and a Smalltalk exception gets raised. The parameter validation errors should be translated to a Smalltalk exception (perhaps a CRTError), so that the issue can be handled in Smalltalk in an appropriate way.
The simplest fix for this would be to replace the standard parameter validation function with one that does nothing, which will cause the called CRT function to perform old-style C-runtime error reporting (typically set errno to EINVAL, and return whatever form of error return value it uses). This could be done in the VM, or the image. This fix will require that any call sites detect and handle the error appropriately, although they need to do this anyway for other potential error conditions.
A better fix might be to fail the external library call and override #invalidCall on CRTLibrary so as to translate the invalid parameter information into an appropriate Smalltalk exception in a standard way. the advantage of this would be consistent and automatic behaviour for invalid parameter errors. This will require both VM and image side modifications.

I think that the proper solution is to have a new hash function that takes as an argument a collection of visited objects to avoid the recursion. I can work up something but before spending much time on it I'd welcome some input/guidance.

| array |
array := Array new: 1.
array at: 1 put: array.
array hash.

| assoc |
assoc := Association new.
assoc key: assoc.
assoc hash

ViewComposer openOn: (ResourceIdentifier class: DatePresenter selector: #resource_Month_view).

2:56:57 PM, Thursday, March 03, 2016: 'Unspecified error (16r4005: Unspecified error)'
IDolphinAxHost(COMInterface)>>hresultError:
IDolphinAxHost(ExternalStructure)>>invalidCall
IDolphinAxHost>>CreateControlLicEx:hWnd:pStream:ppUnk:piAdvise:bstrLic:
IDolphinAxHost>>createControlLicEx:hWnd:pStream:piAdvise:bstrLic:
MonthView(AXControlSite)>>safeCreateControlFromStream:
MonthView(AXControlSite)>>controlBinaryStoreBytes:
MessageSend(MessageSendAbstract)>>value
[] in MessageSequenceAbstract>>value
OrderedCollection>>do:
MessageSequence>>messagesDo:
MessageSequence(MessageSequenceAbstract)>>value
MonthView(View)>>state:
MonthView(STBViewProxy)>>restoreView
MonthView(STBViewProxy)>>restoreTopView
[] in MonthView(STBViewProxy)>>stbFixup:at:
[] in STBInFiler>>evaluateDeferredActions
OrderedCollection>>do:
STLInFiler(STBInFiler)>>evaluateDeferredActions
STLInFiler(STBInFiler)>>next
[] in DesktopView(View)>>loadViewResource:forEdit:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
DesktopView(View)>>loadViewResource:forEdit:
[] in SmalltalkSystem>>loadViewResource:inContext:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
RefactoringSmalltalkSystem(SmalltalkSystem)>>loadViewResource:inContext:
ViewComposer>>basicPasteResource:context:
ViewComposer>>pasteResource:context:position:
ViewComposer>>openOn:
ViewComposer class>>openOn:
DatePresenter class>>{unbound}doIt

Following is a simplification of my code the produces the walkback (the workaround is to move the variable declaration to outside the block):

(1 2) do: [:each | | a |

[[self halt.
a := 'AAA'.
] on: Error do: [:ex | ]] ensure: [ ]].

2:31:48 PM, Tuesday, March 08, 2016: 'not indexable'
Object>>errorAt:
Object>>at:
[] in Debugger>>updateTemporaries
Array(ArrayedCollection)>>do:
Debugger>>updateTemporaries
Debugger>>displayFrame
Debugger>>onFrameSelected
EventMessageSend>>forwardTo:withArguments:
EventMessageSend>>value
[] in MessageSequenceAbstract>>value
EventMessageSequence>>messagesDo:
EventMessageSequence(MessageSequenceAbstract)>>value
EventsCollection>>triggerEvent:
ListPresenter(Object)>>trigger:
ListBox(ListControlView)>>onSelectionChanged
ListPresenter(SelectableItemsPresenter)>>onSelectionChanged
ListBox(ListControlView)>>onSelChanged:
ListBox(BasicListAbstract)>>onSelChanged:
ListBox(ListControlView)>>onSelChanged
ListBox(BasicListAbstract)>>setSelectionsByIndex:
ListBox(BasicListAbstract)>>selectionsByIndex:ifAbsent:
ListBox(ListControlView)>>selectionByIndex:ifAbsent:
ListBox(ListControlView)>>selectionByIndex:
ListBox(ListControlView)>>selection:ifAbsent:
ListBox(ListControlView)>>selection:
ListBox(ListControlView)>>selectionOrNil:
[] in ListPresenter(SelectableItemsPresenter)>>selectionOrNil:
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry
[] in ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>on:do:
ListPresenter(SelectableItemsPresenter)>>selectionOrNil:
Debugger>>populateStackModel
Debugger>>process:topFrame:
[] in Debugger class>>show:process:topFrame:resumable:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
Cursor>>showWhile:
Debugger class>>show:process:topFrame:resumable:
Process>>attachDebugger:topFrame:resumable:
Process>>debug:topFrame:resumable:
[] in Process>>walkback:topFrame:resumable:
PostedActionWindow>>evaluateNextAction
PostedActionWindow>>preTranslateMessage:
InputState>>preTranslateMessage:
InputState>>pumpMessage:
InputState>>loopWhile:
InputState>>mainLoop

It seems that there has been a change in the Scintilla style mask implementation that is causing the SmalltalkStyler to backtrack and restyle from the start of the text every time. Scintilla requests styling in ranges advancing towards the end, typically a few thousand chars at a time. The styler itself also imposes a maximum block size it will style in one go (32k). On the first request, the styler will style the requested range, and then scintilla requests styling of a subsequent block starting from the next character after the last styled. The Smalltalk styler attempts to reset itself to a whitespace position (outside a comment) at or before the requested style start position from which it is able to commence styling from a known state. However this backtracking now seems to degenerate to going right back to position 1.
The resulting behavior is that the styler styles increasingly large blocks of text from the beginning on each request, with each operation repeating all those before and taking increasingly more and more time. This continues up to the maximum block size of 32Kb, at which point it will advance no further. The scintilla editor continues to ask for the rest of the text to be styled, burning lots of CPU to no useful effect.

Toolbars looks s little outdated on W10 due it's flat style.
I've changed the backcolor of some of them as in the following screenshot.

I've set the backcolor to nil on help toolbar and in instance or class methods option selector.

In addition to the img7 file the boot process produces another unusable img file.
When this file is run it raises a MessageBox with the following text:
"Sorry, but this trial copy of Dolphin Smalltalk has permanently expired."
(this is the case for dcore.img)

When loading the package 'IDB Printer' (Version 6b - November 2005), the 'Dolphin' package is marked as changed but when compared to the version in the code repository the system reports no changes. On further investigation it appears that the IDB Printer package has a preload script that adds some constants to Win32Constants, a PoolConstantsDictionary that is owned by the Dolphin package. I believe that there are a couple issues. First, by using the preload script in this way the package is essentially creating a "loose constant" (analogous to the loose method) but the source code management system does not recognize that concept and treats the change as part of another package. Second, the process of looking for changes does not seem to compare the contents of globals contained in the package to the contents of globals in the image. Thus, ignoring the change (and making it much harder to figure out why the package was changed).

It seems that following the move to VS2015 and subsequent changes, Dolphin no longer runs under Wine. The error on startup is:

wine: Call from 0x7b83c3de to unimplemented function api-ms-win-crt-runtime-l1-1-0.dll._get_narrow_winmain_command_line, aborting
wine: Unimplemented function api-ms-win-crt-runtime-l1-1-0.dll._get_narrow_winmain_command_line called at address 0x7b83c3de (thread 0033), starting debugger...
wine@ubuntu:~/shared_directory$ Unhandled exception: unimplemented function api-ms-win-crt-runtime-l1-1-0.d._get_narrow_winmain_command_line called in 32-bit code (0x7b83c3de).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:7b83c3de ESP:00c0fd64 EBP:00c0fdd8 EFLAGS:00000283(   - --  I S - - -C)
 EAX:7b827a69 EBX:7b8c0000 ECX:7e9ab044 EDX:00c0fd84
 ESI:80000100 EDI:00000000
Stack dump:
0x00c0fd64:  00c0fe00 00000008 7ea0eb99 80000100
0x00c0fd74:  00000001 00000000 7b83c3de 00000002
0x00c0fd84:  7e9ab044 7e9ab0ec 7ea93d00 00000001
0x00c0fd94:  7ea83000 f75fbdbb f7799000 00000000
0x00c0fda4:  f754ab6d 7ea83000 7ea344ce 00c0fde0
0x00c0fdb4:  00000000 00000044 7ea0854d 00000009
000c: sel=0067 base=00000000 limit=00000000 32-bit r-x
Backtrace:
=>0 0x7b83c3de in kernel32 (+0x2c3de) (0x00c0fdd8)
  1 0x7e9ab028 in api-ms-win-crt-runtime-l1-1-0 (+0xb027) (0x00c0fe10)
  2 0x7e9aaa2d in api-ms-win-crt-runtime-l1-1-0 (+0xaa2c) (0x00c0fe60)
  3 0x00401824 in dolphin7 (+0x1823) (0x00c0fe60)

This is with the latest (almost) bleeding edge version of winetricks installed and then using winetricks -q vcrun2015 to install the 2015 runtime. Note that I was unable to use the very latest (as of today) winetricks because this has a syntax error in an ie8 function name. To get the prior version I used:

wget https://raw.githubusercontent.com/Winetricks/winetricks/dd1bff70e6f11338b63ee07e44ff28e76010885e/src/winetricks
sudo cp winetricks /usr/bin
sudo chmod +x /usr/bin/winetricks

The current workaround is to go back to using the older 7.0.2 version of Dolphin that was built with VS2015 but presumably before some incompatible changes.

It's about time we had true breakpoints in Dolphin. Thanks to John giving permission to add his method spies package into the the base of Dolphin we should be able to get there in short(ish) order.

There should not need to be a special process to make changes to base classes (i.e. classes in the
Dolphin package). It should be possible to reload the base classes at the start of the boot process.

The "Extract/Move to Component refactoring" may need to add pool dictionary references to the
target class(es). However, it generates a warning whether or not the target class(es) already
reference the required pools. It also generates this warning multiple times in some cases (which may
be a different issue).

The brace highlighting in the code editors is too subtle and difficult to see. Scintilla now supports use of an indicator for brace highlighting, and this may be more appropriate (e.g. use the box style that adds a partially transparent box around the matching brace).

As discussed in #16 we should migrate the OA docs from http://www.object-arts.com/downloads/docs/ into the github WIKI.

I will take a go at that over the coming weekend.

Actually, downloading the project from GitHub using the "download as zip" link results in smalltalk source code corruption in image builds.
The same happens when the repository is cloned from a computer with the core.autocrlf (git config option) set to false.

The problem is originated in the automatic eol conversion done by git.

To solve both problems a .gitattributes file is needed as is explained here

Scintilla is now at version 3.6.3.. There is masses of new stuff to exploit.

We already have a good Smalltalk parser in the image that is used for syntax and semantic analysis in the IDE, but are still reliant on a compiler written in C to compile methods into the system. It is really about time we implemented a compiler backend in Smalltalk that can generate Smalltalk bytecodes and methods from the ASTs created by the SmalltalkParser.

The MenuComposer has had the horizontal spacing between items set to a very large amount at some point in the past as what looks to be a workaround for the fact that if the drop down menus overlap then walkbacks are thrown on clicking on an adjacent menu because the repaint occurs before the geometry has been calculated.
There are a lot of more minor issues with the geometry, and really the whole painting needs to be redone to use the theme engine so it is WYSWYG again. For now it just needs to be made reasonably functional.

If an error occurs during the boot, then the boot process just sits in a loop writing repeated crash dumps to an increasingly enormous errors file. The boot should terminate gracefully having logged a single error dump.

Sometimes when I close an application window I get a gpFault. The following screen show shows the debugger and stack. It appears that the uiIdle method is iterating over the topLevelWindows when one of the windows goes away. Particularly surprising is that the receiver of #primTerminate is SmallInteger and it is implementing a method in Process. This looks to me like a stack corruption.

When inspecting a large object, e.g. the Win32Constants pool dictionary, the PublishedAspectInspector shows only the first 200 aspects, and a further ellipsis entry that when clicked shows the next 200, and so on. The displayed key and value for this ellipsis entry are incorrect, being an integer from the sequence 201, 401, and so on, and a value with the icon "..." (correct) and the string value "a MessageNotUnderstood" (clearly not correct).

See forum request.

We need a separate repository outside of Dolphin to store third party contributions.

All Contributions that are in this repository under Core should be loaded into one of the boot images and pass all (forthcoming) build tests. There may be special cases (like tests or examples, maybe) where packages that are intimately tied to the Dolphin/Core/Contributions packages may not get loaded, but these should be the exception.

All public contributions (for the time being at least) should be added to Dolphin/Contributions which are held in a separate repository.