last win32 VM

Sebastian Sastre wrote on pharo-project list:
>I've found this weird: downloaded the vm for win32 from pharo site and is
>happening that it complies about no disk in drive G: every time I open an >image.
>I've press continue a couple of times and the image opens normally.

I would guess it is not the newest VM, but the code in "FreeTypeFontProvider>>guessWindowsFontFolderPath"
running through all drives and F: is the last mapped drive on your system.
Therefore it crashes when accessing drive G:

On Vista this gives you a nice Win32 Exception. Maybe the FreeType code should switch to another way to get the windows system and font folder  
(using Registry, Win32 API, ... - but there is no FFI by default).  

However, quickfix is to disable the update in FreeTypeFontProvider>>startUp:

So it is not a VM issue.

Bye
Torsten





--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Torsten,

It could be up to the VM if we made it that way.  There is a function call to get the system directory, and the VM can "just do that" vs. the image needing to have access to FFI/Alien to do so.  Perhaps the other VMs could add something analogous, or just answer an empty string, vm path, whatever if their hosts are better designed than Windows (not that such a thing is imaginable... queue throat clearing .wav).

Bill




-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Torsten Bergmann
Sent: Saturday, March 07, 2009 8:29 PM
To: [hidden email]; [hidden email]
Subject: [Pharo-project] last win32 VM

Sebastian Sastre wrote on pharo-project list:
>I've found this weird: downloaded the vm for win32 from pharo site and is
>happening that it complies about no disk in drive G: every time I open an >image.
>I've press continue a couple of times and the image opens normally.

I would guess it is not the newest VM, but the code in "FreeTypeFontProvider>>guessWindowsFontFolderPath"
running through all drives and F: is the last mapped drive on your system.
Therefore it crashes when accessing drive G:

On Vista this gives you a nice Win32 Exception. Maybe the FreeType code should switch to another way to get the windows system and font folder  
(using Registry, Win32 API, ... - but there is no FFI by default).  

However, quickfix is to disable the update in FreeTypeFontProvider>>startUp:

So it is not a VM issue.

Bye
Torsten





--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Schwab,Wilhelm K wrote:
> Torsten,
>
> It could be up to the VM if we made it that way.  There is a function
> call to get the system directory, and the VM can "just do that" vs.
> the image needing to have access to FFI/Alien to do so.  Perhaps the
> other VMs could add something analogous, or just answer an empty
> string, vm path, whatever if their hosts are better designed than
> Windows (not that such a thing is imaginable... queue throat clearing
> .wav).

We could add that as part of the OSPlatform package and add a plugin
returning platform specific "stuff".
In Sophie we had packaged access to platform specific paths in an extra
package using mostly FFI, but a plugin would be more sensible in the
long run.

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Michael,

So you are saying that rather than put the call in the VM itself, it would go in a plugin that does the right things for the various platforms?  Is there a plugin per platform, or one that grows to cover them all??

How am I doing?  If I'm at all close, it sounds like a winner.  There are those who do not want too much reliance on FFI, and I see their point, um, to a point.  The idea of being able to disable FFI from the command line is interesting from a security perspective, so a plugin seems a good way to go.

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Rueger
Sent: Saturday, March 07, 2009 11:46 PM
To: [hidden email]
Subject: Re: [Pharo-project] last win32 VM

Schwab,Wilhelm K wrote:
> Torsten,
>
> It could be up to the VM if we made it that way.  There is a function
> call to get the system directory, and the VM can "just do that" vs.
> the image needing to have access to FFI/Alien to do so.  Perhaps the
> other VMs could add something analogous, or just answer an empty
> string, vm path, whatever if their hosts are better designed than
> Windows (not that such a thing is imaginable... queue throat clearing
> .wav).

We could add that as part of the OSPlatform package and add a plugin
returning platform specific "stuff".
In Sophie we had packaged access to platform specific paths in an extra
package using mostly FFI, but a plugin would be more sensible in the
long run.

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Schwab,Wilhelm K wrote:
> Michael,
>
> So you are saying that rather than put the call in the VM itself, it
> would go in a plugin that does the right things for the various
> platforms?  Is there a plugin per platform, or one that grows to
> cover them all??
>
> How am I doing?  If I'm at all close, it sounds like a winner.  There

Close :-)
One plugin with support for the different platforms (see locale plugin
for a similar solution).

The plugin could support calls like primTempDirectory,
primSystemFontFolder(s), primUserDirectory etc. or other platform
specific calls (can't think of one right now ;-) ).

As I said, we are doing this in Sophie with FFI in Files-Locations,
making Sophie a "good citizen" on each platform instead of using "C:\My
Squeak" or the VM/image directory.

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sounds good.


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Rueger
Sent: Sunday, March 08, 2009 1:05 AM
To: [hidden email]
Subject: Re: [Pharo-project] last win32 VM

Schwab,Wilhelm K wrote:
> Michael,
>
> So you are saying that rather than put the call in the VM itself, it
> would go in a plugin that does the right things for the various
> platforms?  Is there a plugin per platform, or one that grows to
> cover them all??
>
> How am I doing?  If I'm at all close, it sounds like a winner.  There

Close :-)
One plugin with support for the different platforms (see locale plugin
for a similar solution).

The plugin could support calls like primTempDirectory,
primSystemFontFolder(s), primUserDirectory etc. or other platform
specific calls (can't think of one right now ;-) ).

As I said, we are doing this in Sophie with FFI in Files-Locations,
making Sophie a "good citizen" on each platform instead of using "C:\My
Squeak" or the VM/image directory.

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project