Given a Pharo0.1Core-10204.image
with the following changes to collect startup times in SystemDictionary>>send: toClassesNamedIn: with:
Seem simple?
I hacked usage of FilePackage log: because it was simple and wanted to record times & progress to a file in the VM directory.
But the windows VM coughs up the dialog saying the file does not exist, create a new file or choose another file. This does not happen on mac or linux?
The file is not created via the hopeful code in the modified FilePackage>>logFileStream
It does not write a debug log, does not allow mouse clicks, keyboard entry etc, in general it's obvious to any input activity at this point.
Now I wondering here if sandboxing for etoys is leaping in and being nasty? Is there some magical call that is done later in the startup: processing that ok's the ability to create files? And that I *know* later after system startup I *can* invoke FilePackage log: 'foo' and we are happy if I rip out the file access in log:
Oh and I'm here because WikiServer wouldn't start on Windows, well because I've ripped out lots of eToy stuff, like the the eToy startup security sandboxing which isn't needed on the iPhone.
changes to base 10204 image
SystemDictionary>>send: startUpOrShutDown toClassesNamedIn: startUpOrShutDownList with: argument "Send the message #startUp: or #shutDown: to each class named in the list. The argument indicates if the system is about to quit (for #shutDown:) or if the image is resuming (for #startUp:). If any name cannot be found, then remove it from the list."
| removals class t6 t7 | removals := OrderedCollection new. startUpOrShutDownList do: [:name | class := self at: name ifAbsent: [nil]. class == nil ifTrue: [removals add: name] ifFalse: [class isInMemory ifTrue: [t6 := Time millisecondClockValue. class perform: startUpOrShutDown with: argument. startUpOrShutDown = #startUp: ifTrue: [t7 := class printString , ' ' , (Time millisecondClockValue - t6) printString. FilePackage log: t7]]]].
"Remove any obsolete entries, but after the iteration" startUpOrShutDownList removeAll: removals
FilePackage>>logFileStream LogFileStream ifNil: [LogFileStream := StandardFileStream forceNewFileNamed: 'ConflictChecker.log'. LogFileStream setToEnd]. LogFileStream closed ifTrue: [LogFileStream reopen. LogFileStream setToEnd]. ^ LogFileStream
Oh at shutdown: time we need to do a FilePackage closeLog, where that happens is an exercise for the reader.
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Hi John -
I fail to see where this is an issue with the Windows VM. Can you elaborate?
Cheers, - Andreas
John M McIntosh wrote:
Given a Pharo0.1Core-10204.image
with the following changes to collect startup times in SystemDictionary>>send: toClassesNamedIn: with:
Seem simple?
I hacked usage of FilePackage log: because it was simple and wanted to record times & progress to a file in the VM directory.
But the windows VM coughs up the dialog saying the file does not exist, create a new file or choose another file. This does not happen on mac or linux?
The file is not created via the hopeful code in the modified FilePackage>>logFileStream
It does not write a debug log, does not allow mouse clicks, keyboard entry etc, in general it's obvious to any input activity at this point.
Now I wondering here if sandboxing for etoys is leaping in and being nasty? Is there some magical call that is done later in the startup: processing that ok's the ability to create files? And that I *know* later after system startup I *can* invoke FilePackage log: 'foo' and we are happy if I rip out the file access in log:
Oh and I'm here because WikiServer wouldn't start on Windows, well because I've ripped out lots of eToy stuff, like the the eToy startup security sandboxing which isn't needed on the iPhone.
changes to base 10204 image
SystemDictionary>>send: startUpOrShutDown toClassesNamedIn: startUpOrShutDownList with: argument "Send the message #startUp: or #shutDown: to each class named in the list. The argument indicates if the system is about to quit (for #shutDown:) or if the image is resuming (for #startUp:). If any name cannot be found, then remove it from the list."
| removals class t6 t7 | removals := OrderedCollection new. startUpOrShutDownList do: [:name | class := self at: name ifAbsent: [nil]. class == nil ifTrue: [removals add: name] ifFalse: [class isInMemory ifTrue: [t6 := Time millisecondClockValue. class perform: startUpOrShutDown with: argument. startUpOrShutDown = #startUp: ifTrue: [t7 := class printString , ' ' ,
(Time millisecondClockValue - t6) printString. FilePackage log: t7]]]].
"Remove any obsolete entries, but after the iteration" startUpOrShutDownList removeAll: removals
FilePackage>>logFileStream LogFileStream ifNil: [LogFileStream := StandardFileStream forceNewFileNamed: 'ConflictChecker.log'. LogFileStream setToEnd]. LogFileStream closed ifTrue: [LogFileStream reopen. LogFileStream setToEnd]. ^ LogFileStream
Oh at shutdown: time we need to do a FilePackage closeLog, where that happens is an exercise for the reader.
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
This fails on windows VM
StandardFileStream forceNewFileNamed: 'ConflictChecker.log'.
if you invoke in SystemDictionary>>send: toClassesNamedIn:with: at startup time
but it works on mac/linux
after all startup runs then
StandardFileStream forceNewFileNamed: 'ConflictChecker.log'.
works on windows
why it fails is a bit hard to track since the failure results in a image Ui that does not respond to keyboard, clicks etc.
No doubt it is because FileDirectory>>startUp has not run yet.
Of course what I'm tracking is why my WikiServer image does not show the window when you start it. Attempting to add the traceing to log file, which then causes the walkback then does show the window.
I'm sure at some point here I'll get far enough along to see what window specific behaviour is causing failure in the startup: processing.
On 18-Jun-09, at 11:06 PM, Andreas Raab wrote:
Hi John -
I fail to see where this is an issue with the Windows VM. Can you elaborate?
Cheers,
- Andreas
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
John M McIntosh wrote:
This fails on windows VM
StandardFileStream forceNewFileNamed: 'ConflictChecker.log'.
if you invoke in SystemDictionary>>send: toClassesNamedIn:with: at startup time
but it works on mac/linux
after all startup runs then
StandardFileStream forceNewFileNamed: 'ConflictChecker.log'.
works on windows
why it fails is a bit hard to track since the failure results in a image Ui that does not respond to keyboard, clicks etc.
No doubt it is because FileDirectory>>startUp has not run yet.
Right. So why is this a Windows VM issue? Perhaps you should call FileDirectory startUp before doing file operations?!
Of course what I'm tracking is why my WikiServer image does not show the window when you start it. Attempting to add the traceing to log file, which then causes the walkback then does show the window.
I'm sure at some point here I'll get far enough along to see what window specific behaviour is causing failure in the startup: processing.
My suspicion would be that this is because you saved the image on Mac/Unix thus the ActiveDirectoryClass is set to UnixFileDir and consequently fails on Windows. If you'd save the image on Windows it will likely show the same behavior on Mac/Unix. I still fail to see what this has to do with the Windows VM - file and directory operations *will* fail if unless you call FileDirectory>>startUp.
Cheers, - Andreas
Ok to solve this I added to SmalltalkImage>.snapshot:andQuit:embedded:
who := Processor activeProcess. [| messageStrm| (Delay forMilliseconds: 500) wait. who suspend. messageStrm := WriteStream on: (String new: 1500). who suspendedContext errorReportOn: messageStrm. Clipboard default primitiveClipboardText: messageStrm contents. who resume ] forkAt: Processor lowIOPriority.
This showed that yes if you delete the class DosFileDirectory class, why Window's won't love you...
On 19-Jun-09, at 1:28 AM, Andreas Raab wrote:
My suspicion would be that this is because you saved the image on Mac/Unix thus the ActiveDirectoryClass is set to UnixFileDir and consequently fails on Windows. If you'd save the image on Windows it will likely show the same behavior on Mac/Unix. I still fail to see what this has to do with the Windows VM - file and directory operations *will* fail if unless you call FileDirectory>>startUp.
Cheers,
- Andreas
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
vm-dev@lists.squeakfoundation.org