<div dir="ltr">Hi Tim,<div><br></div><div>    thanks for this.  I don't want to respond to the tests per se, but I do want to address one parenthetical you make.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 28, 2018 at 1:27 PM, Tim Johnson <span dir="ltr"><<a href="mailto:digit@sonic.net" target="_blank">digit@sonic.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I downloaded an ran the All-in-one and wanted to put it through its paces on Windows 7 32-bit.  (I recognize 32-bit is a dying breed, but nonetheless...)<br></blockquote><div><br></div><div>I don't think it is, at least not unless underlying OSs cease to support it.  Because Smalltalk has infinite precision arithmetic the 32-bit system works very well for anything that doesn't require a huge address space.  Because in a symbolic processing application the 32-bit implementation will move half the data than the 64-bit implementation, the 32-bit version should be faster, and so if the application fits within the 32-bit heap there's no reason to go to 64-bits; one is simply wasting memory bandwidth.  I no longer use the 32-bit system with any regularity, but that's because the VM simulator is faster on 64-bits than on 32-bits because it spends a lot of time accessing the array (actually a Bitmap or DoubleWordArray) that contains the heap, and on 64-bits there's much less overflow into boxed integers.  But in this case the application is to a symbolic processing one, but a low level bit manipulation one.</div><div><br></div><div>So I, and others, hope that the 32-bit system will live for a long time.  The 64-bit version has its place, and in an increasing number of contexts it is required, but it can be overkill, and so there are string benefits to maintaining both.  Especially since in Smalltalk we have the infrastructure to freely exchange code between the two and are much less dependent on word size than programs written in many other programming languages.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Test steps:<br>
<br>
* ran squeak.bat<br>
* skipped configuration<br>
* ran update (to #18160)<br>
* ran Installer ensureRecentMetacello<br>
* ran:<br>
<br>
Metacello new<br>
    baseline: 'Seaside3';<br>
    repository: 'github://SeasideSt/Seaside:ma<wbr>ster/repository';<br>
    load<br>
<br>
Please note: my notes below are from my initial run and have not been verified by duplicating my initial run.<br>
<br>
results:<br>
<br>
* initial fetches of BaselineOf* via Metacello all seem to initially stall, then retry, then succeed.  My internet connection is pretty fast (gigabit fiber).  In Transcript, each shows similar to:<br>
<br>
...RETRY->BaselineOfSeaside3<br>
...RETRY->BaselineOfGrease<br>
<br>
* the VM opened a Debug Console.  Its text:<br>
<br>
LoadLibrary(UUIDPlugin) (998: Invalid access to memory location.<br>
<br>
)<br>
<br>
LoadLibrary(UUIDPlugin.dll) (998: Invalid access to memory location.<br>
<br>
)<br>
<br>
UUIDPlugin was mentioned on the mailing list about two years ago, but I don't know if this is related.<br>
<br>
* Grease throws various Undeclared warnings in the transcript;  I wonder if it will need some adjustments for Squeak 5.2, or what. Some examples:<br>
<br>
BlockContext>>fixCallbackTemps (home is Undeclared)<br>
BlockContext>>tempVarRefs(meth<wbr>od is shadowed)<br>
BlockContext>>tempVarRefs (home is Undeclared)<br>
BlockContext>>tempVarRefs (startpc is Undeclared)<br>
<br>
<br>
I decided to run some tests.  Results:<br>
<br>
* Grease tests all pass, though one prompts for author initials.<br>
<br>
* KernelTests:  1 error, 1 unexpected pass.<br>
<br>
passed:   FloatTest>>#testTimesTwoPowerG<wbr>radualUnderflow<br>
<br>
failed:  AllocationTest>>#testOutOfMemo<wbr>rySignal<br>
<br>
    (failed:  #vmParameterAt:put:   ... primitive 254) ?<br>
<br>
* NetworkTests:  all green<br>
<br>
* "Tests-*" -- excepting Tests-Bugs, Tests-Release, DecompilerTests*<br>
<br>
I interrupted & restarted these tests partway thru in order to deselect DecompilerTests.  Hopefully that didn't affect my results, but is worth mentioning.<br>
<br>
14 failures:<br>
<br>
MCWorkingCopyTest>>#testDouble<wbr>RepeatedMerge<br>
MCWorkingCopyTest>>#testRedund<wbr>antMerge<br>
MCWorkingCopyTest>>#testSnapsh<wbr>otAndLoad<br>
PackageDependencyTest>>#testEt<wbr>oys<br>
PackageDependencyTest>>#testMo<wbr>rphic<br>
PackageDependencyTest>>#testMo<wbr>rphicExtras<br>
PackageDependencyTest>>#testNe<wbr>twork<br>
PackageDependencyTest>>#testSU<wbr>nitGUI<br>
PackageDependencyTest>>#testSo<wbr>und<br>
PackageDependencyTest>>#testSy<wbr>stem<br>
PackageDependencyTest>>#testTo<wbr>ols<br>
UserInterfaceThemeTest>>#test0<wbr>1ImplementationHooks<br>
UserInterfaceThemeTest>>#test0<wbr>5ClearProperty<br>
UserInterfaceThemeTest>>#test0<wbr>6SetAndClearUnkownProperty<br>
<br>
2 errors:<br>
<br>
MCWorkingCopyRenameTest>>#test<wbr>RenamePrefix<br>
MCWorkingCopyRenameTest>>#test<wbr>RenameSuffix<br>
<br>
<br>
* SqueakSSLTests -- all green!<br>
<br>
* WebClientTests -- two failures:<br>
<br>
WebClientServerTest>>#testLogg<wbr>ing200<br>
WebClientServerTest>>#testLogg<wbr>ing404<br>
<br>
* ChronologyTests -- one failure (maybe this is an expected failure)<br>
<br>
DateAndTimeLeapTest>>#testAsSe<wbr>conds<br>
<br>
<br>
Thanks everybody,<br>
Tim<br>
<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>