FileURL don't works properly on windows

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

FileURL don't works properly on windows

Igor Stasenko
Try:

(FileDirectory default / 'foo') asUrl retrieveContents

--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: FileURL don't works properly on windows

Marcus Denker-4

On Mar 27, 2012, at 4:05 PM, Igor Stasenko wrote:

> Try:
>
> (FileDirectory default / 'foo') asUrl retrieveContents


Yes, we need to really do a pass over the Url... there is Url (from old Squeak).
The there is URI, a package from Impara that we wanted to replace Url in Squeak 3.9
but development stopped when Impara could not contribute to Squeak anymore (due to politics...).

Then there is ZnUrl...

Definitly needs cleanup. We need one model for Url that works.

        Marcus


--
Marcus Denker -- http://marcusdenker.de


Reply | Threaded
Open this post in threaded view
|

Re: FileURL don't works properly on windows

Gary Chambers-4
+1 for that.
Though I try to use URLs (URIs) have to draw a line and hit FS directly at a
certain point...

Regards, Gary

----- Original Message -----
From: "Marcus Denker" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, March 27, 2012 4:17 PM
Subject: Re: [Pharo-project] FileURL don't works properly on windows



On Mar 27, 2012, at 4:05 PM, Igor Stasenko wrote:

> Try:
>
> (FileDirectory default / 'foo') asUrl retrieveContents


Yes, we need to really do a pass over the Url... there is Url (from old
Squeak).
The there is URI, a package from Impara that we wanted to replace Url in
Squeak 3.9
but development stopped when Impara could not contribute to Squeak anymore
(due to politics...).

Then there is ZnUrl...

Definitly needs cleanup. We need one model for Url that works.

Marcus


--
Marcus Denker -- http://marcusdenker.de



Reply | Threaded
Open this post in threaded view
|

Re: FileURL don't works properly on windows

philippeback
In reply to this post by Marcus Denker-4

I would vote for Zn to deal with it all...

No so simple I know but...

Le 27 mars 2012 17:18, "Marcus Denker" <[hidden email]> a écrit :

On Mar 27, 2012, at 4:05 PM, Igor Stasenko wrote:

> Try:
>
> (FileDirectory default / 'foo') asUrl retrieveContents


Yes, we need to really do a pass over the Url... there is Url (from old Squeak).
The there is URI, a package from Impara that we wanted to replace Url in Squeak 3.9
but development stopped when Impara could not contribute to Squeak anymore (due to politics...).

Then there is ZnUrl...

Definitly needs cleanup. We need one model for Url that works.

       Marcus


--
Marcus Denker -- http://marcusdenker.de


Reply | Threaded
Open this post in threaded view
|

Re: FileURL don't works properly on windows

Igor Stasenko
In reply to this post by Marcus Denker-4
this part is closely related to command-line arguments handling..

on windows things, which expected to work, like:

vm image.image <pathToScript>.st

fails to find the script, because it messing up with back/forward
slashes in path
and at the end it transforms an input into escaped slashes, which is
of course cannot be found in file system...

On 27 March 2012 17:17, Marcus Denker <[hidden email]> wrote:

>
> On Mar 27, 2012, at 4:05 PM, Igor Stasenko wrote:
>
>> Try:
>>
>> (FileDirectory default / 'foo') asUrl retrieveContents
>
>
> Yes, we need to really do a pass over the Url... there is Url (from old Squeak).
> The there is URI, a package from Impara that we wanted to replace Url in Squeak 3.9
> but development stopped when Impara could not contribute to Squeak anymore (due to politics...).
>
> Then there is ZnUrl...
>
> Definitly needs cleanup. We need one model for Url that works.
>
>        Marcus
>
>
> --
> Marcus Denker -- http://marcusdenker.de
>
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: FileURL don't works properly on windows

Igor Stasenko
In reply to this post by philippeback
On 27 March 2012 17:59, [hidden email] <[hidden email]> wrote:
> I would vote for Zn to deal with it all...
>
The problem is in FileUrl,
which is related to different path encoding scheme on windows (use
drive letter(s), and back slashes instead of normal ones)..
i'm not sure if Zinc can help there, because its urls mostly for
http.. if i'm not mistaken.

