squeak-vmdev — CVS-related Virtual Machine Development Issues

Re: [Squeak-VMdev] RFC: Default VM directory

[David T. L. <le...@ma...>]

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 :/

RE: [Squeak-VMdev] RFC: Default VM directory

[Tim R. <ti...@su...>]

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!

RE: [Squeak-VMdev] RFC: Default VM directory

[Andreas R. <And...@gm...>]

> 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

Re: [Squeak-VMdev] RFC: Default VM directory

[David T. L. <le...@ma...>]

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

Re: [Squeak-VMdev] RFC: Default VM directory

[David T. L. <le...@ma...>]

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

RE: [Squeak-VMdev] RFC: Default VM directory

[Bert F. <be...@is...>]

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

RE: [Squeak-VMdev] RFC: Default VM directory

[Ian P. <ian...@in...>]

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

RE: [Squeak-VMdev] RFC: Default VM directory

[Andreas R. <And...@gm...>]

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

RE: [Squeak-VMdev] RFC: Default VM directory

[Tim R. <ti...@su...>]

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

RE: [Squeak-VMdev] RFC: Default VM directory

[Ian P. <ian...@in...>]

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
 

Re: [Squeak-VMdev] RFC: Default VM directory

[John M M. <jo...@sm...>]

On the mac for os 9 and previous the directory that contains the image  
becomes the default directory. So opening foo.log drops it into the  
image directory.

This is different for plugins, those get loaded from the directory the  
VM is running from

For os-x, it follow more of the unix flow as mentioned by Ian, with  
some issues for which I've seen a technote floating about, your note is  
a reminder to look at that further. However I think it stated I can't  
use the os-9 calls to change the working directory directly. I'll look  
further.


On Thursday, September 5, 2002, at 02:13  PM, Andreas Raab wrote:

> Hi Guys,
>
> I just had the need to analyze log files which were written by the VM
> (in my case the Squeak3D.log) It turns out that this is a pain on
> Windows since your default directory is apparently set pretty much
> randomly.
>
> So I changed this to be the image location by default. How is this
> handled on the other platforms?! Can we agree on the "definite default
> working directory" for the VM to be set to the image location?!
>
> Cheers,
>   - Andreas
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Squeak-VMdev mailing list
> Squ...@li...
> https://lists.sourceforge.net/lists/listinfo/squeak-vmdev
>
>
--
======================================================================== 
===
John M. McIntosh <jo...@sm...> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===

RE: [Squeak-VMdev] RFC: Default VM directory

[Ian P. <ian...@in...>]

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

RE: [Squeak-VMdev] RFC: Default VM directory

[Andreas R. <And...@gm...>]

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
> 

[Squeak-VMdev] Changes in B3DAcceleratorPlugin

[Andreas R. <And...@gm...>]

Hi Guys,

I've done some changes which affect the B3DAcceleratorPlugin code. I've
unified the HW/SW renderer attributes in a generic 'flags' variable
which is passed down to the renderer creation primitives. In addition an
extra flag has been introduced to explicitly request stencil buffer
support (which is required for some of the stuff that I'm doing).

This means, the renderer creation primitive (glCreateRenderer) is now
obsolete - a new creation primitive has been introduced
(glCreateRendererFlags) which takes a bunch of flags along as an
argument. What you need to do are three things:
a) Extract the former HW/SW renderer attribute from the flags. This can
be done as simply as
	int allowSoftware = (flags & B3D_SOFTWARE_RENDERER) != 0;
	int allowHardware = (flags & B3D_HARDWARE_RENDERER) != 0;
b) The platform code must check if any "unsupported" flags are
requested. This is needed in order to allow "experimental" extensions of
the flags without getting strange results if that code is run on a
platform not supporting the request. E.g., if you only support the above
two flags then there should be some code saying something like:

#define SUPPORTED_FLAGS (B3D_SOFTWARE_RENDERER | B3D_HARDWARE_RENDERER)

	if( (flags & ~SUPPORTED_FLAGS) != 0) /* check for unsupported
flags */
		return -1; 

c) In order to support stencil buffering (which is the only capability
newly introduced) you will have to modify the renderer creation code.
For Unix this means adding a non-zero value to GLX_STENCIL_SIZE. For
MacOS it means adding an entry to the attributes list requesting a
non-zero AGL_STENCIL_SIZE.

