Alternative directory/file classes?

On Mar 12, 2007, at 14:50 , Michael Davies wrote:

Maybe Keith used a non-standard PackageInfo for Rio? The MC file  
looks broken.

- Bert -

Hi, Bert,

> Cross-platform file support has been a real pain in the past, mostly
> because users usually only develop on one platform and unconsciously
> use platform-dependent strings for filenames. I've been working with
> the URI package lately (http://www.squeaksource.com/URI.html) which
> is a real pleasure because it just does the Right Thing when taking
> your code from one platform to the next.
>

What is bad about file:// URI is that it could contain drive letter in
Windows. I think it would easily break portability. So I just prefer
using relative portable path representation in FileMan.

In FileMan, the code like this works in all platforms.
'./test/hello.txt' fileContents: 'world'.

If you use absolute path (without drive letter), FileMan automatically
detects the current drive letter. So,
'/tmp' asDirectoryEntry files.

still works in all platforms. (though it may be a little extreme).

Regards,
--
[:masashi | ^umezawa]

>
> Maybe Keith used a non-standard PackageInfo for Rio? The MC file looks
> broken.
>
> - Bert -
>
The image I am working in has PackageInfo from here:

http://bugs.impara.de/squeak/view.php?id=5715

I also tried loading things into a fresh 3.9-final image and I thought
it was ok.

Keith

               
___________________________________________________________
The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html

On Mar 12, 2007, at 16:26 , Keith Hodges wrote:

Ah. It's a Traits problem ... will only work in 3.9.

- Bert -

Bert Freudenberg wrote: Indeed, I thought that I would experiment with a little traitism just
for fun.

It should be easy enough to detraitify in order to support earlier versions.

Keith

       
       
               
___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html

On Mar 12, 2007, at 16:48 , Bert Freudenberg wrote:

If the package does not include any traits it should work also in  
previous images. If this is not the case let me know. Of course if  
you have traits, you cannot just load that into a pre 3.9 image.

Adrian

>
> - Bert -
>
>
>

Keith Hodges wrote:
> Indeed, I thought that I would experiment with a little traitism just
> for fun.

I see. It's not for me then (I'm plainly set on 3.8). I think I'll stick
with FileMan for the time being.

Cheers,
   - Andreas

Adrian Lienhard wrote:
> If the package does not include any traits it should work also in
> previous images. If this is not the case let me know. Of course if you
> have traits, you cannot just load that into a pre 3.9 image.

Why not? Wasn't the idea that traits methods get "inlined" when they are
loaded into older versions? And if it's about the traits definition
itself, a little compatibility package (introducing class Trait and just
treat the traits defined in the package as subclasses) should go a long way.

Cheers,
   - Andreas

Traits are defined in such a way that they can be flattened.

At the moment this does not happen at load time as you assume, but at
the time at which the mcz creation. This means that pre-traits MC works
unchanged with flat mcz files, at the cost of needing to create flat and
unflat variations on each.

Daniel

Andreas Raab wrote:

And how does one create "flat" MC files?

Cheers,
   - Andreas

Daniel Vainsencher wrote:

Back when I believed in files (!), I thought the ANSI Common Lisp spec on
pathnames was as powerful as it needed to be, and no more.

It is highly portable and is the result of a lot of demanding use. Although it
predated (and influenced) OSI pathnames, URIs, and SCCS/RCS, it turned out to be
powerful enough to represent each of these. Being future-proof is good.

http://www.lispworks.com/documentation/HyperSpec/Body/19_.htm
http://www.lispworks.com/documentation/HyperSpec/Body/20_.htm

The concepts are sufficiently powerful and well-chosen that the operations can
all be defined in surprisingly little code. The key concepts are:

   + Separate Physical Pathname objects and Logical Pathname objects.

   + String designators for either of these, that can generally be used where the
above is expected.

   + Accessors for components of any of the above, including Host, Device,
Directory (an ordered collection), Name, Type, and Version.

   + Clear semantics for merging by components and matching with wildcards.

   + Canonical forms and Truenames.

   + Local Case and Common Case, with information-preserving transformations
between the two (which is what allows merging/matching and canonical forms to
actually be useful).