> No so simple I know but...
>
> Le 27 mars 2012 17:18, "Marcus Denker" <[hidden email]> a écrit :
>
>>
>> On Mar 27, 2012, at 4:05 PM, Igor Stasenko wrote:
>>
>> > Try:
>> >
>> > (FileDirectory default / 'foo') asUrl retrieveContents
>>
>>
>> Yes, we need to really do a pass over the Url... there is Url (from old
>> Squeak).
>> The there is URI, a package from Impara that we wanted to replace Url in
>> Squeak 3.9
>> but development stopped when Impara could not contribute to Squeak anymore
>> (due to politics...).
>>
>> Then there is ZnUrl...
>>
>> Definitly needs cleanup. We need one model for Url that works.
>>
>>        Marcus
>>
>>
>> --
>> Marcus Denker -- http://marcusdenker.de
>>
>>
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: FileURL don't works properly on windows

philippeback

True.

The situation isn't any better in Java or PHP BTW.

Tcl does a bit of effort to get there tough. / for everything and it gets translated right.

Tcl and Smalltalk: lovely homoiconic languages of art  someone can master.

Le 27 mars 2012 18:08, "Igor Stasenko" <[hidden email]> a écrit :
On 27 March 2012 17:59, [hidden email] <[hidden email]> wrote:
> I would vote for Zn to deal with it all...
>
The problem is in FileUrl,
which is related to different path encoding scheme on windows (use
drive letter(s), and back slashes instead of normal ones)..
i'm not sure if Zinc can help there, because its urls mostly for
http.. if i'm not mistaken.

> No so simple I know but...
>
> Le 27 mars 2012 17:18, "Marcus Denker" <[hidden email]> a écrit :
>
>>
>> On Mar 27, 2012, at 4:05 PM, Igor Stasenko wrote:
>>
>> > Try:
>> >
>> > (FileDirectory default / 'foo') asUrl retrieveContents
>>
>>
>> Yes, we need to really do a pass over the Url... there is Url (from old
>> Squeak).
>> The there is URI, a package from Impara that we wanted to replace Url in
>> Squeak 3.9
>> but development stopped when Impara could not contribute to Squeak anymore
>> (due to politics...).
>>
>> Then there is ZnUrl...
>>
>> Definitly needs cleanup. We need one model for Url that works.
>>
>>        Marcus
>>
>>
>> --
>> Marcus Denker -- http://marcusdenker.de
>>
>>
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: FileURL don't works properly on windows

Marcus Denker-4
In reply to this post by Marcus Denker-4

On Mar 27, 2012, at 6:06 PM, Igor Stasenko wrote:

> this part is closely related to command-line arguments handling..
>
> on windows things, which expected to work, like:
>
> vm image.image <pathToScript>.st
>
> fails to find the script, because it messing up with back/forward
> slashes in path
> and at the end it transforms an input into escaped slashes, which is
> of course cannot be found in file system...


right now we use Urls there because it supports to add URL as a "file".

vm imageimage http://myscript.com/phato.st

I personally think we should remove that. If you want to load a file via the network, just
write a local script that does that.

If we remove the network support for script parameters, we will directly solve that problem.
(and we simplify the whole startup logic, and we make the startup not depend on networking).

        http://code.google.com/p/pharo/issues/detail?id=4057

        Marcus


--
Marcus Denker -- http://marcusdenker.de


Reply | Threaded
Open this post in threaded view
|

Re: FileURL don't works properly on windows

Igor Stasenko
On 27 March 2012 18:18, Marcus Denker <[hidden email]> wrote:

>
> On Mar 27, 2012, at 6:06 PM, Igor Stasenko wrote:
>
>> this part is closely related to command-line arguments handling..
>>
>> on windows things, which expected to work, like:
>>
>> vm image.image <pathToScript>.st
>>
>> fails to find the script, because it messing up with back/forward
>> slashes in path
>> and at the end it transforms an input into escaped slashes, which is
>> of course cannot be found in file system...
>
>
> right now we use Urls there because it supports to add URL as a "file".
>
> vm imageimage http://myscript.com/phato.st
>
> I personally think we should remove that. If you want to load a file via the network, just
> write a local script that does that.
>
> If we remove the network support for script parameters, we will directly solve that problem.
> (and we simplify the whole startup logic, and we make the startup not depend on networking).
>
>        http://code.google.com/p/pharo/issues/detail?id=4057
>
>        Marcus
>
agree.. this thing is a bit overengineeeeered.
but in overall it is cool to have, unless it breaks a most basic usage
: hey ... a stupid file name passed as an argument!

we can remove it, of course, but it won't make a FileURL a bit less broken..
since things like that:

'c:\myfile.txt' asURL retrieveContents still won't work.
we should cover it by tests btw, since now we have windows..
but in order to run any test(s) we should fix this thing first :)

>
> --
> Marcus Denker -- http://marcusdenker.de
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: FileURL don't works properly on windows

Gary Chambers-4
Give filesystem disparities I'd personally be happy with

file://Pharo/xyz.abc

resolving to

C:\Pharo\xyz.abc

on Windows...

Regards, Gary

----- Original Message -----
From: "Igor Stasenko" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, March 27, 2012 6:41 PM
Subject: Re: [Pharo-project] FileURL don't works properly on windows


On 27 March 2012 18:18, Marcus Denker <[hidden email]> wrote:

>
> On Mar 27, 2012, at 6:06 PM, Igor Stasenko wrote:
>
>> this part is closely related to command-line arguments handling..
>>
>> on windows things, which expected to work, like:
>>
>> vm image.image <pathToScript>.st
>>
>> fails to find the script, because it messing up with back/forward
>> slashes in path
>> and at the end it transforms an input into escaped slashes, which is
>> of course cannot be found in file system...
>
>
> right now we use Urls there because it supports to add URL as a "file".
>
> vm imageimage http://myscript.com/phato.st
>
> I personally think we should remove that. If you want to load a file via
> the network, just
> write a local script that does that.
>
> If we remove the network support for script parameters, we will directly
> solve that problem.
> (and we simplify the whole startup logic, and we make the startup not
> depend on networking).
>
> http://code.google.com/p/pharo/issues/detail?id=4057
>
> Marcus
>
agree.. this thing is a bit overengineeeeered.
but in overall it is cool to have, unless it breaks a most basic usage
: hey ... a stupid file name passed as an argument!

we can remove it, of course, but it won't make a FileURL a bit less broken..
since things like that:

'c:\myfile.txt' asURL retrieveContents still won't work.
we should cover it by tests btw, since now we have windows..
but in order to run any test(s) we should fix this thing first :)

>
> --
> Marcus Denker -- http://marcusdenker.de
>



--
Best regards,
Igor Stasenko.


Reply | Threaded
Open this post in threaded view
|

Re: FileURL don't works properly on windows

Gary Chambers-4
In reply to this post by Igor Stasenko
Maybe an extra / there... else relative etc.

Regards, Gary

----- Original Message -----
From: "Igor Stasenko" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, March 27, 2012 6:41 PM
Subject: Re: [Pharo-project] FileURL don't works properly on windows


On 27 March 2012 18:18, Marcus Denker <[hidden email]> wrote:

>
> On Mar 27, 2012, at 6:06 PM, Igor Stasenko wrote:
>
>> this part is closely related to command-line arguments handling..
>>
>> on windows things, which expected to work, like:
>>
>> vm image.image <pathToScript>.st
>>
>> fails to find the script, because it messing up with back/forward
>> slashes in path
>> and at the end it transforms an input into escaped slashes, which is
>> of course cannot be found in file system...
>
>
> right now we use Urls there because it supports to add URL as a "file".
>
> vm imageimage http://myscript.com/phato.st
>
> I personally think we should remove that. If you want to load a file via
> the network, just
> write a local script that does that.
>
> If we remove the network support for script parameters, we will directly
> solve that problem.
> (and we simplify the whole startup logic, and we make the startup not
> depend on networking).
>
> http://code.google.com/p/pharo/issues/detail?id=4057
>
> Marcus
>
agree.. this thing is a bit overengineeeeered.
but in overall it is cool to have, unless it breaks a most basic usage
: hey ... a stupid file name passed as an argument!