If any of you need help with making these changes, let me know. They are
pretty trivial to make if you know what you're doing ;-)

Cheers,
  - Andreas

Re: [Squeak-VMdev] RFC: Default VM directory

[Ian P. <ian...@in...>]

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

[Squeak-VMdev] RFC: Default VM directory

[Andreas R. <And...@gm...>]

Hi Guys,

I just had the need to analyze log files which were written by the VM
(in my case the Squeak3D.log) It turns out that this is a pain on
Windows since your default directory is apparently set pretty much
randomly.

So I changed this to be the image location by default. How is this
handled on the other platforms?! Can we agree on the "definite default
working directory" for the VM to be set to the image location?!

Cheers,
  - Andreas

Re: [Squeak-VMdev] CVS school! :-)

[<gor...@bl...>]

Hi Tim and all!

Quoting Tim Rowledge <ti...@su...>:
> In message <E17...@le...>
>           gor...@bl... wrote:
> > My shell transcript:
> > 
> > gohu@marvin:~/squeak/srctrees/play/test/other$ mkdir replugin
> > gohu@marvin:~/squeak/srctrees/play/test/other$ cd replugin
> > gohu@marvin:~/squeak/srctrees/play/test/other/replugin$ ls >
kid.txt
> > gohu@marvin:~/squeak/srctrees/play/test/other/replugin$ ls >
> > kaboodle.txt
> .
> and of course SqCVS is going to be able to do all this for us with a
> simple drag/click/magic, right ? It occurs to me that a well fleshed
> out
> SqCVS tool in a nicely trimmed image would be a quite decent tool in
> and
> of itself. Not that it has a particularly high bar to jump to be better
> than other cvs tools I've seen so far.

True. I have a nice list of things to fix in SqCVS so that it actually can be
used. Just lying there and waiting for me...

But since noone has offered to help me out with SqueakMap (hint), and I think
that SqueakMap is more important for the community I am trying to finish that
before jumping back to SqCVS.

Anybody implementing SSH in the meantime? :-) (I think someone said something
about that on the list recently...)

regards, Göran

Göran Hultgren, gor...@bl...
GSM: +46 70 3933950, http://www.bluefish.se
\"Department of Redundancy department.\" -- ThinkGeek

Re: [Squeak-VMdev] CVS school! :-)

[Tim R. <ti...@su...>]

In message <E17...@le...>
          gor...@bl... wrote:


> My shell transcript:
> 
> gohu@marvin:~/squeak/srctrees/play/test/other$ mkdir replugin
> gohu@marvin:~/squeak/srctrees/play/test/other$ cd replugin
> gohu@marvin:~/squeak/srctrees/play/test/other/replugin$ ls > kid.txt
> gohu@marvin:~/squeak/srctrees/play/test/other/replugin$ ls >
> kaboodle.txt
.
.
.
.
.

and of course SqCVS is going to be able to do all this for us with a
simple drag/click/magic, right ? It occurs to me that a well fleshed out
SqCVS tool in a nicely trimmed image would be a quite decent tool in and
of itself. Not that it has a particularly high bar to jump to be better
than other cvs tools I've seen so far.

tim

-- 
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Strange OpCodes: PO: Punch Operator

Re: [Squeak-VMdev] CVS school! :-)

[<gor...@bl...>]

Oh yeah forgot to tell you, I am taking a break at this point with the
guide and await reactions.

regards, Göran

[Squeak-VMdev] CVS school! :-)

[<gor...@bl...>]

Hi Andrew and all!

"Andrew C. Greenberg" <we...@mu...> wrote:
> What I would like to do is this: (a) Add a folder, RePlugin, to the
> Cross directory; (b) add some files; and (c) commit the kid and 
> kaboodle.