The spec deliberately left some things (e.g., version numbers) up to the
implementation. The conforming implementation-specific extensions that I wrote
(and felt necessary) are spec'd at
http://webpages.charter.net/stearns/howard/eclipse/eclipse/path.htm

The specs are all written as though all operations are functions, although many
implementations (including mine) were done as generic function methods.



Andreas Raab wrote:
--
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:[hidden email]
jabber:[hidden email]
voice:+1-608-262-3724

Rio (without traits) has been successfully loaded and tested in 3.8, on
Linux.

Using the latest Installer from:

http://www.squeaksource.com/Installer

Installer squeaksource project: 'Null'; install: 'Null-Core'.
Installer squeaksource project: 'Testing'; install: 'SUnit'.
Installer squeaksource project: 'Rio'; install: 'Rio-Kernel';
    install: 'Rio-Core';
    install: 'Rio-Test'.

To run the test cases:

TestReporter runCategories: 'Rio-Test'.  <print-it>

cheers

Keith

> Indeed, I thought that I would experiment with a little traitism just
> for fun.
>
> It should be easy enough to detraitify in order to support earlier
> versions.
>
> Keith



               
___________________________________________________________
The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html

I thought it was proposed as a complete replacement of the existing file
handling stuff.  The URI idea isn't bad, but how would that work?  Seems
kind of redundant to have to type "file://" all the time to a class that
only handles files.

_________________________________________________________________
The average US Credit Score is 675. The cost to see yours: $0 by Experian.
http://www.freecreditreport.com/pm/default.aspx?sc=660600&bcd=EMAILFOOTERAVERAGE

On Mar 13, 2007, at 2:48 PM, J J wrote:

> I thought it was proposed as a complete replacement of the existing  
> file handling stuff.  The URI idea isn't bad, but how would that  
> work?  Seems kind of redundant to have to type "file://" all the  
> time to a class that only handles files.

In Sophie we store references to external data as a URI object.

There is a platform specific class that looks after fetching the URI  
for say the temp directory, the vm directory, the document directory  
for the platform you are running on.

Thus to open a file in the document directory we take the document  
directory, resolved that against the relative URI part of the  
document name, then take the resolved URI and ask it for say a read/
write UTF8 stream.

The Sophie Resource manager stores relative URI's which point to data  
as relative paths based on the URI of the book, or absolute URIs  
which point
to files or internet resources. Naturally we don't suggest people use  
absolute URIs for file based media, we even have a URI to indicate a  
path is a absolute path to a memory
file stream stored in the memory based book model logic.

This model then allows us to open a book (foo.spbf) either on a local  
hard drive, or via a http://  URI without further work since the
URI logic looks after the deals of making a stream,  
StandardFileStream/UTF8 or HTTP stream, ftp, etc....

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

Howard Stearns <[hidden email]> writes:
> Back when I believed in files (!), I thought the ANSI Common Lisp spec on
> pathnames was as powerful as it needed to be, and no more.

Thanks for the pointer, btw.  I happen to have been looking for good
file and filename specs over the last few months, with a mind to
figuring out what good wrappers would look like for the Java file
classes.  Eclipse Lisp is also interesting in this regard, of course;
I presume it uses only the JVM's file primitives, and no native
library to get more?


Lex

On Mar 18, 2007, at 6:04 AM, Lex Spoon wrote:

> Howard Stearns <[hidden email]> writes:
>> Back when I believed in files (!), I thought the ANSI Common Lisp  
>> spec on
>> pathnames was as powerful as it needed to be, and no more.
>
> Thanks for the pointer, btw.

No problem.

> I happen to have been looking for good
> file and filename specs over the last few months, with a mind to
> figuring out what good wrappers would look like for the Java file
> classes.  Eclipse Lisp is also interesting in this regard, of course;
> I presume it uses only the JVM's file primitives, and no native
> library to get more?

I do not think Eclipse Common Lisp helps you in providing any clues  
for how to implement the primitives using Java. It only helps in  
defining a known-to-be-sufficient set of high-level operations.

Eclipse Common Lisp was (past tense) a Lisp - in - C, such that the  
compiler generated human readable C. C could call Lisp in natural  
way, and vice versa.