we can remove it, of course, but it won't make a FileURL a bit less broken..
since things like that:

'c:\myfile.txt' asURL retrieveContents still won't work.
we should cover it by tests btw, since now we have windows..
but in order to run any test(s) we should fix this thing first :)

>
> --
> Marcus Denker -- http://marcusdenker.de
>



--
Best regards,
Igor Stasenko.


Reply | Threaded
Open this post in threaded view
|

Re: FileURL don't works properly on windows

Igor Stasenko
In reply to this post by Gary Chambers-4
On 27 March 2012 19:50, Gary Chambers <[hidden email]> wrote:
> Give filesystem disparities I'd personally be happy with
>
> file://Pharo/xyz.abc
>
> resolving to
>
> C:\Pharo\xyz.abc
>
> on Windows...

unless you meant

D:\Pharo\xyz.abc

:)
No. I don't like such implicit cleverness. Things should be stupid. No
magic. If it works it should work. If it doesn't , it should explain
why.
And let users solve the issue.
But when system tries to play a wizard which can read people's mind,
this is road to nowhere.

>
> Regards, Gary
>
> ----- Original Message ----- From: "Igor Stasenko" <[hidden email]>
> To: <[hidden email]>
> Sent: Tuesday, March 27, 2012 6:41 PM
>
> Subject: Re: [Pharo-project] FileURL don't works properly on windows
>
>
> On 27 March 2012 18:18, Marcus Denker <[hidden email]> wrote:
>>
>>
>> On Mar 27, 2012, at 6:06 PM, Igor Stasenko wrote:
>>
>>> this part is closely related to command-line arguments handling..
>>>
>>> on windows things, which expected to work, like:
>>>
>>> vm image.image <pathToScript>.st
>>>
>>> fails to find the script, because it messing up with back/forward
>>> slashes in path
>>> and at the end it transforms an input into escaped slashes, which is
>>> of course cannot be found in file system...
>>
>>
>>
>> right now we use Urls there because it supports to add URL as a "file".
>>
>> vm imageimage http://myscript.com/phato.st
>>
>> I personally think we should remove that. If you want to load a file via
>> the network, just
>> write a local script that does that.
>>
>> If we remove the network support for script parameters, we will directly
>> solve that problem.
>> (and we simplify the whole startup logic, and we make the startup not
>> depend on networking).
>>
>> http://code.google.com/p/pharo/issues/detail?id=4057
>>
>> Marcus
>>
> agree.. this thing is a bit overengineeeeered.
> but in overall it is cool to have, unless it breaks a most basic usage
> : hey ... a stupid file name passed as an argument!
>
> we can remove it, of course, but it won't make a FileURL a bit less broken..
> since things like that:
>
> 'c:\myfile.txt' asURL retrieveContents still won't work.
> we should cover it by tests btw, since now we have windows..
> but in order to run any test(s) we should fix this thing first :)
>
>>
>> --
>> Marcus Denker -- http://marcusdenker.de
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: FileURL don't works properly on windows

Sven Van Caekenberghe
In reply to this post by Igor Stasenko

On 27 Mar 2012, at 18:07, Igor Stasenko wrote:

> The problem is in FileUrl,
> which is related to different path encoding scheme on windows (use
> drive letter(s), and back slashes instead of normal ones)..
> i'm not sure if Zinc can help there, because its urls mostly for
> http.. if i'm not mistaken.

Yes, ZnUrl is HTTP(S) specific and does not include a number of aspect that are in URL like uername and password.

