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 [email protected] http://lists.gnu.org/mailman/listinfo/help-smalltalk
