Hi Help-Smalltalk readers,
I've just gotten my Smalltalk book (Smalltalk, Objects and Design) and started encoding. I'm not good yet, so here is my question: How do you include other files. Currently I use: FileStream fileIn: 'ClassInfo/ClassInfo.st' ! To include my ClassInfo class defenition into the source, however, when I seperate my my class into seperate files I have to mention the directory. The problem is, this method of including files does not take the location of the file calling it into account. So, I have to mention either the absolute path or the path relative to the gst process. Is there an 'include' statement which takes the calling file position into account? Greetings, Bram _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Bram Neijt wrote:
> Is there an 'include' statement which takes the calling file position > into account? Before you go off and add a primitive for _gst_get_cur_file_name, consider the intent of your package: 1. Is this a package of library-like code? If so, consider arranging for a package XML description to install and load your package via the PackageLoader. 2. Is this a script to be installed? If so, you can use Autoconf's substitution to insert the proper value when your package is configured (this is how gst finds the default kernel directory). Doing this yourself is also easy: sed 's!@bindir@!'$bindir'!' script.st.in > script.st Also there may be a way to get the current filename that I am missing. thisContext method methodSourceFile doesn't seem to have it, which isn't that surprising.... -- Stephen Compall http://scompall.nocandysw.com/blog _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Stephen Compall wrote:
> Bram Neijt wrote: > >>Is there an 'include' statement which takes the calling file position >>into account? > > > Before you go off and add a primitive for _gst_get_cur_file_name, > consider the intent of your package: Adding a primitive would be overkill, wouldn't it? Surely you just need a small change to FileStream >> #fileIn:? Regards, Mike _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Mike Anderson wrote:
> Adding a primitive would be overkill, wouldn't it? Surely you just need > a small change to FileStream >> #fileIn:? How would this know about a filepath specified on the command line, for example? (see gst_smalltalk_args and process_file in lib.c) While the user could always specify a method that is already defined in the current file, whereupon the information could be retrieved from that CompiledMethod's MethodInfo, this would be ugly at best. -- Stephen Compall http://scompall.nocandysw.com/blog _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Stephen Compall wrote:
> Mike Anderson wrote: > >>Adding a primitive would be overkill, wouldn't it? Surely you just need >>a small change to FileStream >> #fileIn:? > > > How would this know about a filepath specified on the command line, > for example? (see gst_smalltalk_args and process_file in lib.c) It wouldn't. I'm afraid I'm having difficulty coming to grips with the recent fad for doing everything outside of Smalltalk. Mike _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by S11001001
> Also there may be a way to get the current filename that I am missing. > thisContext method methodSourceFile doesn't seem to have it, which > isn't that surprising.... > That's because most likely the stream you're using is a readline stream. For a file-in, your very clever expression works. I'm not sure I like hacking into #fileIn:, on the other hand a method like FileStream class>#include: might be much better: include: aFileName | callerName dir fullName | callerName := thisContext parentContext method methodSourceFile. callerName isNil ifTrue: [ FileStream fileIn: aFileName asString ]. dir := (File name: callerName) stripFileName. fullName := Directory append: aFileName to: dir. FileStream fileIn: aFileName! or something like that. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Mike Anderson-3
>> How would this know about a filepath specified on the command line, >> for example? (see gst_smalltalk_args and process_file in lib.c) >> > It wouldn't. The obvious solution being to call FileStream>>#fileIn: there too. We only need to use process_file to bootstrap the system, everything else had better be done with Smalltalk call-ins. We're actually doing this more often in post-2.2 development versions, to allow filing in a ReadStream. > I'm afraid I'm having difficulty coming to grips with the > recent fad for doing everything outside of Smalltalk. > ??? Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Paolo Bonzini wrote:
> >>> How would this know about a filepath specified on the command line, >>> for example? (see gst_smalltalk_args and process_file in lib.c) >>> >> >> It wouldn't. > > The obvious solution being to call FileStream>>#fileIn: there too. We > only need to use process_file to bootstrap the system, everything else > had better be done with Smalltalk call-ins. We're actually doing this > more often in post-2.2 development versions, to allow filing in a > ReadStream. > >> I'm afraid I'm having difficulty coming to grips with the >> recent fad for doing everything outside of Smalltalk. >> > > ??? What I was trying to say is that lately it seems everyone has been focussing on better ways of writing Smalltalk from outside of Smalltalk, whereas I'm more interested in finding ways of doing the tasks from within Smalltalk. What you've suggested there is exactly that, so that makes me happy. To digress slightly: what I've been daydreaming about is having the Read-Eval-Print loop implemented in a Smalltalk process. That way, you could substitute another method of interaction (like, say, something listening on a port), kill the REP, and restart the image with the new interface only. At the moment, you have to supply a script to the image that will suspend the REP. I'm increasingly thinking that a Smalltalk image is most similar to a database instance. Rather than starting it up every time you want to run something, you would run it in the background. Adding classes and compiling methods have parallels in creating tables and stored procedures. Queries translate into expression evaluations, but of course, a Smalltalk image can provide the application as well as just the back end. Maybe I'm reinventing GemStone, but that's not Free Software, so I'd never feel comfortable hacking on it. Regards, Mike _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
> To digress slightly: what I've been daydreaming about is having the > Read-Eval-Print loop implemented in a Smalltalk process. That way, you > could substitute another method of interaction (like, say, something > listening on a port), kill the REP, and restart the image with the new > interface only. At the moment, you have to supply a script to the image > that will suspend the REP. > Don't daydream. :-) Instead, what we should do is to provide a small C interface to readline -- all that's needed actually (at least to start) is the functions readline() and add_history(), or a wrapper that does both -- so that the REP loop could use a ReadlineStream, a StdinStream, an EmacsInteractionStream, and so on... > I'm increasingly thinking that a Smalltalk image is most similar to a > database instance. I agree with the parallel (but it's the weakness as much as the strength of Smalltalk...) Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Mike Anderson-3
And wouldn't it be easier to save an image with useful objects in it? I do
that often to save time. At 01:51 PM 9/3/2006 +0000, Mike Anderson wrote: >Stephen Compall wrote: > > Mike Anderson wrote: > > > >>Adding a primitive would be overkill, wouldn't it? Surely you just need > >>a small change to FileStream >> #fileIn:? > > > > > > How would this know about a filepath specified on the command line, > > for example? (see gst_smalltalk_args and process_file in lib.c) > >It wouldn't. I'm afraid I'm having difficulty coming to grips with the >recent fad for doing everything outside of Smalltalk. > >Mike > > > >_______________________________________________ >help-smalltalk mailing list >[hidden email] >http://lists.gnu.org/mailman/listinfo/help-smalltalk _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Paolo Bonzini
J Pfersich wrote:
> Somewhat off topic: > > the File touch method doesn't work I'm not sure if you meant off-topic for the subject line or off-topic for the list, but bug reports are on-topic for the list. It seems to work in so far as it can create files, but it doesn't update the timestamp. Is that what you see? Mike _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Paolo Bonzini
J Pfersich wrote:
> Off topic for the subject line. > > Yes, touch doesn't update the timestamp. It seems that the open-close is > optimized out of existence. I tried other means, but got the same > results (like adding a position 0 before the close). > A primitive using utimes would fix it, but I'm not sure how to do it (at > least I haven't tried it). I tried to utimes on Linux and Mac and it > worked beautifully, not sure about other platforms. man utime says it's POSIX. I'd be in favour of adding #utime and removing #touch if anyone cared to do the work ;) Mike _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
>> Yes, touch doesn't update the timestamp. It seems that the open-close is >> optimized out of existence. I tried other means, but got the same >> results (like adding a position 0 before the close). >> A primitive using utimes would fix it, but I'm not sure how to do it (at >> least I haven't tried it). I tried to utimes on Linux and Mac and it >> worked beautifully, not sure about other platforms. >> > man utime says it's POSIX. I'd be in favour of adding #utime and > removing #touch if anyone cared to do the work ;) Like this? I will commit this as soon as you confirm it's what you could have done. That was just laziness on my side. I recall I was using Cygwin at the time I added File>>#touch. When I added VFS support, that one method had not changed, so I didn't bother testing if it still worked. Thanks all for the activity that is going on these days! Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
>> man utime says it's POSIX. I'd be in favour of adding #utime and >> removing #touch if anyone cared to do the work ;) > Like this? I will commit this as soon as you confirm it's what you > could have done. Like this I meant. Paolo --- orig/kernel/File.st +++ mod/kernel/File.st @@ -251,6 +251,18 @@ size ^vfsHandler size ! +lastAccessTime: aDateTime + "Update the last access time of the file corresponding to the receiver, + to be aDateTime." + vfsHandler lastAccessTime: aDateTime lastModifyTime: self lastModifyTime +! + +lastAccessTime: accessDateTime lastModifyTime: modifyDateTime + "Update the timestamps of the file corresponding to the receiver, to be + accessDateTime and modifyDateTime." + vfsHandler lastAccessTime: accessDateTime lastModifyTime: modifyDateTime +! + lastAccessTime "Answer the last access time of the file identified by the receiver" ^vfsHandler lastAccessTime @@ -272,6 +284,12 @@ creationTime ^vfsHandler creationTime ! +lastModifyTime: aDateTime + "Update the last modification timestamp of the file corresponding to the + receiver, to be aDateTime." + vfsHandler lastAccessTime: self lastAccessTime lastModifyTime: aDateTime +! + lastModifyTime "Answer the last modify time of the file identified by the receiver (the `last modify time' has to do with the actual file contents)." @@ -381,8 +399,10 @@ contents ! touch - "Update the timestamp of the file with the given path name." - (self openDescriptor: FileStream append) close + "Update the timestamp of the file corresponding to the receiver." + | now | + now := DateTime now. + self lastAccessTime: now lastModifyTime: now ! open: mode --- orig/kernel/VFS.st +++ mod/kernel/VFS.st @@ -168,6 +168,9 @@ rewindDir: dirObject !RealFileHandler class methodsFor: 'C call-outs'! +setTimeFor: file atime: atimeSeconds mtime: mtimeSeconds + <cCall: 'utime' returning: #int args: #(#string #long #long)>! + working <cCall: 'getCurDirName' returning: #stringOut args: #()>! ! @@ -357,6 +360,12 @@ isAccessible !VFSHandler methodsFor: 'file operations'! +lastAccessTime: accessDateTime lastModifyTime: modifyDateTime + "Set the receiver's timestamps to be accessDateTime and modifyDateTime. + If your file system does not support distinct access and modification + times, you should discard accessDateTime." + self subclassResponsibility! + open: class mode: mode ifFail: aBlock "Open the receiver in the given mode (as answered by FileStream's class constant methods)" @@ -518,6 +527,14 @@ isExecutable !RealFileHandler methodsFor: 'file operations'! +lastAccessTime: accessDateTime lastModifyTime: modifyDateTime + "Set the receiver's timestamps to be accessDateTime and modifyDateTime." + self class + setTimeFor: self realFileName + atime: (self secondsFromDateTime: accessDateTime) + mtime: (self secondsFromDateTime: modifyDateTime). + File checkError! + open: class mode: mode ifFail: aBlock "Open the receiver in the given mode (as answered by FileStream's class constant methods)" @@ -541,9 +558,16 @@ renameTo: newFileName !RealFileHandler methodsFor: 'private'! -getDateAndTime: time +secondsFromDateTime: aDateTime "Private - Convert a time expressed in seconds from 1/1/2000 to an array of two Smalltalk Date and Time objects" + ^(aDateTime asSeconds - Epoch asSeconds) + - (aDateTime offset asSeconds - Epoch offset asSeconds) +! + +getDateAndTime: time + "Private - Convert a time expressed in seconds from 1/1/2000 to + a Smalltalk DateTime object." ^(Epoch + (Duration seconds: time)) offset: (Duration seconds: Time timezoneBias) --- orig/libgst/cint.c +++ mod/libgst/cint.c @@ -200,6 +200,9 @@ static OOP classify_type_symbol (OOP sym static int get_errno (void); /* Encapsulate binary incompatibilities between various C libraries. */ +static int my_utime (const char *name, + long new_atime, + long new_mtime); static int my_stat (const char *name, gst_stat * out); static int my_lstat (const char *name, @@ -306,6 +309,22 @@ get_errno (void) } int +my_utime (const char *name, + long new_atime, + long new_mtime) +{ + struct timeval times[2]; + int result; + times[0].tv_sec = new_atime + 86400 * 10957; + times[1].tv_sec = new_mtime + 86400 * 10957; + times[0].tv_usec = times[1].tv_usec = 0; + result = utimes (name, times); + if (!result) + errno = 0; + return (result); +} + +int my_stat (const char *name, gst_stat * out) { @@ -497,6 +516,7 @@ _gst_init_cfuncs (void) _gst_define_cfunc ("strerror", strerror); _gst_define_cfunc ("stat", my_stat); _gst_define_cfunc ("lstat", my_lstat); + _gst_define_cfunc ("utime", my_utime); _gst_define_cfunc ("opendir", my_opendir); _gst_define_cfunc ("closedir", closedir); _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Paolo Bonzini
In File.st there's two opens and two openDescriptors and the comment for
renameTo: is wrong At 09:16 AM 9/8/2006 +0200, Paolo Bonzini wrote: >>>Yes, touch doesn't update the timestamp. It seems that the open-close is >>>optimized out of existence. I tried other means, but got the same >>>results (like adding a position 0 before the close). >>>A primitive using utimes would fix it, but I'm not sure how to do it (at >>>least I haven't tried it). I tried to utimes on Linux and Mac and it >>>worked beautifully, not sure about other platforms. >>> >>man utime says it's POSIX. I'd be in favour of adding #utime and >>removing #touch if anyone cared to do the work ;) >Like this? I will commit this as soon as you confirm it's what you could >have done. > >That was just laziness on my side. I recall I was using Cygwin at the >time I added File>>#touch. When I added VFS support, that one method had >not changed, so I didn't bother testing if it still worked. > >Thanks all for the activity that is going on these days! > >Paolo > > >_______________________________________________ >help-smalltalk mailing list >[hidden email] >http://lists.gnu.org/mailman/listinfo/help-smalltalk _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Paolo Bonzini
It's pretty close to what I've done, I just never got around to creating
the diffs. I have more touch methods. And my touch methods don't raise an exception when the file doesn't exist. st> File touch: 'banbang.txt' ! Object: File error: No such file or directory File class(Object)>>#primError: SystemExceptions.FileError(Exception)>>#defaultAction optimized [] in Exception class>>#coreException SystemExceptions.FileError(Signal)>>#activateHandler: SystemExceptions.FileError(Exception)>>#signal SystemExceptions.FileError class(Exception class)>>#signal: File class>>#checkError: File class>>#checkError VFS.RealFileHandler>>#lastAccessTime:lastModifyTime: File>>#lastAccessTime:lastModifyTime: File>>#touch File class>>#touch: UndefinedObject>>#executeStatements nil st> The touch utility creates the file unless you specify nocreate. It's not that hard to create primitives, is it? BTW, when is a new tarball going to be created? Will it be 2.3 or 2.2.1? At 09:42 AM 9/8/2006 +0200, Paolo Bonzini wrote: > >>>man utime says it's POSIX. I'd be in favour of adding #utime and >>>removing #touch if anyone cared to do the work ;) >>Like this? I will commit this as soon as you confirm it's what you could >>have done. >Like this I meant. > >Paolo > > >--- orig/kernel/File.st >+++ mod/kernel/File.st >@@ -251,6 +251,18 @@ size > ^vfsHandler size > ! > >+lastAccessTime: aDateTime >+ "Update the last access time of the file corresponding to the receiver, >+ to be aDateTime." >+ vfsHandler lastAccessTime: aDateTime lastModifyTime: self lastModifyTime >+! >+ >+lastAccessTime: accessDateTime lastModifyTime: modifyDateTime >+ "Update the timestamps of the file corresponding to the receiver, to be >+ accessDateTime and modifyDateTime." >+ vfsHandler lastAccessTime: accessDateTime lastModifyTime: modifyDateTime >+! >+ > lastAccessTime > "Answer the last access time of the file identified by the receiver" > ^vfsHandler lastAccessTime >@@ -272,6 +284,12 @@ creationTime > ^vfsHandler creationTime > ! > >+lastModifyTime: aDateTime >+ "Update the last modification timestamp of the file corresponding to the >+ receiver, to be aDateTime." >+ vfsHandler lastAccessTime: self lastAccessTime lastModifyTime: aDateTime >+! >+ > lastModifyTime > "Answer the last modify time of the file identified by the receiver > (the `last modify time' has to do with the actual file contents)." >@@ -381,8 +399,10 @@ contents > ! > > touch >- "Update the timestamp of the file with the given path name." >- (self openDescriptor: FileStream append) close >+ "Update the timestamp of the file corresponding to the receiver." >+ | now | >+ now := DateTime now. >+ self lastAccessTime: now lastModifyTime: now > ! > > open: mode > > >--- orig/kernel/VFS.st >+++ mod/kernel/VFS.st >@@ -168,6 +168,9 @@ rewindDir: dirObject > > !RealFileHandler class methodsFor: 'C call-outs'! > >+setTimeFor: file atime: atimeSeconds mtime: mtimeSeconds >+ <cCall: 'utime' returning: #int args: #(#string #long #long)>! >+ > working > <cCall: 'getCurDirName' returning: #stringOut args: #()>! ! > >@@ -357,6 +360,12 @@ isAccessible > > !VFSHandler methodsFor: 'file operations'! > >+lastAccessTime: accessDateTime lastModifyTime: modifyDateTime >+ "Set the receiver's timestamps to be accessDateTime and modifyDateTime. >+ If your file system does not support distinct access and modification >+ times, you should discard accessDateTime." >+ self subclassResponsibility! >+ > open: class mode: mode ifFail: aBlock > "Open the receiver in the given mode (as answered by FileStream's > class constant methods)" >@@ -518,6 +527,14 @@ isExecutable > > !RealFileHandler methodsFor: 'file operations'! > >+lastAccessTime: accessDateTime lastModifyTime: modifyDateTime >+ "Set the receiver's timestamps to be accessDateTime and modifyDateTime." >+ self class >+ setTimeFor: self realFileName >+ atime: (self secondsFromDateTime: accessDateTime) >+ mtime: (self secondsFromDateTime: modifyDateTime). >+ File checkError! >+ > open: class mode: mode ifFail: aBlock > "Open the receiver in the given mode (as answered by FileStream's > class constant methods)" >@@ -541,9 +558,16 @@ renameTo: newFileName > > !RealFileHandler methodsFor: 'private'! > >-getDateAndTime: time >+secondsFromDateTime: aDateTime > "Private - Convert a time expressed in seconds from 1/1/2000 to > an array of two Smalltalk Date and Time objects" >+ ^(aDateTime asSeconds - Epoch asSeconds) >+ - (aDateTime offset asSeconds - Epoch offset asSeconds) >+! >+ >+getDateAndTime: time >+ "Private - Convert a time expressed in seconds from 1/1/2000 to >+ a Smalltalk DateTime object." > > ^(Epoch + (Duration seconds: time)) > offset: (Duration seconds: Time timezoneBias) > > >--- orig/libgst/cint.c >+++ mod/libgst/cint.c >@@ -200,6 +200,9 @@ static OOP classify_type_symbol (OOP sym > static int get_errno (void); > > /* Encapsulate binary incompatibilities between various C libraries. */ >+static int my_utime (const char *name, >+ long new_atime, >+ long new_mtime); > static int my_stat (const char *name, > gst_stat * out); > static int my_lstat (const char *name, >@@ -306,6 +309,22 @@ get_errno (void) > } > > int >+my_utime (const char *name, >+ long new_atime, >+ long new_mtime) >+{ >+ struct timeval times[2]; >+ int result; >+ times[0].tv_sec = new_atime + 86400 * 10957; >+ times[1].tv_sec = new_mtime + 86400 * 10957; >+ times[0].tv_usec = times[1].tv_usec = 0; >+ result = utimes (name, times); >+ if (!result) >+ errno = 0; >+ return (result); >+} >+ >+int > my_stat (const char *name, > gst_stat * out) > { >@@ -497,6 +516,7 @@ _gst_init_cfuncs (void) > _gst_define_cfunc ("strerror", strerror); > _gst_define_cfunc ("stat", my_stat); > _gst_define_cfunc ("lstat", my_lstat); >+ _gst_define_cfunc ("utime", my_utime); > > _gst_define_cfunc ("opendir", my_opendir); > _gst_define_cfunc ("closedir", closedir); > > > >_______________________________________________ >help-smalltalk mailing list >[hidden email] >http://lists.gnu.org/mailman/listinfo/help-smalltalk _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
J Pfersich wrote:
> It's not that hard to create primitives, is it? Smalltalk code is less bug-prone and easier to maintain than C. Fewer primitives is better, all else being equal. > Will [the next release] be 2.3 or 2.2.1? By NEWS in smalltalk--devo--2.2, it should be 2.2.1. -- Stephen Compall http://scompall.nocandysw.com/blog _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by J Pfersich
J Pfersich wrote:
> It's pretty close to what I've done, I just never got around to > creating the diffs. I have more touch methods. And my touch methods > don't raise an exception when the file doesn't exist. Right. Please send the diffs, if you care that people see them. I also fixed the other bugs you reported, thanks. > The touch utility creates the file unless you specify nocreate. > > It's not that hard to create primitives, is it? ??? As for the next tarball, it will be 2.2a (2.3 prerelease, that is) and I'll try to build it this week, or as soon as I get to test the remaining Unicode changes. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
At 11:39 PM 9/12/2006 +0200, Paolo Bonzini wrote:
>J Pfersich wrote: >>It's pretty close to what I've done, I just never got around to creating >>the diffs. I have more touch methods. And my touch methods don't raise an >>exception when the file doesn't exist. >Right. Please send the diffs, if you care that people see them. I'd have to check which system has the changes I did. It's not on a computer that's connected to the net. I may have just overwritten my changes with yours. I agree with Mike that utime would be a better name than touch if it only changes an already existing file. My touch created the file if it didn't exist, Paolo's does not. Maybe we should have both? Why is >I also fixed the other bugs you reported, thanks. >>The touch utility creates the file unless you specify nocreate. >> >>It's not that hard to create primitives, is it? >??? > >As for the next tarball, it will be 2.2a (2.3 prerelease, that is) and >I'll try to build it this week, or as soon as I get to test the remaining >Unicode changes. > >Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
> I may have just overwritten my
> changes with yours. No problem. > I agree with Mike that utime would be a better name > than touch if it only changes an already existing file. My touch created > the file if it didn't exist, Paolo's does not. Maybe we should have both? My latest changes have both #touch: and #lastAccessTime:lastModifyTime: (the latter does not create the file). Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Free forum by Nabble | Edit this page |