Smalltalk › Squeak › Squeak - Dev

Accessing external resources in a cross-platform way

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

hernanmd

Accessing external resources in a cross-platform way

Let's say you want to resolve paths in a cross platform way

Binaries @ 'MyExec'
Libraries @ 'MyLib'
SystemLibraries @ 'SystemLib'
etc.

then Binaries is

In Windows: #( 'C:\Program Files\' 'C:\Archivos de Programa\' ...) "
and all standard locations including translations "
In UNIX: #('/usr/bin/' '/usr/local/bin' ....) " and all standard locations "
etc

Now you may say it is necessary to scan all directories to find
MyExec, yes but you may then save that location

myBinaryLocation := Binaries @ 'MyExec'.

so you scan for it just once.

What do you think? it is already implemented anywhere?
If not what package do you think is more suitable or prepared for
implementing it?

Cheers,

--
Hernán Morales
Information Technology Manager,
Institute of Veterinary Genetics.
National Scientific and Technical Research Council (CONICET).
La Plata (1900), Buenos Aires, Argentina.
Telephone: +54 (0221) 421-1799.
Internal: 422
Fax: 425-7980 or 421-1799.

David T. Lewis

Re: Accessing external resources in a cross-platform way

On Fri, Jan 28, 2011 at 01:51:22PM +0100, Hern??n Morales Durand wrote:

> Let's say you want to resolve paths in a cross platform way
>
> Binaries @ 'MyExec'
> Libraries @ 'MyLib'
> SystemLibraries @ 'SystemLib'
> etc.
>
> then Binaries is
>
> In Windows: #( 'C:\Program Files\' 'C:\Archivos de Programa\' ...) "
> and all standard locations including translations "
> In UNIX: #('/usr/bin/' '/usr/local/bin' ....) " and all standard locations "
> etc
>
> Now you may say it is necessary to scan all directories to find
> MyExec, yes but you may then save that location
>
> myBinaryLocation := Binaries @ 'MyExec'.
>
> so you scan for it just once.
>
> What do you think? it is already implemented anywhere?
> If not what package do you think is more suitable or prepared for
> implementing it?

Hern??n,

This is of course very platform dependent, and it is more complex
than you might expect due to differences in file systems, operating
systems, volume names (windows), environment variables and search
path conventions.

Both Windows and Unix use various seach paths accessible through
environment variables, and the conventions for this tend to change
over time with different OS versions. So it would probably be best
to rely directly on those environment variables for identifying
search paths.

Aside from the conventions for default locations and search paths,
some of what you are looking for may also be implemented for Windows
and Unix in SqS/CommandShell in class ShellSyntax:

My instances implement parsing of strings in a manner similar to
a simple Unix command shell. I provide path name expansion in the
context of an external file system, and support the syntax required
for IO redirection. All file name globbing and PATH searching are
implemented in Smalltalk rather than in C library functions or an
external command shell.

Most of my syntax is applicable for any operating system. Where
needed, platform specific methods are in my "platform dependent"
category. Currently, Unix and Windows are supported, and other
platforms have not been tested. The primary difference between
Unix and Windows support is that device names (such as 'C:') are
used in Windows path strings. Separate current working directory
strings are maintained for all Windows device names. For Unix,
a single current working directory path is used. On Windows,
this permits the CommandShell 'cd' command to support changing
directories to another device without losing track of the current
working directory for the previous device.

Command pipeline syntax is not supported here. See CommandShell
for the implementation of command pipelines.

Dave

K K Subbu

Re: Accessing external resources in a cross-platform way

In reply to this post by hernanmd

On Friday 28 Jan 2011 6:21:22 pm Hernán Morales Durand wrote:
> What do you think? it is already implemented anywhere?
> If not what package do you think is more suitable or prepared for
> implementing it?
David has already replied about the complexity of such references.

Squeak is a virtual computer that runs on a variety of hosts. For Squeak
processes, the host is just another remote computer. The best way to access
these resources will be through URIs with protocol handlers in the VM for each
type of resource (e.g. program:/pdflatex, plugin:/SerialPlugin or font:/Sans).
URIs can even handle device ports (e.g. serial:/1 or video:/1). Such URIs can
safely be persisted in objects across snapshot ops.

I suspect most people use Squeak on a single platform, so the itch is not
serious enough ;-) for a URI.

Subbu

hernanmd

Re: Accessing external resources in a cross-platform way

In reply to this post by David T. Lewis

Thanks David,

I've seen FileSystem package http://www.wiresong.ca/filesystem/
it seems related in some way too

2011/1/28 David T. Lewis <[hidden email]>:

> On Fri, Jan 28, 2011 at 01:51:22PM +0100, Hern??n Morales Durand wrote:
>> Let's say you want to resolve paths in a cross platform way
>>
>> Binaries @ 'MyExec'
>> Libraries @ 'MyLib'
>> SystemLibraries @ 'SystemLib'
>> etc.
>>
>> then Binaries is
>>
>> In Windows: #( 'C:\Program Files\' 'C:\Archivos de Programa\' ...) "
>> and all standard locations including translations "
>> In UNIX: #('/usr/bin/' '/usr/local/bin' ....) " and all standard locations "
>> etc
>>
>> Now you may say it is necessary to scan all directories to find
>> MyExec, yes but you may then save that location
>>
>> myBinaryLocation := Binaries @ 'MyExec'.
>>
>> so you scan for it just once.
>>
>> What do you think? it is already implemented anywhere?
>> If not what package do you think is more suitable or prepared for
>> implementing it?
>
> Hern??n,
>
> This is of course very platform dependent, and it is more complex
> than you might expect due to differences in file systems, operating
> systems, volume names (windows), environment variables and search
> path conventions.
>
> Both Windows and Unix use various seach paths accessible through
> environment variables, and the conventions for this tend to change
> over time with different OS versions. So it would probably be best
> to rely directly on those environment variables for identifying
> search paths.
>
> Aside from the conventions for default locations and search paths,
> some of what you are looking for may also be implemented for Windows
> and Unix in SqS/CommandShell in class ShellSyntax:
>
> My instances implement parsing of strings in a manner similar to
> a simple Unix command shell. I provide path name expansion in the
> context of an external file system, and support the syntax required
> for IO redirection. All file name globbing and PATH searching are
> implemented in Smalltalk rather than in C library functions or an
> external command shell.
>
> Most of my syntax is applicable for any operating system. Where
> needed, platform specific methods are in my "platform dependent"
> category. Currently, Unix and Windows are supported, and other
> platforms have not been tested. The primary difference between
> Unix and Windows support is that device names (such as 'C:') are
> used in Windows path strings. Separate current working directory
> strings are maintained for all Windows device names. For Unix,
> a single current working directory path is used. On Windows,
> this permits the CommandShell 'cd' command to support changing
> directories to another device without losing track of the current
> working directory for the previous device.
>
> Command pipeline syntax is not supported here. See CommandShell
> for the implementation of command pipelines.
>
> Dave
>
>
>

Colin Putney-3

Re: Accessing external resources in a cross-platform way

On Fri, Jan 28, 2011 at 9:17 AM, Hernán Morales Durand
<[hidden email]> 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

hernanmd

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

> On Fri, Jan 28, 2011 at 9:17 AM, Hernán Morales Durand
> <[hidden email]> 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 (5K) Download Attachment