Issue 3595 in pharo: problem starting up with a script on windows

Status: Accepted
Owner: [hidden email]
Labels: Milestone-1.2 Milestone-1.3 Type-ReportDefect

New issue 3595 by [hidden email]: problem starting up with a script  
on windows
http://code.google.com/p/pharo/issues/detail?id=3595

Pharo image: Dev
Pharo core version: <copy from World/System/About>
Virtual machine used: Cog 2316, 2348


There seems to be a problem with starting a Pharo 1.2-based image with an  
initial .st script on Windows.

The problem seems to be in CodeLoader>>installSourceFiles and it is related  
to the contentStream retrieved from the HTTPDownloadRequest being nil. The  
debug log is listed below.

I checked the paths and they are all correct. In fact, if I run the same  
script with a Pharo 1.1.1 image, everything works as expected. I also tried  
to drag and drop the .st script and again, everything works as expected.  
So, it seems that there is some initialization problem.

I managed to debug some more and the problem seems to be introduced by  
System-Download after the version System-Download-StephaneDucasse.51. If  
you try any of the newer version, you should get the error.

I worked on a Windows Server 2008 R2 using a Cog VM (both r2316 and r2348).


Attachments:
        PharoDebug.log  7.8 KB

Updates:
        Labels: Importance-High

Comment #1 on issue 3595 by [hidden email]: problem starting up with  
a script on windows
http://code.google.com/p/pharo/issues/detail?id=3595

Is there nobody that has a Windows to test this issue?

Comment #2 on issue 3595 by [hidden email]: problem starting up  
with a script on windows
http://code.google.com/p/pharo/issues/detail?id=3595

Can confirm this bug:

Pharo 1.1:
    C:\pharo\install10\Pharo.exe C:\pharo\install11\pharo.image c:\Foo.st

works and Pharo 1.2

    C:\pharo\install10\Pharo.exe C:\pharo\core\1.2\PharoCore-1.2.image  
c:\Foo.st

comes up with the error: 'No content to install' in  
CodeLoader>>installSourceFiles.

Updates:
        Cc: stephane.ducasse

Comment #3 on issue 3595 by [hidden email]: problem starting up  
with a script on windows
http://code.google.com/p/pharo/issues/detail?id=3595

If you debug both you will notice that ProjectLauncher>>startUpAfterLogin  
has changed. First there is a check if the given argument (the script  
name/location)
has a protocol like http, file or ftp.
If not then the url is "manually" adjusted to file-protocol in Pharo 1.1

      isUrl ifFalse:[scriptName := 'file:',scriptName]].

So I get 'file:c:\Foo.st' in Pharo 1.1. here and my Script works.

In Pharo 1.2 this is replaced by some URI magic that allows for relative  
paths:

              "Allow for ../dir/scriptName arguments"
              scriptName := (FileDirectory default uri
                                resolveRelativeURI: scriptName) asString]]]

In my example that just returns 'c:\Foo.st' (since it is now relative)
which results in not loading the stuff if you give an absolute path.

Note that there is also a comment:
    "Allow for ../dir/scriptName arguments"

I think this was DONE TO NOW SUPPORT RELATIVE PATHS TOO - maybe for Coral  
scripting system.

If you want to give an absolute path you have to use the file protocol
since otherwise it is interpreted as a relative path. That is the effect of  
the change

So
C:\pharo\core\1.2\Pharo.exe C:\pharo\core\1.2\PharoCore-1.2.image  
file:c:\Foo.st

works without a problem.

Since relative paths are now supported too you can also write:

C:\pharo\core\1.2\Pharo.exe  
C:\pharo\core\1.2\PharoCore-1.2.image ../../../../c:\Foo.st

So I think this is not a bug, mainly a "not yet documented new feature".

Updates:
        Status: WontFix

Comment #4 on issue 3595 by [hidden email]: problem starting up  
with a script on windows
http://code.google.com/p/pharo/issues/detail?id=3595

We should close it since it is not a bug

Comment #5 on issue 3595 by [hidden email]: problem starting up  
with a script on windows
http://code.google.com/p/pharo/issues/detail?id=3595

One bad smell though ... by using "FileDirectory default" the script is  
looked up RELATIVE TO THE IMAGE PATH not the current directory I'm in in  
the console shell.

But this is a problem of Coral then and a minus compared to other scripting  
languages...