Hi Folks -
I've done two interesting improvements to the Win32 VM mostly for production uses. First, fetch the latest Windows VM from:
http://squeakvm.org/win32/release/SqueakVM-Win32-3.10.5-bin.zip
and run it. Aaaahhhh! What a nice splash screen ;-) The reason for the (optional) splash screen is that I finally got beaten into delaying the main window creation up until the point when there is something to show but unfortunately this also leads to the problem that if the time to show something interesting is a couple of seconds there is no user-visible feedback about the application launch, so the splash screen support became necessary (shame on the Mac VM for delaying window creation without splash screen! ;-)
Of course, not being the artist myself, I'd appreciate a nicer looking splash screen by someone a little more artistically inclined, and that could mean fame and ... err ... fame for you!
(see also http://squeakvm.org/win32/settings.html for the updated documentation on the splash screen settings)
The other relevant production improvement in this VM are a few new system attributes which report very detailed information about the current platform:
* Smalltalk getSystemAttribute: 10001 Reports detailed hardware information, for example:
Hardware information: Manufacturer: Panasonic Model: R5 Number of processors: 1 Page size: 4096
Memory Information (upon launch): Physical Memory Size: 1038384 kbytes Physical Memory Free: 330896 kbytes Page File Size: 1987776 kbytes Page File Free: 1332884 kbytes Virtual Memory Size: 2097024 kbytes Virtual Memory Free: 1931968 kbytes Memory Load: 68 percent
Processor 0: Genuine Intel(R) CPU U1400 @ 1.20GHz Identifier: x86 Family 6 Model 14 Stepping 8 ~MHZ: 1197
* Smalltalk getSystemAttribute: 10002 Reports detailed OS information, for example:
Operating System: Microsoft Windows XP (Build 2600 Service Pack 2) Registered Owner: Registered Company: SP major version: 2 SP minor version: 0 Suite mask: 100 Product type: 1
* Smalltalk getSystemAttribute: 10003 Reports detailed Graphics information, for example:
Display Information: Graphics adapter name: Mobile Intel(R) 945GM/GU Express Chipset Family Primary monitor resolution: 1024 x 768
Device: Mobile Intel(R) 945GM/GU Express Chipset Family Adapter String: Mobile Intel(R) 945GM/GU Express Chipset Family Bios String: Intel Video BIOS Chip Type: Intel(R) GMA 950 DAC Type: Internal Memory Size: 0x08000000
Driver Versions: igxprd32: 6.14.10.4785
All of the above can be extremely helpful if you need to find out about a problem and, perhaps most importantly, the information is also written in crash.dmp if the Squeak VM ever crashes. This information has allowed us to successfully debug a few problems that would be otherwise very hard to find.
As usual, the sources for this version are up on squeakvm.org as well:
http://squeakvm.org/win32/release/SqueakVM-Win32-3.10.5-bin.zip
Enjoy, - Andreas
i can't help with artistics, but can help with making win32 VM :) Here's makefiles i changed slightly to be able build VM from any directory, not just from platforms/win32 directory.
Also, you should remove Win32VMMaker>>sourceDirectory method to be able to pick any output directory for generating sources and building VM. I found very inconvenient to build VM in platforms/win32 dir and mix generated sources with platform dependent code. Maybe i'm doing something wrong, but without changes to makefiles i was unable to build VM from any directory. (btw i was following instructions given on squeak-dev pages). Just place these files in dir, where you picked as root of generated sources (im usually using winbuild dir).
If something not working, check PLATDIR and DXDIR.
I hope files i provided will be useful.
On 30/08/2007, Andreas Raab andreas.raab@gmx.de wrote:
Hi Folks -
I've done two interesting improvements to the Win32 VM mostly for production uses. First, fetch the latest Windows VM from:
http://squeakvm.org/win32/release/SqueakVM-Win32-3.10.5-bin.zip
and run it. Aaaahhhh! What a nice splash screen ;-) The reason for the (optional) splash screen is that I finally got beaten into delaying the main window creation up until the point when there is something to show but unfortunately this also leads to the problem that if the time to show something interesting is a couple of seconds there is no user-visible feedback about the application launch, so the splash screen support became necessary (shame on the Mac VM for delaying window creation without splash screen! ;-)
Of course, not being the artist myself, I'd appreciate a nicer looking splash screen by someone a little more artistically inclined, and that could mean fame and ... err ... fame for you!
(see also http://squeakvm.org/win32/settings.html for the updated documentation on the splash screen settings)
The other relevant production improvement in this VM are a few new system attributes which report very detailed information about the current platform:
- Smalltalk getSystemAttribute: 10001
Reports detailed hardware information, for example:
Hardware information: Manufacturer: Panasonic Model: R5 Number of processors: 1 Page size: 4096
Memory Information (upon launch): Physical Memory Size: 1038384 kbytes Physical Memory Free: 330896 kbytes Page File Size: 1987776 kbytes Page File Free: 1332884 kbytes Virtual Memory Size: 2097024 kbytes Virtual Memory Free: 1931968 kbytes Memory Load: 68 percent
Processor 0: Genuine Intel(R) CPU U1400 @ 1.20GHz Identifier: x86 Family 6 Model 14 Stepping 8 ~MHZ: 1197
- Smalltalk getSystemAttribute: 10002
Reports detailed OS information, for example:
Operating System: Microsoft Windows XP (Build 2600 Service Pack 2) Registered Owner: Registered Company: SP major version: 2 SP minor version: 0 Suite mask: 100 Product type: 1
- Smalltalk getSystemAttribute: 10003
Reports detailed Graphics information, for example:
Display Information: Graphics adapter name: Mobile Intel(R) 945GM/GU Express Chipset Family Primary monitor resolution: 1024 x 768
Device: Mobile Intel(R) 945GM/GU Express Chipset Family Adapter String: Mobile Intel(R) 945GM/GU Express Chipset Family Bios String: Intel Video BIOS Chip Type: Intel(R) GMA 950 DAC Type: Internal Memory Size: 0x08000000
Driver Versions: igxprd32: 6.14.10.4785
All of the above can be extremely helpful if you need to find out about a problem and, perhaps most importantly, the information is also written in crash.dmp if the Squeak VM ever crashes. This information has allowed us to successfully debug a few problems that would be otherwise very hard to find.
As usual, the sources for this version are up on squeakvm.org as well:
http://squeakvm.org/win32/release/SqueakVM-Win32-3.10.5-bin.zip
Enjoy,
- Andreas
On 29-Aug-07, at 10:45 PM, Andreas Raab wrote:
and run it. Aaaahhhh! What a nice splash screen ;-) The reason for the (optional) splash screen is that I finally got beaten into delaying the main window creation up until the point when there is something to show
About time, too.
but unfortunately this also leads to the problem that there is no user-visible feedback about the application launch, so the splash screen support became necessary (shame on the Mac VM for delaying window creation without splash screen! ;-)
A splash screen should be configurable in some way. Ideally it ought to be generated by the image! The *real* problem here is the whole " if the time to show something interesting is a couple of seconds" part. There really isn't much of an excuse for such a delay.
I don't think it would be appropriate to have a window of any sort display when you are starting a Seaside server for example. Or running on an IBM 3090. Or a signet ring.
- Smalltalk getSystemAttribute: 10001
Good idea(s)
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: PS: Pirate Software
tim Rowledge wrote:
A splash screen should be configurable in some way. Ideally it ought to be generated by the image! The *real* problem here is the whole " if the time to show something interesting is a couple of seconds" part. There really isn't much of an excuse for such a delay.
You mean loading the image and relocating pointers is no excuse? Running the startup code, redrawing the screen? No excuses either? Even a basic image takes about a second to start (the delay between launching it and seeing something is noticeable); if you actually do anything when you start the image or if you simply have larger images it easily takes longer.
I don't think it would be appropriate to have a window of any sort display when you are starting a Seaside server for example. Or running on an IBM 3090. Or a signet ring.
And which part of "optional" splash screen is so hard to understand? Remove splash.bmp and it's gone.
Cheers, - Andreas
On Aug 30, 2007, at 8:55 AM, Andreas Raab wrote:
tim Rowledge wrote:
A splash screen should be configurable in some way. Ideally it ought to be generated by the image! The *real* problem here is the whole " if the time to show something interesting is a couple of seconds" part. There really isn't much of an excuse for such a delay.
You mean loading the image and relocating pointers is no excuse? Running the startup code, redrawing the screen? No excuses either? Even a basic image takes about a second to start (the delay between launching it and seeing something is noticeable); if you actually do anything when you start the image or if you simply have larger images it easily takes longer.
Actually I recall (years ago I last looked) is that we make multiple passes thru object memory to fix things up before starting. Although this is 'fast' I've always felt it could be reduced to a single pass and post work on remembered objects.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
On 30-Aug-07, at 8:55 AM, Andreas Raab wrote:
tim Rowledge wrote:
A splash screen should be configurable in some way. Ideally it ought to be generated by the image! The *real* problem here is the whole " if the time to show something interesting is a couple of seconds" part. There really isn't much of an excuse for such a delay.
You mean loading the image and relocating pointers is no excuse? Running the startup code, redrawing the screen? No excuses either?
It's a *reason* but not an *excuse*. Yes, there is a load of assorted stuff done as the VM starts up and loads the image (which could take several seconds on some machine/setups) and then as the image starts up. That's the reason(s). The excuse really adds up to "we haven't bothered to improve things". As John mentioned, it seems likely that some of the VM related memory scanning could be improved. Looking at the fairly intimidating list of things done as part of the image startup I feel sure we could do a lot better - not least by having a smaller simpler better thought out image in the first place.
Even a basic image takes about a second to start (the delay between launching it and seeing something is noticeable); if you actually do anything when you start the image or if you simply have larger images it easily takes longer.
I don't think it would be appropriate to have a window of any sort display when you are starting a Seaside server for example. Or running on an IBM 3090. Or a signet ring.
And which part of "optional" splash screen is so hard to understand? Remove splash.bmp and it's gone.
Cheers,
- Andreas
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Any program that runs right is obsolete.
Damn! Keyboard fumble sent this before I had finished typing.
On 30-Aug-07, at 9:40 AM, tim Rowledge wrote:
On 30-Aug-07, at 8:55 AM, Andreas Raab wrote:
tim Rowledge wrote:
A splash screen should be configurable in some way. Ideally it ought to be generated by the image! The *real* problem here is the whole " if the time to show something interesting is a couple of seconds" part. There really isn't much of an excuse for such a delay.
You mean loading the image and relocating pointers is no excuse? Running the startup code, redrawing the screen? No excuses either?
It's a *reason* but not an *excuse*. Yes, there is a load of assorted stuff done as the VM starts up and loads the image (which could take several seconds on some machine/setups) and then as the image starts up. That's the reason(s). The excuse really adds up to "we haven't bothered to improve things". As John mentioned, it seems likely that some of the VM related memory scanning could be improved. Looking at the fairly intimidating list of things done as part of the image startup I feel sure we could do a lot better - not least by having a smaller simpler better thought out image in the first place.
Even a basic image takes about a second to start (the delay between launching it and seeing something is noticeable); if you actually do anything when you start the image or if you simply have larger images it easily takes longer.
I don't think it would be appropriate to have a window of any sort display when you are starting a Seaside server for example. Or running on an IBM 3090. Or a signet ring.
And which part of "optional" splash screen is so hard to understand? Remove splash.bmp and it's gone.
My *reason* for misunderstanding that is that I simply didn't absorb the (optional). Not a very good *excuse*.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Never do card tricks for the group you play poker with.
tim Rowledge wrote:
On 30-Aug-07, at 8:55 AM, Andreas Raab wrote:
You mean loading the image and relocating pointers is no excuse? Running the startup code, redrawing the screen? No excuses either?
It's a *reason* but not an *excuse*. Yes, there is a load of assorted stuff done as the VM starts up and loads the image (which could take several seconds on some machine/setups) and then as the image starts up. That's the reason(s). The excuse really adds up to "we haven't bothered to improve things". As John mentioned, it seems likely that some of the VM related memory scanning could be improved. Looking at the fairly intimidating list of things done as part of the image startup I feel sure we could do a lot better - not least by having a smaller simpler better thought out image in the first place.
Fix it ;-) In the meantime there is at least *some* feedback that the application has successfully launched. I find it highly disturbing (to say the least) if you don't get any feedback for several seconds when an application launches. The splash screen may not be an optimal solution but it sure as hell beats seeing absolutely nothing.
Cheers, - Andreas
On 30-Aug-07, at 10:46 AM, Andreas Raab wrote:
tim Rowledge wrote:
I feel sure we could do a lot better - not least by having a smaller simpler better thought out image in the first place.
Fix it ;-)
Sure. One million Euros....
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: HBT: Harvest Binary Tree
On Aug 30, 2007, at 10:46 , Andreas Raab wrote:
tim Rowledge wrote:
On 30-Aug-07, at 8:55 AM, Andreas Raab wrote:
You mean loading the image and relocating pointers is no excuse? Running the startup code, redrawing the screen? No excuses either?
It's a *reason* but not an *excuse*. Yes, there is a load of assorted stuff done as the VM starts up and loads the image (which could take several seconds on some machine/setups) and then as the image starts up. That's the reason(s). The excuse really adds up to "we haven't bothered to improve things". As John mentioned, it seems likely that some of the VM related memory scanning could be improved. Looking at the fairly intimidating list of things done as part of the image startup I feel sure we could do a lot better
- not least by having a smaller simpler better thought out image
in the first place.
Fix it ;-) In the meantime there is at least *some* feedback that the application has successfully launched. I find it highly disturbing (to say the least) if you don't get any feedback for several seconds when an application launches. The splash screen may not be an optimal solution but it sure as hell beats seeing absolutely nothing.
There is this idea I discussed on and off with people ... which is having part of the object memory be "static/read-only". Objects in there wouldn't be garbage-collected (ven by a full GC), and writing to them would copy them into regular space. Unfortunately this wouldn't help with start-up time unless we also move to an object table (so oops wouldn't have to be rewritten on start-up).
- Bert -
On 30-Aug-07, at 1:48 PM, Bert Freudenberg wrote:
There is this idea I discussed on and off with people ... which is having part of the object memory be "static/read-only". Objects in there wouldn't be garbage-collected (ven by a full GC), and writing to them would copy them into regular space. Unfortunately this wouldn't help with start-up time unless we also move to an object table (so oops wouldn't have to be rewritten on start-up).
Yah, I talked with Dan about this sort of thing some years ago, having previously done exactly this for the (ancient history!) Active Book vm. There I used a copy on write so that the entire image could be in actual ROM for near instand loading; a patching method allowed the incremental changes to be saved and applied very quickly. Working 'images' were often only a few tens of KB.
The problem is that I've never heard of any way of doing such a mechanism without something that is effectively an OT. With direct pointers we have a problem that altering some object means making a copy of it in 'ram' and updating every object that points to it, requiring a copy and update and GOTO beginning-of-sentence. Basically a vm level system tracer! Somewhere there has to be a level of indirection that starts out in ram and stays there (Active Book vm kept the OT in ram for example) so as to provide a useful stopping point to the trace.
VW has (had?) the PermSpace idea where a large chunk of the image is not garbage collected under normal circumstances, which allows the use of shared memory mapping etc. I'm not at all certain whether that is still useful in OSs more recent than my 1995 experience. It is still ram though and IIRC used the OS level copy-on-write of the relevant pages and the VW sort-of OT in order to work.
Personally I've never had a problem with the idea of object tables. I think they let you do interesting things at modest cost. Certainly I can imagine interesting possibilities for sharing the bulk of an image between many Spoons.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A)bort, R)etry, I)nfluence with large hammer.
tim Rowledge wrote:
Personally I've never had a problem with the idea of object tables. I think they let you do interesting things at modest cost. Certainly I
Yup, being the old fashioned engineer I always preferred the idea of an object table. After all it is late binding ;-)
can imagine interesting possibilities for sharing the bulk of an image between many Spoons.
Imagine the possibilities ;-)
A)bort, R)etry, I)nfluence with large hammer.
Tim's sigline AI struck again...
Michael
Hi Folks -
I've done two interesting improvements to the Win32 VM mostly for production uses. First, fetch the latest Windows VM from:
http://squeakvm.org/win32/release/SqueakVM-Win32-3.10.5-bin.zip
and run it. Aaaahhhh! What a nice splash screen ;-) The reason for the
Any reason the VM seems to be ignoring the -headless option now?
Ramon Leon http://onsmalltalk.com
Hi Ramon -
I've rev-ed the VM to 3.10.6 to address this problem:
http://squeakvm.org/win32/release/SqueakVM-Win32-3.10.6-bin.zip http://squeakvm.org/win32/release/SqueakVM-Win32-3.10.6-src.zip
Cheers, - Andreas
Ramon Leon wrote:
Hi Folks -
I've done two interesting improvements to the Win32 VM mostly for production uses. First, fetch the latest Windows VM from:
http://squeakvm.org/win32/release/SqueakVM-Win32-3.10.5-bin.zip
and run it. Aaaahhhh! What a nice splash screen ;-) The reason for the
Any reason the VM seems to be ignoring the -headless option now?
Ramon Leon http://onsmalltalk.com
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Andreas Raab Sent: Thursday, August 30, 2007 9:51 PM To: The general-purpose Squeak developers list Subject: Re: Win32 VM Update & Request for help
Hi Ramon -
I've rev-ed the VM to 3.10.6 to address this problem:
http://squeakvm.org/win32/release/SqueakVM-Win32-3.10.6-bin.zip http://squeakvm.org/win32/release/SqueakVM-Win32-3.10.6-src.zip
Cheers,
- Andreas
Perfect, thanks. I'll let you know if I run into anything else.
Ramon Leon http://onsmalltalk.com
On Aug 29, 2007, at 10:45 PM, Andreas Raab wrote:
(shame on the Mac VM for delaying window creation without splash screen! ;-)
In the past this was non-trival because the VM had only the concept there was ONE window and it was the squeak main window and it would want to flow events to the image if you interacted with it. Since we migrate to multiple window support it becomes more feasible to do the (still lots more than) 15 minutes work of adding a splash screen. -- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Igor Stasenko -
John M McIntosh -
Michael Rueger -
Ramon Leon -
tim Rowledge