Folks -
If you got the last batch, you should get these too.
- Dan ----------------------- 4539furtherToFlaps-sw -- Scott Wallace -- 22 November 2001 Fixes proportional relayout of flap tabs upon resize of squeak-app window. Offers a preference that governs whether flaps along the bottom of the screen should have their positions automatically be positioned, and two other preferences relating to flaps and navigators. Hopefully users will be happy with the settings provided by default. The intent is to allow the undiluted use of the old non-flap-based navigator for those who have bonded to it, while offering a completely flap-based alternative to it."
4540FasterWakeText-di -- Dan Ingalls -- 21 November 2001 When you enter a text pane, it opens the scroll bar and highlights the text. When you leave a text pane, if closes the scroll bar and clears the highlight. However entering invalidates the entire text pane, thus causing a complete repaint. This should not be necessary... And it isn't. This changeSet fixes the problem by only repainting the selection, leading to considerably faster window and scrollbar response in textually oriented windows.
4541FlapsTweak-di -- Dan Ingalls -- 22 November 2001 Fixes RealEstateAgent>>reduceByFlaps: so it works properly -- ie it uses full width screen if all shared flaps (other than 'Painting') are along the bottom. Also includes a rewrite of Flaps sharedFlapsAlongBottom so that it is more robust with respect to future changes in the set of flaps that are shared.
4542UncollapseFix-di -- Dan Ingalls -- 22 November 2001 The recent improvement to uncollapsing of SystemWindows had the side-effect of not unlocking the panes of a window if it was collapsed when not active. This changeSet fixes that problem.
MMm well I think I added truncate so I'm wondering if it's really busted on non-mac platforms.
You see
int sqFileTruncate(SQFile *f,int offset) { /* Truncate the file*/
if (!sqFileValid(f)) return interpreterProxy->success(false); if (ftruncate(f->file,offset)) return interpreterProxy->success(false); f->fileSize = ftell(f->file); return 1; }
But really on Unix f->file points to a FILE structure, but ftruncate needs a file descriptor (an integer).
#include <unistd.h> int sqFileTruncate(SQFile *f,int offset) { /* Truncate the file*/
if (!sqFileValid(f)) return interpreterProxy->success(false); if (ftruncate(fileno(f->file),offset)) return interpreterProxy->success(false); f->fileSize = ftell(f->file); return 1; }
Ah, thoughts are welcome. Of course I'm going to make the change because the SUnits fail... Hint it works on the mac because ftruncate didn't exist in a workable form for CW 6 so I added one.
In the pending 3.2.1 mac vm and the 3.1.2 beta VM that some of you have noticed there is a feature to allow you to drag and drop (jpeg, text, mp3 (no smalltalk support yet) onto the VM.
However this fails in the current image because EventSensor is asked to flush the VM event queue at the most interesting times, like at startup. I think it's gets rid of mouse clicks etc at startup time and when you switch between projects and I noticed some interesting code Dan added in Oct (flushNonKbdEvents) that tampers with the event queue. However it has the side effect of removing all traces of the pending drag and drop events we've queued. This change set ensures that drag and drop event don't silently disappear at startup time.
Note at application startup time we might get a list of 100 jpegs to open, these get passed upwards as queued VM drag and drop events, then everyone is happy, unless you flush the queue.
This is reissued because of a collision in a change set that was in progress
In the pending 3.2.1 mac vm and the 3.1.2 beta VM that some of you have noticed there is a feature to allow you to drag and drop (jpeg, text, mp3 (no smalltalk support yet) onto the VM.
However this fails in the current image because EventSensor is asked to flush the VM event queue at the most interesting times, like at startup. I think it's gets rid of mouse clicks etc at startup time and when you switch between projects and I noticed some interesting code Dan added in Oct (flushNonKbdEvents) that tampers with the event queue. However it has the side effect of removing all traces of the pending drag and drop events we've queued. This change set ensures that drag and drop event don't silently disappear at startup time.
Note at application startup time we might get a list of 100 jpegs to open, these get passed upwards as queued VM drag and drop events, then everyone is happy, unless you flush the queue.
In the 3.2.1 Carbon VM this change set allows you to have 255 character file/directory names.
Support for this feature will back ported to System 8.1 and beyond in a few weeks.
On Fri, Nov 23, 2001 at 12:56:19AM -0800, John M McIntosh wrote:
MMm well I think I added truncate so I'm wondering if it's really busted on non-mac platforms.
<snip>
But really on Unix f->file points to a FILE structure, but ftruncate needs a file descriptor (an integer).
Yes, it's broken on Linux. It gives a "primitive has failed" error. I tried your fixed version and it works fine.
- Dave
p.s. "ftruncate()" is certainly a misleading name. All of the other "fwhatever()" calls expect to use a FILE structure.
Ok, I've an version of the Squeak VM 3.2.1 awaiting in the wings which has 64bit? file support and has been compiled under Apple's Project Builder versus CW. So I'm looking for a few good folks to kick the tires. Please email me if you can test (stress test is best).
Ok, I've an version of the Squeak VM 3.2.1 awaiting in the wings which has 64bit? file support and has been compiled under Apple's Project Builder versus CW. So I'm looking for a few good folks to kick the tires. Please email me if you can test (stress test is best).
Ok, I shipped a 3.2.1Beta1 to those who asked. If you didn't get one then email me. Only runs on OS-X right at the moment, and still quite a bit of work to do.
Excuse me, I'd like to get the SocketPlugin for carbon squeak (for mac os X 10.1). The plug in is needed for using some method of Socket class (see for example Socket>>primSocket: socketID receiveUDPDataInto: aStringOrByteArray startingAt: startIndex count: count in Squeak3.0) Where can I find it and the others plugins? What is the latest-stable carbon VM? Thank you!!
// Giovanni JJ Giorgi http://daitanmarks.sf.net // ^. .^ Building software is like quantum mechanics: you can predict // ='= what it will do, or when it will be ready -- but not both. // Sol-Tec Soluzioni Tecnologiche S.r.L. http://www.sol-tec.it
On Wed, Nov 28, 2001 at 05:32:07PM +0100, Giovanni Giorgi wrote:
Excuse me, I'd like to get the SocketPlugin for carbon squeak (for mac os X 10.1). The plug in is needed for using some method of Socket class (see for example Socket>>primSocket: socketID receiveUDPDataInto: aStringOrByteArray startingAt: startIndex count: count in Squeak3.0) Where can I find it and the others plugins?
The SocketPlugin should be compiled inline. You can check which Plugins are inlined by printing
Smalltalk listBuiltinModules
You'l see that the SocketPlugin is allready there. No need to install an adional Plugin.
What is the latest-stable carbon VM?
I'm using Squeak 3.1Alpha1MTCarbon from ftp://ftp.cs.uni-magdeburg.de/pub/Smalltalk/Smalltalk/Squeak/3.1beta/mac/Squeak3.1.1-mac-carbon-vm.sit
Marcus
Ok, I've done a little bit of revision. Windows users are welcome to kick the tires.
Note it still will delete directories that start with 'A' and 32 A's. Yes yes I should change that, maybe the next version. Yes you need 2GB or so of free disk space to run this.
Now it should run to completion on the macintosh. For Unix machines it should complain about files that get deleted while open (testFileCreate and testFileDelete), and I *think* it should complain about truncate not working correctly! For Windows machines I have no idea what happens. Note the change set is in UUENCODE format versus binhex allowing windows users the ability to read it (I *think*)
On Fri, Nov 23, 2001 at 01:08:22AM -0800, John M McIntosh wrote:
Ok, I've done a little bit of revision. Windows users are welcome to kick the tires.
Note it still will delete directories that start with 'A' and 32 A's. Yes yes I should change that, maybe the next version. Yes you need 2GB or so of free disk space to run this.
Now it should run to completion on the macintosh. For Unix machines it should complain about files that get deleted while open (testFileCreate and testFileDelete), and I *think* it should complain about truncate not working correctly! For Windows machines I have no idea what happens. Note the change set is in UUENCODE format versus binhex allowing windows users the ability to read it (I *think*)
Hmm... evidently the Unix VM has no signal handler for SIGXFSZ. The VM does a nice clean exit() when you run the large file write part of the test!
Under gdb, it looks like this:
lewis@dtlewis:/home/lewis/squeak/squeak3.2a > gdb ./squeak GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-suse-linux-gnu"... (gdb) set args -memory 30m squeak.image (gdb) r Starting program: /home/lewis/squeak/squeak3.2a/./squeak -memory 30m squeak.image
Program received signal SIGXFSZ, File size limit exceeded. 0x401b6504 in __libc_write () from /lib/libc.so.6 (gdb)
On Fri, Nov 23, 2001 at 01:08:22AM -0800, John M McIntosh wrote:
Ok, I've done a little bit of revision. Windows users are welcome to kick the tires.
On Linux, the #testFileCreate test fails in the #subFileCreate method when it tries to do the following: self should: [file _ shortDir forceNewFileNamed: aFileName] raise: Error.
I'm running Linux with an NFS mounted Squeak directory, which produces rather odd failure symptoms. The #forceNewFileNamed: deletes the A/A.txt file, but there is another open reference to A/A.txt from Squeak, so the file does not really disappear yet. And since it's on an NFS mounted file system, NFS seems to accomplish this by keeping a hidden file named something like "A/.nfs0002c80300000023". This leads to TestRunner attempting to delete the "A" directory in its tearDown method, which fails due to the directory not being empty.
All of this seemed rather mysterious until I noticed the hidden NFS droppings, so I thought it would be worth describing.
Dave
squeak-dev@lists.squeakfoundation.org