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 <[hidden email]> 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 > > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Andreas.Raab
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; [hidden email]; 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 |
In reply to this post by Andreas.Raab
> 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 |
Ramon Leon wrote:
> Any reason the VM seems to be ignoring the -headless option now? It shouldn't. I'll check it. Cheers, - Andreas |
In reply to this post by Andreas.Raab
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 <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
In reply to this post by Andreas.Raab
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 <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
In reply to this post by Andreas.Raab
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; [hidden email]; 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; [hidden email]; http://www.rowledge.org/tim Never do card tricks for the group you play poker with. |
In reply to this post by timrowledge
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; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: HBT: Harvest Binary Tree |
In reply to this post by Andreas.Raab
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 - |
In reply to this post by Ramon Leon-5
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 > > > |
In reply to this post by Bert Freudenberg
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; [hidden email]; 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 |
In reply to this post by Andreas.Raab
> -----Original Message-----
> From: [hidden email] > [mailto:[hidden email]] 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 |
Free forum by Nabble | Edit this page |