Menu
▾
▴
squeak-vmdev
|
From: Andreas R. <And...@gm...> - 2002-09-05 21:41:40
|
Ian, Good points all. So how about having a way for *asking* what the VM thinks the CWD is?! Cheers, - Andreas > -----Original Message----- > From: Ian Piumarta [mailto:ian...@in...] > Sent: Thursday, September 05, 2002 11:26 PM > To: Andreas Raab > Cc: squ...@li... > Subject: Re: [Squeak-VMdev] RFC: Default VM directory > > > On Thu, 5 Sep 2002, Andreas Raab wrote: > > > So I changed this to be the image location by default. How is this > > handled on the other platforms?! > > Unix has a very well-developed idea about what cwd means. > Squeak behaves > the way you'd expect any Unix app to behave: it inherits the > cwd from the > shell (or whatever process runs Squeak). The only thing it > requires is > that the .sources (or a link thereto) be in the cwd. > > Normally the cwd is the same dir as the image file, but there > is nothing > at all preventing people from doing this: > > ln -s some/where/SqueakV3.sources . > /some/where/else/squeak /some/where/different/squeak.image > > > Can we agree on the "definite default > > working directory" for the VM to be set to the image location?! > > For Unix I'd be inclined to generalize the above (i.e., the current > behaviour) rather than making it more specific (e.g., setting > the cwd to > something that isn't the inherited value); for example, removing the > remaining restriction that the .sources be in the cwd, viz: > > /some/where/else/squeak \ > -sources /some/where/bizarre/SqueakV3.sources \ > /some/where/different/squeak.image > > such that the cwd can be made completely independent of the > three files > the VM looks for. > > Regarding where the log files get written to, the cwd at the time of > starting the VM is the right place. There is no reason to insist that > any of the VM, .sources, .image/.changes be in a writable > directory. OTOH, the logs can only be written to a writable directory > (duh ;-). > > For now I don't think I should change anything. It doesn't > seem to be an > issue for anyone on Unix (not one single person has ever asked if the > current behaviour might be changed). If it ain't broke, I > ain't going to > even begin to speculate about the merest possibility of > "fixing" it. ;) > > Your solution for windows (of setting cwd to the image > directory) seems > fair enough given that the .changes file will normally be in > some place > writable. For Unix, such draconianism just isn't indicated (or even > desirable). > > Cheers, > > Ian > |
|
From: Ian P. <ian...@in...> - 2002-09-05 21:47:49
|
Hi Andreas, > So how about having a way for *asking* what the VM thinks the CWD is?! How about: squeak -cwd /tmp my.image ? (I was tempted to suggest "-C" by analogy with GNU `make' and `tar', but then I came to my senses. ;) I'll add this (or any better suggestion you might have) to 3.2-5 and then just before 3.2-6 comes along I'll poll the list to see if more than zero people ever used it (to determine if the `source-level GC' should run -- creeping featurism and all that... ;). Ian |
|
From: Ian P. <ian...@in...> - 2002-09-05 22:00:20
|
Hi again, Andreas - At the risk of answering my own email (oops -- too late ;) this > squeak -cwd /tmp my.image might turn out to be more confusing than simply insisting that people do `the usual Unix thing', viz: prompt$ ( cd /working/dir; squeak /path/to/my.image ) because it isn't clear what the behaviour of the proposed `-cwd' flag should be. E.g: the image file is opened and read before the interpreter is started. Then the image looks in the cwd for the .changes and .sources files after the interpreter is started. There are two possibilities: 1) the VM calls chdir() before reading the image, in which case we're just adding cruft to achieve something we can do using a standard Unix idiom: ( cd somewhere; run-my-program ). 2) the VM calls chdir() after reading the image, in which case we're going to end up with the very strange behaviour that the VM looks for the .image and .changes in different places (the .image is opened in inherited cwd, the .changes in the dir specified by -cwd). In any case, either of the above would mean that to set the cwd to /tmp (for example) when running squeak from my home dir I would have to do this: squeak -cwd /tmp $HOME/my.image and then the .changed would be either in $HOME or /tmp depending on the choice of (1) or (2) above. Is this not _more_ confusing than the current situation? Ian |
|
From: Tim R. <ti...@su...> - 2002-09-05 22:46:25
|
In message <Pin...@ti...>
Ian Piumarta <ian...@in...> wrote:
> because it isn't clear what the behaviour of the proposed `-cwd' flag
> should be. E.g: the image file is opened and read before the interpreter
> is started. Then the image looks in the cwd for the .changes and .sources
> files after the interpreter is started.
Err, I am under the impression that the .changes file is to be expected
in the same directory as the .image and the .sources in the same
directory as the VM. Or more exactly, the .sources are expected to be in
the path returned by vmPath and the .changes in the CWD as set by
'setDefaultDirectoryFrom: Smalltalk imageName'.
For Acorn I make the vmPath be the application directory so that the
sources live right next door to the vm.
Oh, and Ian, you were wrong a couple of messages back - in general the
.changes file could do with living in a writable directory...
It might be smart to specify explicit paths rather than the somewhat
limiting assumptions currently in the system. I suspect that it isn't
normally expected in unix that a text file would be in
/blah/bin/var/nobodyinparticular/usr/sqf/squeak/3.2/bin along with the
vm. And from reading some of the discussion relating to ROX I get the
impression that where to put files can become a holywar for unixoids.
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
"Like no bother man.." said Pooh as he spaced out on hash
|
|
From: Ian P. <ian...@in...> - 2002-09-05 23:15:51
|
On Thu, 5 Sep 2002, Tim Rowledge wrote: > Oh, and Ian, you were wrong a couple of messages back - in general the > .changes file could do with living in a writable directory... Well, only because the image insists on opening it read-write. There's nothing fundamental preventing it from being read-only if the session is not intended to make any changes in the image. > limiting assumptions currently in the system. I suspect that it isn't > normally expected in unix that a text file would be in > /blah/bin/var/nobodyinparticular/usr/sqf/squeak/3.2/bin along with the > vm. Actually, this is precisely the situation we have when using the npsqueak browser plugin. > And from reading some of the discussion relating to ROX I get the > impression that where to put files can become a holywar for unixoids. Which is why it should all be kept as simple as possible. Ian |
|
From: Andreas R. <And...@gm...> - 2002-09-05 23:03:02
|
Ian, > > So how about having a way for *asking* what the VM thinks > > the CWD is?! > > How about: > > squeak -cwd /tmp my.image That wasn't the problem. What I needed was knowing from within the *image* what the CWD is. E.g., FileDirectory takes the "default directory" from the image name (and I am not inclined to change this) but this means you cannot find out where something like a log file goes. Cheers, - Andreas |
|
From: Bert F. <be...@is...> - 2002-09-06 09:59:14
|
On Fri, 6 Sep 2002, Andreas Raab wrote: > That wasn't the problem. What I needed was knowing from within the > *image* what the CWD is. E.g., FileDirectory takes the "default > directory" from the image name (and I am not inclined to change this) > but this means you cannot find out where something like a log file goes. I'm pretty sure OSProcess allows you to query the CWD. It's rather platform-dependent, isn't it? Tim Rowledge wrote: > Err, I am under the impression that the .changes file is to be expected > in the same directory as the .image and the .sources in the same > directory as the VM. Or more exactly, the .sources are expected to be in > the path returned by vmPath and the .changes in the CWD as set by > 'setDefaultDirectoryFrom: Smalltalk imageName'. Right. However, the Unix VM sets vmPath to the *image* directory, just to confuse things. Ian once explained why this is so, but I couldn't quite remember. IMO "vmPath" is just a misnomer and should read "sourcePath", because that's the only actual use for it in the image. Also, let's not confuse "CWD" and "default dir" and "image dir" because it's not the same. CWD is the current directory when you invoke Squeak. Both the VM directory and the image directory can be different from that, and certainly will be in a Squeak-as-scripting-language situation, in which the default dir should probably made equal to the CWD. Or somthing like this ;-) -- Bert |
|
From: David T. L. <le...@ma...> - 2002-09-06 14:31:16
|
On Fri, Sep 06, 2002 at 12:04:59PM +0200, Bert Freudenberg wrote:
> On Fri, 6 Sep 2002, Andreas Raab wrote:
>
> > That wasn't the problem. What I needed was knowing from within the
> > *image* what the CWD is. E.g., FileDirectory takes the "default
> > directory" from the image name (and I am not inclined to change this)
> > but this means you cannot find out where something like a log file goes.
>
> I'm pretty sure OSProcess allows you to query the CWD. It's rather
> platform-dependent, isn't it?
Well, it *should* be rather platform independent. On a Unix platform,
ThisOSProcess>>getCwd answers the result of getcwd(), which is as described
by Ian earlier in this thread. On any other platform, it answers the result
of "FileDirectory default pathName", which would match the current
Windows behavior.
I agree with keeping the Unix VM behavior as is (a "-cwd" flag would not
add anything useful).
On Windows, the image directory is the sensible default location for log
files, but I expect that it would be possible to pick up the "Start in:"
path (as displayed in the properties dialog of a desktop icon for running
Squeak). Presumably that's what you get from a Win32 call to
GetCurrentDirectory(), right? If so, this would follow the same behavior
as the Unix implementation, which would in most cases end up being the
image directory anyhow. If the user wanted the log files to go somewhere
else, s/he would set the "Start in:" path to the location for the log files,
and specify an explicit path the the image on the command line ("Target:"
in the properties dialog).
Hmm, I guess I had better go add the correct #getCwd support for Win32
into OSProcess, now that I think about it.
Dave
|
|
From: David T. L. <le...@ma...> - 2002-09-06 21:42:27
|
On Fri, Sep 06, 2002 at 10:31:12AM -0400, David T. Lewis wrote:
>
> On Windows, the image directory is the sensible default location for log
> files, but I expect that it would be possible to pick up the "Start in:"
> path (as displayed in the properties dialog of a desktop icon for running
> Squeak). Presumably that's what you get from a Win32 call to
> GetCurrentDirectory(), right? If so, this would follow the same behavior
> as the Unix implementation, which would in most cases end up being the
> image directory anyhow. If the user wanted the log files to go somewhere
> else, s/he would set the "Start in:" path to the location for the log files,
> and specify an explicit path the the image on the command line ("Target:"
> in the properties dialog).
>
> Hmm, I guess I had better go add the correct #getCwd support for Win32
> into OSProcess, now that I think about it.
OK, I wrote the primitiveGetCurrentWorkingDirectory for Windows, and here
is what I find on a Windows ME system:
1) If I run Squeak from a desktop icon, the cwd is the "Start in:" path
as defined in the properties dialog. Normally, this would be the same as
the image directory.
2) If I run Squeak from a DOS shell, the cwd is that of the DOS shell
(same as would be expected on Unix), independent of the location of the
VM or the image. In practice, the cwd would usually turn out to be the
same as the image directory.
3) If I drag and drop an image file onto a VM in some arbitary directory,
the cwd is C:\WINDOWS.
The first two behaviors are reasonable. The third one is unexpected (at
least to me). Therefore, I think that the right thing to do on Windows
is to assume that the cwd "should be" the same as the image directory,
and put the log files in the image directory. Which of course is what
Andreas just implemented, so this should just serve as confirmation that
it was the right thing to do.
Dave
|
|
From: Andreas R. <And...@gm...> - 2002-09-06 22:45:30
|
> OK, I wrote the primitiveGetCurrentWorkingDirectory for > Windows, and here is what I find on a Windows ME system: [...] > 3) If I drag and drop an image file onto a VM in some > arbitary directory, the cwd is C:\WINDOWS. And if you would run this on XP you'd end up in "C:\Documents and Settings\user name". And if you would run this on Win98 you'd end up on the desktop. Etc. etc. etc. I'm just tired of all that mess ;-) Cheers, - Andreas |
|
From: Tim R. <ti...@su...> - 2002-09-06 23:34:53
|
In message <002f01c255f6$f680ff00$f7affea9@Atlantis>
"Andreas Raab" <And...@gm...> wrote:
> I'm just tired of all that mess ;-)
Well you could always move over to a Real Man's (tm) Operating System
and use an Acorn :-) Note very apropos random sigline, yet again...
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
...now touch these wires to your tongue!
|
|
From: David T. L. <le...@ma...> - 2002-09-07 01:14:59
|
On Sat, Sep 07, 2002 at 12:44:29AM +0200, Andreas Raab wrote: > > 3) If I drag and drop an image file onto a VM in some > > arbitary directory, the cwd is C:\WINDOWS. > > And if you would run this on XP you'd end up in "C:\Documents and > Settings\user name". And if you would run this on Win98 you'd end up on > the desktop. Etc. etc. etc. > > I'm just tired of all that mess ;-) You can almost count the number of committees that designed it :/ |
|
From: Lex S. <le...@cc...> - 2002-09-07 15:49:46
|
Just to toss out, Bert's comment about scripts is a real issue. I tried to use Squeak in a scripting situation on Windows once, and got frustrated because of it not inheriting the worknig directory. I had to fully specify every filename. (Another nuisance was that it didn't block when called from a batch script, but instead forked into its own independent thread.) So, I would vote that we in fact use whatever Windows gives you. In a drag-and-drop situation, you are unlikely to care what "FileDirectory default" is, anyway, are you? Regarding the sources file, I actually find it pretty annoying to have this stupid symlink in every directory I run Squeak from. It would be really nice if the image could query for a sources directory and then use that. On Unix that would be some system location (though probably overide-able by an environment variable). For Windows, I don't know which would make more sense: VM or image. I would guess VM, just because Windows programs tend to have a single directory tree holding all of the standard files. For the changes file, of course, we can derive a name from the image name, and thus we have no trouble. (Assuming the name is fully qualified, and which we could insist that it is.) Fileouts, I guess, should go in the image directory, because they seem like the same sort of development type thingie as an image, anyway, and since it would be annoying if fileouts started appearing on the desktop. Logfiles can go anywhere on Windows; the VM directory would seem the most natural place, if it is writable. Lex PS -- on Unix it is possible that your directory is unlinked and doesn't have a position. But I suppose we can live with ignoring this awkward case! :) The usual Unix idea is not to insist on having an absolute position in the file hierarchy. Not every file has a name in Unix; but then again, that's an immediate conflict with the Squeak StandardFileStream class. |
|
From: Andreas R. <And...@gm...> - 2002-09-07 16:07:17
|
Lex, > Just to toss out, Bert's comment about scripts is a real > issue. I tried to use Squeak in a scripting situation on > Windows once, and got frustrated because of it not inheriting > the worknig directory. I had to fully specify every filename. > (Another nuisance was that it didn't block when called > from a batch script, but instead forked into its own > independent thread.) It would if you'd use a VM which is compiled as "console application". Windows apps have this weird thing that they are either console apps (in which case they *do* inherit the CWD from the command line and block the invoking thread by default) or GUI apps (in which case you get all this wonderful behavior described before). I tried to figure out whether someone is starting Squeak from the command line or not (e.g., to make this behavior transparent) but apparently there is no way to figure this out. "GUI apps" are simply forked off. "Console apps" on the other hand open one of these really ugly command line prompts whenever you start them by double clicking (and I couldn't find a way of getting rid of those fast enough to make it unnoticable to the user). I could compile a console VM in addition to the GUI VM but sofar there hasn't been a lot of interest in this. > So, I would vote that we in fact use whatever Windows gives you. In a > drag-and-drop situation, you are unlikely to care what "FileDirectory > default" is, anyway, are you? I am. That was exactly the reason why I changed it. > Regarding the sources file, I actually find it pretty annoying to have > this stupid symlink in every directory I run Squeak from. It would be > really nice if the image could query for a sources directory and then > use that. On Unix that would be some system location (though probably > overide-able by an environment variable). For Windows, I don't know > which would make more sense: VM or image. I would guess VM, just > because Windows programs tend to have a single directory tree holding > all of the standard files. Squeak is already looking in the VM directory to find the source files. I don't know if that's any different on Unix but I have all the .sources in the VM directory and hardly ever copy anything around. Cheers, - Andreas |
Thanks for helping keep SourceForge clean.
X