Except for the actual branching and moving over to that branch (but that
I have explained that in detail at minnow now:
http://minnow.cc.gatech.edu/squeak/2684), I did the operations you would
typically do, but on my own fake CVS repository - so paths, directories
and filenames are of course silly fakes. (Note: It might be a good idea
to create a local one if you want to "learn" or test things.)

When I start here I have already checked out "test" (like "squeak") into
empty dir "play". I have also created a branch and switched over to that
according to minnow.

My shell transcript:

gohu@marvin:~/squeak/srctrees/play/test/other$ mkdir replugin
gohu@marvin:~/squeak/srctrees/play/test/other$ cd replugin
gohu@marvin:~/squeak/srctrees/play/test/other/replugin$ ls > kid.txt
gohu@marvin:~/squeak/srctrees/play/test/other/replugin$ ls >
kaboodle.txt
gohu@marvin:~/squeak/srctrees/play/test/other/replugin$ ls
kaboodle.txt  kid.txt
gohu@marvin:~/squeak/srctrees/play/test/other/replugin$ cd ..
gohu@marvin:~/squeak/srctrees/play/test/other$ cvs update
? replugin
cvs server: Updating .
gohu@marvin:~/squeak/srctrees/play/test/other$ cvs add replugin
? replugin/kaboodle.txt
? replugin/kid.txt
Directory /var/cvs_play/test/other/replugin added to the repository
--> Using per-directory sticky tag `extension-other-branch'
gohu@marvin:~/squeak/srctrees/play/test/other$ cd replugin/
gohu@marvin:~/squeak/srctrees/play/test/other/replugin$ cvs add *
cvs add: cannot add special file `CVS'; skipping
cvs server: scheduling file `kaboodle.txt' for addition on branch
`extension-other-branch'
cvs server: scheduling file `kid.txt' for addition on branch
`extension-other-branch'
cvs server: use 'cvs commit' to add these files permanently
gohu@marvin:~/squeak/srctrees/play/test/other/replugin$ cvs commit -m
"Added two files on branch"
cvs commit: Examining .
RCS file: /var/cvs_play/test/other/replugin/Attic/kaboodle.txt,v
done
Checking in kaboodle.txt;
/var/cvs_play/test/other/replugin/Attic/kaboodle.txt,v  <-- 
kaboodle.txt
new revision: 1.1.2.1; previous revision: 1.1
done
RCS file: /var/cvs_play/test/other/replugin/Attic/kid.txt,v
done
Checking in kid.txt;
/var/cvs_play/test/other/replugin/Attic/kid.txt,v  <--  kid.txt
new revision: 1.1.2.1; previous revision: 1.1
done


Ok, that was that. Then typically the port maintainer needs to do the
following to merge that stuff into the trunk (I moved the workingcopy
back to the trunk before this using "cvs update -A"):

gohu@marvin:~/squeak/srctrees/play/test$ cvs update -d -j
extension-other-branch
cvs server: Updating .
cvs server: Updating cross
cvs server: Updating other
RCS file: /var/cvs_play/test/other/ls.txt,v
retrieving revision 1.1
retrieving revision 1.1.2.1
Merging differences between 1.1 and 1.1.2.1 into ls.txt
rcsmerge: warning: conflicts during merge
cvs server: Updating other/replugin
U other/replugin/kaboodle.txt
U other/replugin/kid.txt
cvs server: Updating test
cvs server: Updating test/subdir
gohu@marvin:~/squeak/srctrees/play/test$

The conflict was because I also edited the file "ls.txt" in both trunk
and branch. Ignore that.
The "-d" switch is important here because "update" normally doesn't suck
down new directories like "checkout" do.

regards, Göran

Re: [Squeak-VMdev] Vouching stuff and more!

[Tim R. <ti...@su...>]

In message <Pin...@ti...>
          Ian Piumarta <ian...@in...> wrote:

> > and then do a full replace at SF with what he has.
> 
> Yup.
Soon, please, pretty please. With sugar on top.

tim
-- 
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
C:\GRAPHICS\GIF\NAUGHTY\FILTHY\DISGUSTING\WOW!

Re: [Squeak-VMdev] Re: [SqueakSF] SqeakSF Policy Proposal [was: Re: [VM 3.2-4] build problems, if an acinclude.m4 has been added]

[Stephan R. <sr...@ev...>]

Tim Rowledge wrote:
> On Tuesday, August 20, 2002, at 06:51  AM, Stephan Rudlof wrote:
> 
>>>>>0. To get this policy work, there is the need to introduce platform 
>>>>>specific
>>>>>src trees - e.g. src_unix, src_win, src_mac - for the different ports,
>>>>> which
>>>>>contain the 'official' proven sources. Currently there aren't any, 
>>>>>but it
>>>>>isn't possible to store full ports at SF without them. There has to 
>>>>>be one
>>>>>source tree for each port, since on each platform there may be a 
>>>>>different
>>>>>number of plugins or (not so good) a different version of the VM, 
>>>>>which are
>>>>>working in reality.
>>>>
>>>If I am not mistaken the source tree is partitioned today into one tree
>>>for each port and one "Cross" tree with everything in common... Perhaps
>>>I misunderstood.
>>
>>I mean the sources generated by VMMaker here: an 'official' port doesn't
>>necessarily contain all possible plugins. And it runs stable with a VM
>>generated from whatever Squeak version.
>>
>>AFAIK VMMaker generated sources are not at SF.
> 

> I thought I had very clearly explained how VMMaker works and what I 
> anticipated the role of SF/anyotherrepositorywechose would be.

Yes.

> 
> VMMaker generated sources are not expected to be stored on SF; only the 
> handwritten code (sqRPCWindow.c etc) should be in that tree. VMM takes the 
> tree of files under SF/platforms along with the VM related classes in the 
> image and produces a combination ready to build a VM for a particular 
> platform and configuration of internal/external/ignored plugins.
> 
> One day, I hope that we will be in a position to do automated generated 
> sets of sources for each main platform and store them  somewhere sensible 
> so that people simply wanting to compile a latest vm can do so without the 
> difficulty of having to open a UI tool and press a button or two. Right 
> now that isn'tin place but I beleive I have been told it can be done via 
> SF related tools.
> 
> To determine which plugins work for each platform it is supposed to be 
> possible to look at the two directories platforms/platName/plugins and 
> platforms/Cross/plugins. If a plugin is in platforms/Cross/plugins and NOT 
> in platforms/platName/plugins it had better damn well not have any 
> platform dpendencies and must work on any machine. As examples, consider 
> MiscPlugin. If a plugin appears in Cross and any platofrm specific place 
> then it is supposed to be the case that it requires some platform support.
>   Thus if it doesn't appear in your platforms's plugins list it probably 
> doesn't work for it.

Recently I've used Ian's sources to compile a VM. His distribution contains
- and it has to - the VMMaker generated files, too.
My point was to make it possible to the port maintainers to state exactly,
what the 'official' distribution is: without the VMMaker generated sources
you have to generate them: e.g. I wasn't able to generate Ian's choice of
plugins, since some have been missing in my - newer - image.
There is more:
- one maintainer may choose some image version, another one another
  for generating the sources;
- a maintainer may *not* trust some plugins generatable by VMMaker.

I have had the impression, that the port maintainers are very picky
regarding these issues.

> 
> You can also get a more direct visual answer to the question by opening 
> the VMMakerTool and just using the menu in the bottom-left pane to say 
> 'make all external'. ONLY plugins that the platform can support will be 
> moved to the external plugins list. For any particular plugin you can look 
> in its class for the messages #requiresPlatformFiles and 
> #requiresCrossPlatformFiles etc. Of course, it is conceivable that a 
> plugin may have innappropriate implementations of these messages until 
> someone discovers and fixes the situation.
> 

> Platform specific full source trees should not be maintained in any system 
> like SF since it would add another layer of confusion.

I'm not so sure here: it also can be a layer of confusion, if I
- check out some SqueakSF platform and cross sources (tagged as dist),
- generate the other sources by VMMaker in my uptodate image,
- compile,
and something doesn't work.

So my question is: how is an 'official' distribution defined?

> Tarred up (or 
> otherwise bundled) platform trees ready to just compile are another matter 
> and have been under consideration for the do-it list for ages.

This has been given by e.g. Ian so far.


Greetings,

Stephan

> 
> ti...@su...
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Squeak-VMdev mailing list
> Squ...@li...
> https://lists.sourceforge.net/lists/listinfo/squeak-vmdev
> 


-- 
Stephan Rudlof (sr...@ev...)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3

Re: [Squeak-VMdev] Vouching stuff and more!

[Ian P. <ian...@in...>]

On Wed, 21 Aug 2002 gor...@bl... wrote:

> My guess (ONLY a guess) is for example that Ian will begin go through
> the code at SF, pick out the cherries

I went through the SF code in May and looked at all the fixes that had
been applied.  A few I pulled into my sources, some were irrelevant
(because of // development in my sources) and the rest I fixed from
scratch.  The number of "real" problems reported/fixed at SF was actually
quite low.  Most of the changes there were more-or-less cosmetic.

> integrate them in his own current sources

My first release of 3.2-1 in early June had fixed all the problems
reported at SF (and a few more besides) modulo a couple of trivialities
(where I'd inadvertently missed a line in ediff -- which Ned discovered
and corrected in pretty short order, I might add. ;)

> and then do a full replace at SF with what he has.

Yup.

Ian

[Squeak-VMdev] Vouching stuff and more!

[<gor...@bl...>]

(still including Gerardo and Lantz since they are not on this list)

Eric Scharff wrote:
> I apologize that I was not aware of the vouching scheme before receiving
> this email.  Thanks for the information.

No apologize needed. :-) Essentially it was a suggestion from Andreas
which IMHO sounded sane and there where no comments from the rest so I
simply went ahead and tried to introduce it. 

It will probably NOT mean anyone needs to be removed, that was not the
intention. The intention is to make sure we are all in agreement with
the "soon to be in effect" policy and that we follow it. The port
maintainers (and others like me) simply felt it was a good idea to try
to do something in order to maintain "order in the class". Especially
now when we are introducing branches and tags etc. :-)

