behavior issues with windows vm?

 
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 <[hidden email]>   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:

 
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 <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

 
Try a full path.

- Bert -

Am 19.06.2009 um 08:30 schrieb John M McIntosh <[hidden email]
 >:

>> StandardFileStream forceNewFileNamed: 'ConflictChecker.log'.
>

 
John M McIntosh wrote:
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 <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================