File URLs (http://en.wikipedia.org/wiki/File_URI_scheme) are more complicated because of platform differences, the way things seem to be on Windows is a bit scary, for me at least.

Cleaning up and/or unifying the URL/URI mess would be a nice project.

>> No so simple I know but...
>>
>> Le 27 mars 2012 17:18, "Marcus Denker" <[hidden email]> a écrit :
>>
>>>
>>> On Mar 27, 2012, at 4:05 PM, Igor Stasenko wrote:
>>>
>>>> Try:
>>>>
>>>> (FileDirectory default / 'foo') asUrl retrieveContents
>>>
>>>
>>> Yes, we need to really do a pass over the Url... there is Url (from old
>>> Squeak).
>>> The there is URI, a package from Impara that we wanted to replace Url in
>>> Squeak 3.9
>>> but development stopped when Impara could not contribute to Squeak anymore
>>> (due to politics...).
>>>
>>> Then there is ZnUrl...
>>>
>>> Definitly needs cleanup. We need one model for Url that works.
>>>
>>>        Marcus
>>>
>>>
>>> --
>>> Marcus Denker -- http://marcusdenker.de
>>>
>>>
>>
>
>
>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: FileURL don't works properly on windows

Gary Chambers-4
In reply to this post by Igor Stasenko
Then again... if you want cleverness you do a link on archaic filesystems
that can't do a proper root...

Personally I'd like a URI/URL to work crossly on multiple platforms in a
reasonable manner.
Otherwise it is a pain to work with Linux/Windows transparently.

Regards, Gary

----- Original Message -----
From: "Igor Stasenko" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, March 27, 2012 6:55 PM
Subject: Re: [Pharo-project] FileURL don't works properly on windows


> On 27 March 2012 19:50, Gary Chambers <[hidden email]> wrote:
>> Give filesystem disparities I'd personally be happy with
>>
>> file://Pharo/xyz.abc
>>
>> resolving to
>>
>> C:\Pharo\xyz.abc
>>
>> on Windows...
>
> unless you meant
>
> D:\Pharo\xyz.abc
>
> :)
> No. I don't like such implicit cleverness. Things should be stupid. No
> magic. If it works it should work. If it doesn't , it should explain
> why.
> And let users solve the issue.
> But when system tries to play a wizard which can read people's mind,
> this is road to nowhere.
>
>>
>> Regards, Gary
>>
>> ----- Original Message ----- From: "Igor Stasenko" <[hidden email]>
>> To: <[hidden email]>
>> Sent: Tuesday, March 27, 2012 6:41 PM
>>
>> Subject: Re: [Pharo-project] FileURL don't works properly on windows
>>
>>
>> On 27 March 2012 18:18, Marcus Denker <[hidden email]> wrote:
>>>
>>>
>>> On Mar 27, 2012, at 6:06 PM, Igor Stasenko wrote:
>>>
>>>> this part is closely related to command-line arguments handling..
>>>>
>>>> on windows things, which expected to work, like:
>>>>
>>>> vm image.image <pathToScript>.st
>>>>
>>>> fails to find the script, because it messing up with back/forward
>>>> slashes in path
>>>> and at the end it transforms an input into escaped slashes, which is
>>>> of course cannot be found in file system...
>>>
>>>
>>>
>>> right now we use Urls there because it supports to add URL as a "file".
>>>
>>> vm imageimage http://myscript.com/phato.st
>>>
>>> I personally think we should remove that. If you want to load a file via
>>> the network, just
>>> write a local script that does that.
>>>
>>> If we remove the network support for script parameters, we will directly
>>> solve that problem.
>>> (and we simplify the whole startup logic, and we make the startup not
>>> depend on networking).
>>>
>>> http://code.google.com/p/pharo/issues/detail?id=4057
>>>
>>> Marcus
>>>
>> agree.. this thing is a bit overengineeeeered.
>> but in overall it is cool to have, unless it breaks a most basic usage
>> : hey ... a stupid file name passed as an argument!
>>
>> we can remove it, of course, but it won't make a FileURL a bit less
>> broken..
>> since things like that:
>>
>> 'c:\myfile.txt' asURL retrieveContents still won't work.
>> we should cover it by tests btw, since now we have windows..
>> but in order to run any test(s) we should fix this thing first :)
>>
>>>
>>> --
>>> Marcus Denker -- http://marcusdenker.de
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>