Essentially the vouch simply is there to ensure that people are aware of
the policy and to make sure someone mops up the mess if something goes
bad. And as long as people stick to the branches no harm is done if they
mess up anyhow.

Andreas Kuckartz wrote:
> I did not really follow the thread and do not know why there is a debate
> about removing people (instead of attracting more or leaving it as it is).
> In fact I think this is an attempt to fix a nonexisting problem.
>
> Anyway, I probably will not be able to contribute to the VM sources during
> the next months and therefore do not care much about beeing removed or not.

We are not going to remove people - I am sure we will establish vouches
for anyone already "in". 

But there HAS been a problem. Especially Andreas Raab and Ian Piumarta
(I don't really know about Tim or John) have not felt that SF was
working good - they where simply not "in the boat". After a long thread
with a lot of constructive ideas from different people we actually
(gasp!) agreed on a model.

So I am pulling this along so that we will have a policy that seems
sound and so that all port maintainers are "in the boat together". I
think we have that now - it's simply up to me to finish the darn
swikipages so that we can all dig in and we also need to get all these
vouches placed so that the vouching model can be considered "active".

My guess (ONLY a guess) is for example that Ian will begin go through
the code at SF, pick out the cherries, integrate them in his own current
sources and then do a full replace at SF with what he has. His code has
evolved a LOT lately so this will be a very good thing for the Unix
port.

Anyway, Eric has acknowledged that he has read through the Swiki pages I
have written so far and I am placing my trust vouch on him. Basically it
all boils down to this: DON'T MESS WITH THE TRUNK & KEEP THOSE TAGNAMES
ACCORDING TO CONVENTION. Everything else is forgivable. :-)