It predated the Eclipse IDE and had nothing to do with it. (It also  
had nothing to do with the Eclipse C++ Rete engine.)

As it happens, the compiler was designed to also be able to also  
generate JVM byte codes or even human readable Java.  This would have  
worked as you imagined above. However, that would have also required  
two projects I never started:

  1. A rationalization of the Common Lisp and Java class hierarchies.  
If I recall, it was theoretically "mostly" possible, by interposing  
Java classes between the Lisp classes and vice versa. But if I recall  
correctly there were a couple of inversions.  This is, in general,  
necessary for the next step in order to the arguments to the high-
level operations to be passed directly the the primitive operations  
without having to wrap or convert them. (Although it's much easier in  
a limited domain like pathname operations.)

  2. A reimplementation of some of the primitive operations. For  
example, the file operations were implemented using a platform-
neutral wrapper extensions of the Posix operations. (The pure Posix  
stuff didn't provide everything needed.)  These would have been  
changed to using the JVM primitives, for which I would have written  
new Posix wrappers when using the C back end.  The idea was that the  
Common Lisp library source would not be conditionalized for different  
back-ends, nor would the generated Java or C code be conditionalized.  
Only the hand-written primitive stuff it called might be  
conditionalized.  This would NOT have allowed C and Java to talk to  
each other, nor would it have allowed another target back-end to be  
added, but that was never the idea.

There was a project at BBN/GTE-Internetworking in the late 90's to do  
something like this (with Scheme maybe), but I don't remember.

Dear fellow FileDirectory loathers!

Just  quick update on the state of Rio, I am quite pleased with the way
that things are working out, particularly some of the new stuff which
includes:

1. A generic stream copyTo: stream function.
2. Simple read/writeStreams api.
3. Adaptor for transparently using gzip streams, using the same API in
both binary/text modes.
4. A RioDirAdaptor API for moving Files and File Trees into Directories
5. A RioArchiveAdaptor providing the same API for moving Files and File
Trees into Archives. (Zip / Tar - does anyone feel like implementing Tar
support?)
6. MacOS support - With some help I got tests to be green on MacOS, as
well asLinux.  I have not got a Windows box to work with at the moment.

I have put some effort into some fairly comprehensive documentation
which you can find here.

http://wiki.squeak.org/squeak/5929

Best Regards

Keith

p.s. still to do: Extracting files from archives, working with files on
remote servers, and OSProcess 'use the OS' mode.


               
___________________________________________________________
All New Yahoo! Mail – Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html

Great work! I'm very excited to download the new stuff. I played
around with Rio and FileMan this week. I really like the style of the
messages in Rio.

On 3/22/07, Keith Hodges <[hidden email]> wrote:

Hi Keith,

are you modifying ReadStream and WriteStream ?

2007/3/22, Keith Hodges <[hidden email]>:
--
Damien Cassou

Damien Cassou wrote:
> Hi Keith,
>
> are you modifying ReadStream and WriteStream ?
>
Hi Damien,

In principle I am not aiming to modify the Stream classes at all. Rio
handles the File Reference side of things and this is theoretically
orthogonal to the functionality of all of the streams.

I have made a couple of minor fixes, a couple of minor additions, and I
have added my generic aStream copyTo: bStream, and also a
#copyTo:withProgress: version.

Where FileStream's keep a reference to their File, accessible via #name,
I have managed to arrange it so that you can transparently pass aRio
into the streams name field. (i.e. open: aRio forWrite: bool works)

In many places the Streams themselves use FileDirectory. Fortunately I
have succeeded in writing Rio to use the streams avoiding any of these
methods. This means that I have not had to port any of these
FileDirectory dependent methods into Rio equivalents. this means that
FileDirectory and Rio can happily co-exist since Rio is replacing
FileDirectory without stepping on any place that uses it.

When FileDirectory is eventually removed many of these Stream methods
may also be removed because their functionality will have been
refactored elsewhere into Rio. Those methods cannot have been
fundamental to the operations of streams, if they were then I would have
had to use them. So I do look forward to being able to eliminate some
redundant stuff from Streams when the time comes, but for now, I am
leaving well alone.

best regards

Keith



               
___________________________________________________________
Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html