Reply | Threaded
Open this post in threaded view
|

Re: FileURL don't works properly on windows

Igor Stasenko
On 27 March 2012 20:28, Gary Chambers <[hidden email]> wrote:
> Then again... if you want cleverness you do a link on archaic filesystems
> that can't do a proper root...
>
> Personally I'd like a URI/URL to work crossly on multiple platforms in a
> reasonable manner.
> Otherwise it is a pain to work with Linux/Windows transparently.
>
i am not opposed to have uniform url(s).
just dont like ambiguous stuff.

>
> Regards, Gary
>
> ----- Original Message ----- From: "Igor Stasenko" <[hidden email]>
> To: <[hidden email]>
> Sent: Tuesday, March 27, 2012 6:55 PM
>
> Subject: Re: [Pharo-project] FileURL don't works properly on windows
>
>
>> On 27 March 2012 19:50, Gary Chambers <[hidden email]> wrote:
>>>
>>> Give filesystem disparities I'd personally be happy with
>>>
>>> file://Pharo/xyz.abc
>>>
>>> resolving to
>>>
>>> C:\Pharo\xyz.abc
>>>
>>> on Windows...
>>
>>
>> unless you meant
>>
>> D:\Pharo\xyz.abc
>>
>> :)
>> No. I don't like such implicit cleverness. Things should be stupid. No
>> magic. If it works it should work. If it doesn't , it should explain
>> why.
>> And let users solve the issue.
>> But when system tries to play a wizard which can read people's mind,
>> this is road to nowhere.
>>
>>>
>>> Regards, Gary
>>>
>>> ----- Original Message ----- From: "Igor Stasenko" <[hidden email]>
>>> To: <[hidden email]>
>>> Sent: Tuesday, March 27, 2012 6:41 PM
>>>
>>> Subject: Re: [Pharo-project] FileURL don't works properly on windows
>>>
>>>
>>> On 27 March 2012 18:18, Marcus Denker <[hidden email]> wrote:
>>>>
>>>>
>>>>
>>>> On Mar 27, 2012, at 6:06 PM, Igor Stasenko wrote:
>>>>
>>>>> this part is closely related to command-line arguments handling..
>>>>>
>>>>> on windows things, which expected to work, like:
>>>>>
>>>>> vm image.image <pathToScript>.st
>>>>>
>>>>> fails to find the script, because it messing up with back/forward
>>>>> slashes in path
>>>>> and at the end it transforms an input into escaped slashes, which is
>>>>> of course cannot be found in file system...
>>>>
>>>>
>>>>
>>>>
>>>> right now we use Urls there because it supports to add URL as a "file".
>>>>
>>>> vm imageimage http://myscript.com/phato.st
>>>>
>>>> I personally think we should remove that. If you want to load a file via
>>>> the network, just
>>>> write a local script that does that.
>>>>
>>>> If we remove the network support for script parameters, we will directly
>>>> solve that problem.
>>>> (and we simplify the whole startup logic, and we make the startup not
>>>> depend on networking).
>>>>
>>>> http://code.google.com/p/pharo/issues/detail?id=4057
>>>>
>>>> Marcus
>>>>
>>> agree.. this thing is a bit overengineeeeered.
>>> but in overall it is cool to have, unless it breaks a most basic usage
>>> : hey ... a stupid file name passed as an argument!
>>>
>>> we can remove it, of course, but it won't make a FileURL a bit less
>>> broken..
>>> since things like that:
>>>
>>> 'c:\myfile.txt' asURL retrieveContents still won't work.
>>> we should cover it by tests btw, since now we have windows..
>>> but in order to run any test(s) we should fix this thing first :)
>>>
>>>>
>>>> --
>>>> Marcus Denker -- http://marcusdenker.de
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
>



--
Best regards,
Igor Stasenko.