And also - everything is fixable. :-)

Current list of non vouched:

Andreas Kuckartz 
Gerardo Richarte 
Jörn Eyrich 
Lantz Rowland  
Stephan Rudlof 

regards, Göran

Re: [Squeak-VMdev] Vouching scheme!

[<gor...@bl...>]

Tim Rowledge <ti...@su...> wrote:
> I will vouch for Craig, Dave Lewis, Andy Greenberg.

Ok, swiki page updated. I moved them up below you closer to "Da Man".

> On Tuesday, August 20, 2002, at 07:02  AM, gor...@bl... 
> wrote:
> > Please read my policy pages on http://minnow.cc.gatech.edu/squeak/2512
> > and RESPOND to me that you have read them, ok? Remember, I am pestering
> > you all with this so that our port maintainers (Tim, Andreas, Ian, John)
> > all can agree on using SF. And we all want THAT don't we!? :-)
> Well, I'd really like if it we could finally get off our collective arses 
> and get it up to date. I couldn't care tuppence if anyone wants to declare 

This will happen as soon as I have gotten the rules down. I will
continue today and focus on how to do the actual tagging/branches
(because that is where it get's non trivial).

> that SF is only a cache of the 'true master' on their own disc as long as 
> it is a reasonably up to date and cared for cache. Get those cache 
> updating algortihms in use!

I think stuff will begin soon.

regards, Göran