Including files

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

Including files

Bram Neijt
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
Reply | Threaded
Open this post in threaded view
|

Re: Including files

S11001001
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
Reply | Threaded
Open this post in threaded view
|

Re: Including files

Mike Anderson-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Including files

S11001001
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
Reply | Threaded
Open this post in threaded view
|

Re: Including files

Mike Anderson-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Including files

Paolo Bonzini
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
Reply | Threaded
Open this post in threaded view
|

Re: Including files

Paolo Bonzini
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
Reply | Threaded
Open this post in threaded view
|

Re: Including files

Mike Anderson-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Including files

Paolo Bonzini

> 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
Reply | Threaded
Open this post in threaded view
|

Re: Including files

J Pfersich
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
Reply | Threaded
Open this post in threaded view
|

Re: Including files

Mike Anderson-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Including files

Mike Anderson-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Including files

Paolo Bonzini

>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Including files

Paolo Bonzini
   
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Including files

J Pfersich
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
Reply | Threaded
Open this post in threaded view
|

Re: Including files

J Pfersich
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
Reply | Threaded
Open this post in threaded view
|

Re: Including files

S11001001
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
Reply | Threaded
Open this post in threaded view
|

Re: Including files

Paolo Bonzini
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
Reply | Threaded
Open this post in threaded view
|

Re: Including files

J Pfersich
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
Reply | Threaded
Open this post in threaded view
|

REĀ : Including files

Paolo Bonzini
> 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
12