Re: [Pharo-project] [squeak-dev] Accessing external resources in a cross-platform way
I've just implemented an initial release on top of FileSystem and ProcessWrapper (it uses some bit of Grease too). This is how it works in Windows: ( FSLocator sysEnvBinaries / 'notepad.exe' ) resolve " C:\WINDOWS\system32\notepad.exe " ( FSLocator sysEnvBinaries / 'X264VFW.DLL' ) resolve " C:\WINDOWS\system32\X264VFW.DLL " ( FSLocator userBinaries / 'excel.exe' ) resolve " C:\Archivos de programa\Microsoft Office\OFFICE11\EXCEL.EXE " ( FSLocator userBinaries / 'firefox.exe' ) resolve " C:\Archivos de programa\Mozilla Firefox\firefox.exe" So #sysEnvBinaries search in the OS PATH environment variable locations (which is usually pretty fast) and #userBinaries in the "program files" locations (it could be slow depending the amount of entries). It's only tested under Windows, IIRC user binaries in Unix are inside "/usr/local/bin" but you may tweak it to other locations, I have no access to a Unix or MacOS. Feel free to suggest or add any enhacements you like. Cheers, Hernán 2011/1/28 Colin Putney <colin@wiresong.com>:
On Fri, Jan 28, 2011 at 9:17 AM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Thanks David,
I've seen FileSystem package http://www.wiresong.ca/filesystem/ it seems related in some way too
Yes, FileSystem does attempt to provide a cross-platform way to resolve paths that are system-dependent. It doesn't include a way to search for executables, although that's a good feature idea. As David, mentioned you probably want to get the value of the PATH environment variable, and use that for your search. That will handle cross-host differences as well as cross-platform issues.
Colin
Hernan I'm documenting and reorganizing and writing more tests for FS. I contacted colin several times but got no feedback. The version that we will integrate in Pharo is available at: PharoTaskForces if you want to integrate/publish your code there, then you are welcomed. We will do several rounds, probably integrate dale gemstone fixes, deprecate and change some api like workingDirectory returning a path and calling it workingDirectoryPath and push FS in Pharo. Of course, people may probably complain but we will do it. Stef On Feb 3, 2011, at 1:01 AM, Hernán Morales Durand wrote:
I've just implemented an initial release on top of FileSystem and ProcessWrapper (it uses some bit of Grease too). This is how it works in Windows:
( FSLocator sysEnvBinaries / 'notepad.exe' ) resolve " C:\WINDOWS\system32\notepad.exe " ( FSLocator sysEnvBinaries / 'X264VFW.DLL' ) resolve " C:\WINDOWS\system32\X264VFW.DLL " ( FSLocator userBinaries / 'excel.exe' ) resolve " C:\Archivos de programa\Microsoft Office\OFFICE11\EXCEL.EXE " ( FSLocator userBinaries / 'firefox.exe' ) resolve " C:\Archivos de programa\Mozilla Firefox\firefox.exe"
So #sysEnvBinaries search in the OS PATH environment variable locations (which is usually pretty fast) and #userBinaries in the "program files" locations (it could be slow depending the amount of entries). It's only tested under Windows, IIRC user binaries in Unix are inside "/usr/local/bin" but you may tweak it to other locations, I have no access to a Unix or MacOS. Feel free to suggest or add any enhacements you like. Cheers,
Hernán
2011/1/28 Colin Putney <colin@wiresong.com>:
On Fri, Jan 28, 2011 at 9:17 AM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Thanks David,
I've seen FileSystem package http://www.wiresong.ca/filesystem/ it seems related in some way too
Yes, FileSystem does attempt to provide a cross-platform way to resolve paths that are system-dependent. It doesn't include a way to search for executables, although that's a good feature idea. As David, mentioned you probably want to get the value of the PATH environment variable, and use that for your search. That will handle cross-host differences as well as cross-platform issues.
Colin
<Fsextensions-hfm.2.mcz>
On 3 February 2011 09:18, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hernan
I'm documenting and reorganizing and writing more tests for FS. I contacted colin several times but got no feedback. The version that we will integrate in Pharo is available at:     PharoTaskForces     if you want to integrate/publish your code there, then you are welcomed. We will do several rounds, probably integrate dale gemstone fixes, deprecate and change some api like workingDirectory returning a path and calling it workingDirectoryPath and push FS in Pharo. Of course, people may probably complain but we will do it.
How about using open repo.. not pharo-specific? MCHttpRepository location: 'http://www.squeaksource.com/fs' user: '' password: '' I see that FS is quite easy to port over forks/dialects. So, with some effort we can make it easily available across many smalltalk platforms. It will benefit not only Pharo (yes, Pharo could be a testbed for new filesystem), but then if people will want to port it on another platform, they will have to just get in and start hacking there, without using controversial repository (PharoTaskForces) , because it means that this stuff is only for Pharo.
Stef
On Feb 3, 2011, at 1:01 AM, Hernán Morales Durand wrote:
I've just implemented an initial release on top of FileSystem and ProcessWrapper (it uses some bit of Grease too). This is how it works in Windows:
( FSLocator sysEnvBinaries / 'notepad.exe' ) resolve  " C:\WINDOWS\system32\notepad.exe " ( FSLocator sysEnvBinaries / 'X264VFW.DLL' ) resolve  " C:\WINDOWS\system32\X264VFW.DLL " ( FSLocator userBinaries / 'excel.exe' ) resolve        " C:\Archivos de programa\Microsoft Office\OFFICE11\EXCEL.EXE " ( FSLocator userBinaries / 'firefox.exe' ) resolve       " C:\Archivos de programa\Mozilla Firefox\firefox.exe"
So #sysEnvBinaries search in the OS PATH environment variable locations (which is usually pretty fast) and #userBinaries in the "program files" locations (it could be slow depending the amount of entries). It's only tested under Windows, IIRC user binaries in Unix are inside "/usr/local/bin" but you may tweak it to other locations, I have no access to a Unix or MacOS. Feel free to suggest or add any enhacements you like. Cheers,
Hernán
2011/1/28 Colin Putney <colin@wiresong.com>:
On Fri, Jan 28, 2011 at 9:17 AM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Thanks David,
I've seen FileSystem package http://www.wiresong.ca/filesystem/ it seems related in some way too
Yes, FileSystem does attempt to provide a cross-platform way to resolve paths that are system-dependent. It doesn't include a way to search for executables, although that's a good feature idea. As David, mentioned you probably want to get the value of the PATH environment variable, and use that for your search. That will handle cross-host differences as well as cross-platform issues.
Colin
<Fsextensions-hfm.2.mcz>
-- Best regards, Igor Stasenko AKA sig.
Ok I published everything to Filesystem which BTW was dead since 2004! Let us see what it will change. Stef
Hernan
I'm documenting and reorganizing and writing more tests for FS. I contacted colin several times but got no feedback. The version that we will integrate in Pharo is available at: PharoTaskForces if you want to integrate/publish your code there, then you are welcomed. We will do several rounds, probably integrate dale gemstone fixes, deprecate and change some api like workingDirectory returning a path and calling it workingDirectoryPath and push FS in Pharo. Of course, people may probably complain but we will do it.
How about using open repo.. not pharo-specific?
MCHttpRepository location: 'http://www.squeaksource.com/fs' user: '' password: ''
I see that FS is quite easy to port over forks/dialects. So, with some effort we can make it easily available across many smalltalk platforms. It will benefit not only Pharo (yes, Pharo could be a testbed for new filesystem), but then if people will want to port it on another platform, they will have to just get in and start hacking there, without using controversial repository (PharoTaskForces) , because it means that this stuff is only for Pharo.
Stef
On Feb 3, 2011, at 1:01 AM, Hernán Morales Durand wrote:
I've just implemented an initial release on top of FileSystem and ProcessWrapper (it uses some bit of Grease too). This is how it works in Windows:
( FSLocator sysEnvBinaries / 'notepad.exe' ) resolve " C:\WINDOWS\system32\notepad.exe " ( FSLocator sysEnvBinaries / 'X264VFW.DLL' ) resolve " C:\WINDOWS\system32\X264VFW.DLL " ( FSLocator userBinaries / 'excel.exe' ) resolve " C:\Archivos de programa\Microsoft Office\OFFICE11\EXCEL.EXE " ( FSLocator userBinaries / 'firefox.exe' ) resolve " C:\Archivos de programa\Mozilla Firefox\firefox.exe"
So #sysEnvBinaries search in the OS PATH environment variable locations (which is usually pretty fast) and #userBinaries in the "program files" locations (it could be slow depending the amount of entries). It's only tested under Windows, IIRC user binaries in Unix are inside "/usr/local/bin" but you may tweak it to other locations, I have no access to a Unix or MacOS. Feel free to suggest or add any enhacements you like. Cheers,
Hernán
2011/1/28 Colin Putney <colin@wiresong.com>:
On Fri, Jan 28, 2011 at 9:17 AM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Thanks David,
I've seen FileSystem package http://www.wiresong.ca/filesystem/ it seems related in some way too
Yes, FileSystem does attempt to provide a cross-platform way to resolve paths that are system-dependent. It doesn't include a way to search for executables, although that's a good feature idea. As David, mentioned you probably want to get the value of the PATH environment variable, and use that for your search. That will handle cross-host differences as well as cross-platform issues.
Colin
<Fsextensions-hfm.2.mcz>
-- Best regards, Igor Stasenko AKA sig.
On 3 February 2011 10:45, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Ok I published everything to Filesystem which BTW was dead since 2004!
Let us see what it will change.
Good. So let encourage people to use it as an OFFICIAL repository for Filesystem package.
Stef
Hernan
I'm documenting and reorganizing and writing more tests for FS. I contacted colin several times but got no feedback. The version that we will integrate in Pharo is available at:     PharoTaskForces     if you want to integrate/publish your code there, then you are welcomed. We will do several rounds, probably integrate dale gemstone fixes, deprecate and change some api like workingDirectory returning a path and calling it workingDirectoryPath and push FS in Pharo. Of course, people may probably complain but we will do it.
How about using open repo.. not pharo-specific?
MCHttpRepository   location: 'http://www.squeaksource.com/fs'   user: ''   password: ''
I see that FS is quite easy to port over forks/dialects. So, with some effort we can make it easily available across many smalltalk platforms. It will benefit not only Pharo (yes, Pharo could be a testbed for new filesystem), but then if people will want to port it on another platform, they will have to just get in and start hacking there, without using controversial repository (PharoTaskForces) , because it means that this stuff is only for Pharo.
Stef
On Feb 3, 2011, at 1:01 AM, Hernán Morales Durand wrote:
I've just implemented an initial release on top of FileSystem and ProcessWrapper (it uses some bit of Grease too). This is how it works in Windows:
( FSLocator sysEnvBinaries / 'notepad.exe' ) resolve  " C:\WINDOWS\system32\notepad.exe " ( FSLocator sysEnvBinaries / 'X264VFW.DLL' ) resolve  " C:\WINDOWS\system32\X264VFW.DLL " ( FSLocator userBinaries / 'excel.exe' ) resolve        " C:\Archivos de programa\Microsoft Office\OFFICE11\EXCEL.EXE " ( FSLocator userBinaries / 'firefox.exe' ) resolve       " C:\Archivos de programa\Mozilla Firefox\firefox.exe"
So #sysEnvBinaries search in the OS PATH environment variable locations (which is usually pretty fast) and #userBinaries in the "program files" locations (it could be slow depending the amount of entries). It's only tested under Windows, IIRC user binaries in Unix are inside "/usr/local/bin" but you may tweak it to other locations, I have no access to a Unix or MacOS. Feel free to suggest or add any enhacements you like. Cheers,
Hernán
2011/1/28 Colin Putney <colin@wiresong.com>:
On Fri, Jan 28, 2011 at 9:17 AM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Thanks David,
I've seen FileSystem package http://www.wiresong.ca/filesystem/ it seems related in some way too
Yes, FileSystem does attempt to provide a cross-platform way to resolve paths that are system-dependent. It doesn't include a way to search for executables, although that's a good feature idea. As David, mentioned you probably want to get the value of the PATH environment variable, and use that for your search. That will handle cross-host differences as well as cross-platform issues.
Colin
<Fsextensions-hfm.2.mcz>
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
Ok, saved FSExtensions package in http://www.squeaksource.com/fs.html I would not integrate into main package because it depends of ProcessWrapper and Grease. Notice the ConfigurationOfFilesystem in MetacelloRepository now is using the release at http://source.wiresong.ca/mc 2011/2/3 Igor Stasenko <siguctua@gmail.com>:
On 3 February 2011 10:45, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Ok I published everything to Filesystem which BTW was dead since 2004!
Let us see what it will change.
Good. So let encourage people to use it as an OFFICIAL repository for Filesystem package.
Stef
Hernan
I'm documenting and reorganizing and writing more tests for FS. I contacted colin several times but got no feedback. The version that we will integrate in Pharo is available at:     PharoTaskForces     if you want to integrate/publish your code there, then you are welcomed. We will do several rounds, probably integrate dale gemstone fixes, deprecate and change some api like workingDirectory returning a path and calling it workingDirectoryPath and push FS in Pharo. Of course, people may probably complain but we will do it.
How about using open repo.. not pharo-specific?
MCHttpRepository   location: 'http://www.squeaksource.com/fs'   user: ''   password: ''
I see that FS is quite easy to port over forks/dialects. So, with some effort we can make it easily available across many smalltalk platforms. It will benefit not only Pharo (yes, Pharo could be a testbed for new filesystem), but then if people will want to port it on another platform, they will have to just get in and start hacking there, without using controversial repository (PharoTaskForces) , because it means that this stuff is only for Pharo.
Stef
On Feb 3, 2011, at 1:01 AM, Hernán Morales Durand wrote:
I've just implemented an initial release on top of FileSystem and ProcessWrapper (it uses some bit of Grease too). This is how it works in Windows:
( FSLocator sysEnvBinaries / 'notepad.exe' ) resolve  " C:\WINDOWS\system32\notepad.exe " ( FSLocator sysEnvBinaries / 'X264VFW.DLL' ) resolve  " C:\WINDOWS\system32\X264VFW.DLL " ( FSLocator userBinaries / 'excel.exe' ) resolve        " C:\Archivos de programa\Microsoft Office\OFFICE11\EXCEL.EXE " ( FSLocator userBinaries / 'firefox.exe' ) resolve       " C:\Archivos de programa\Mozilla Firefox\firefox.exe"
So #sysEnvBinaries search in the OS PATH environment variable locations (which is usually pretty fast) and #userBinaries in the "program files" locations (it could be slow depending the amount of entries). It's only tested under Windows, IIRC user binaries in Unix are inside "/usr/local/bin" but you may tweak it to other locations, I have no access to a Unix or MacOS. Feel free to suggest or add any enhacements you like. Cheers,
Hernán
2011/1/28 Colin Putney <colin@wiresong.com>:
On Fri, Jan 28, 2011 at 9:17 AM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Thanks David,
I've seen FileSystem package http://www.wiresong.ca/filesystem/ it seems related in some way too
Yes, FileSystem does attempt to provide a cross-platform way to resolve paths that are system-dependent. It doesn't include a way to search for executables, although that's a good feature idea. As David, mentioned you probably want to get the value of the PATH environment variable, and use that for your search. That will handle cross-host differences as well as cross-platform issues.
Colin
<Fsextensions-hfm.2.mcz>
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On 3 February 2011 17:14, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Ok, saved FSExtensions package in
http://www.squeaksource.com/fs.html
I would not integrate into main package because it depends of ProcessWrapper and Grease. Notice the ConfigurationOfFilesystem in MetacelloRepository now is using the release at http://source.wiresong.ca/mc
Then somebody have to release a new version of it? :)
2011/2/3 Igor Stasenko <siguctua@gmail.com>:
On 3 February 2011 10:45, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Ok I published everything to Filesystem which BTW was dead since 2004!
Let us see what it will change.
Good. So let encourage people to use it as an OFFICIAL repository for Filesystem package.
Stef
Hernan
I'm documenting and reorganizing and writing more tests for FS. I contacted colin several times but got no feedback. The version that we will integrate in Pharo is available at:     PharoTaskForces     if you want to integrate/publish your code there, then you are welcomed. We will do several rounds, probably integrate dale gemstone fixes, deprecate and change some api like workingDirectory returning a path and calling it workingDirectoryPath and push FS in Pharo. Of course, people may probably complain but we will do it.
How about using open repo.. not pharo-specific?
MCHttpRepository   location: 'http://www.squeaksource.com/fs'   user: ''   password: ''
I see that FS is quite easy to port over forks/dialects. So, with some effort we can make it easily available across many smalltalk platforms. It will benefit not only Pharo (yes, Pharo could be a testbed for new filesystem), but then if people will want to port it on another platform, they will have to just get in and start hacking there, without using controversial repository (PharoTaskForces) , because it means that this stuff is only for Pharo.
Stef
On Feb 3, 2011, at 1:01 AM, Hernán Morales Durand wrote:
I've just implemented an initial release on top of FileSystem and ProcessWrapper (it uses some bit of Grease too). This is how it works in Windows:
( FSLocator sysEnvBinaries / 'notepad.exe' ) resolve  " C:\WINDOWS\system32\notepad.exe " ( FSLocator sysEnvBinaries / 'X264VFW.DLL' ) resolve  " C:\WINDOWS\system32\X264VFW.DLL " ( FSLocator userBinaries / 'excel.exe' ) resolve        " C:\Archivos de programa\Microsoft Office\OFFICE11\EXCEL.EXE " ( FSLocator userBinaries / 'firefox.exe' ) resolve       " C:\Archivos de programa\Mozilla Firefox\firefox.exe"
So #sysEnvBinaries search in the OS PATH environment variable locations (which is usually pretty fast) and #userBinaries in the "program files" locations (it could be slow depending the amount of entries). It's only tested under Windows, IIRC user binaries in Unix are inside "/usr/local/bin" but you may tweak it to other locations, I have no access to a Unix or MacOS. Feel free to suggest or add any enhacements you like. Cheers,
Hernán
2011/1/28 Colin Putney <colin@wiresong.com>:
On Fri, Jan 28, 2011 at 9:17 AM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Thanks David,
I've seen FileSystem package http://www.wiresong.ca/filesystem/ it seems related in some way too
Yes, FileSystem does attempt to provide a cross-platform way to resolve paths that are system-dependent. It doesn't include a way to search for executables, although that's a good feature idea. As David, mentioned you probably want to get the value of the PATH environment variable, and use that for your search. That will handle cross-host differences as well as cross-platform issues.
Colin
<Fsextensions-hfm.2.mcz>
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
+1 :)
<hernan.morales@gmail.com> wrote:
Ok, saved FSExtensions package in
Thanks hernan
I would not integrate into main package because it depends of ProcessWrapper and Grease. Notice the ConfigurationOfFilesystem in MetacelloRepository now is using the release at http://source.wiresong.ca/mc
Then somebody have to release a new version of it? :)
participants (3)
-
Hernán Morales Durand -
Igor Stasenko -
Stéphane Ducasse