[squeak-dev] [ANN] Squeak 5.1 Feature Freeze -- Trunk closed for new features; only bug fixes or text updates

Tobias Pape Das.Linux at gmx.de
Thu Aug 11 18:32:36 UTC 2016


On 11.08.2016, at 20:14, tim Rowledge <tim at rowledge.org> wrote:

>> On 10-08-2016, at 8:21 AM, marcel.taeumel <Marcel.Taeumel at hpi.de> wrote:
>> A first All-In-One can be tried out from here:
>> https://www.hpi.uni-potsdam.de/hirschfeld/artefacts/squeak/Squeak5.1beta-16336-r3397-32bit-All-in-One.zip
>> 
> 
> 
> I like the idea of the welcome dialogue stuff. But I see some problems that we hopefully still have time to handle.
> 
> -The initial ‘welcome’ text is in the middle of the screen and then jumps to the top. Seems a bit jarring.
> - second ‘page’ - “You can try… “ might be better more like  “You can see the effects of these settings in the live and editable windows to the right”
> - there’s no hint what many of the settings will do or how they might affect things. Help balloons might be enough to solve this, explaining for example how to see the effect of choosing ‘fast drag and resize’.
> - at the end of the welcome we are dropped into a dark empty world. I half expect Orcs to come charging at me. Maybe an open browser and workspace ought to be left in place? For experts skipping the whole thing I suspect the first thing we’d do is open a browser/workspace anyway!
> - it leaves out the thing I’d suggest is most important of all - urging the user to first save the image in a new place to discourage the ‘abuse’ of changing the default image. I claim we should conventionally start a new system from the all-in-one, save the image in a local place and thereafter run that image until and unless a fresh image needs to be started. Think of this like many applications that allow opening a new file or a template, with the default image being a very well set up template.
> - another useful start-up option here would be entering developer initials
> - another would be to point out the help system. Of course, we need to improve the content therein as well. And the swiki as always is in need of love.
> 
> 
>> Note that we are looking for start-up bugs in the Linux scripts.
> 
> At least for the ARM linux tree the ‘squeak’ shell script is not so good.
> - it ought to be finding the latest vm; this is a little complex because of the naming change from blah-XXXX to blah-2106MMDDHHMM. And of course, affected by which VM is to be delivered anyway.
> - the newer versions of the script add an option for a gdb flag.
> - it may be appropriate to have the x86 & ARM versions differ in their approach to finding the clib
> - at least for the ARM version there is a serious issue with remote displays (that is, ARM linux has the problem, which squeak triggers) and we need to wrap the whole thing in ‘sudo -E’. We have a program that can be used to test this at runtime (I can send it to anyone interested) but all my attempts to wrap the final line of the script in the required sudo have met with no success. It is likely some problem with how forking and execing and sudo didn’t get on well as children. A better solution would be to fix linux so it doesn't cause the problem in the first case but it seems to have been around for many years.
> 
> 
>> Note that we have not yet fixed the Windows .ini bug.
>> Note that Windows 10 is quite anxious about starting an unsigned executable.
> And you should see how annoyed OS X gets about it.
> 
> The image is frikkin’ huge. How on earth do we have 22Mb of ByteArray/BitMap/ByteString around? And it looks like we are keeping a very large amount of MC stuff; 13018 instances of MCVersionInfo/MCVersionName/DateAndTime/Date/Time/UUID. Is that smart? Simply flushing the cached ancestry from the MC browser gets rid of 60% of them and appears to save 3Mb. Except the damn saved image afterwards is exactly the same size! Sigh.

We can convert all base64 strings to ascii85 and save some 10-20% ;D

> 
> 
> tim





More information about the Squeak-dev mailing list