 |
|
||
|
|
Code Fragments |
11) Add the source code for the PrintJob plugin.
The source code for the PrintJob (RealPrintJob and RealPrintJobPlugin). This source, plus the PrintJob Plugin you can find at the offical distribution site (ftp://st.cs.uiuc.edu/Smalltalk/Squeak/3.8/mac/carbonplugins/), allows you to print a Form, using the mac os print manager interface.
Printing of a Form is supported in OS-X and Mac Classic. Mac Classic users need to ensure they have the latest VM, older VM will not work.
10) A few days in October was spent building an interface to libTIFF
The binaries for the TIFF decoder/encoder.
9) Sept/Oct was spent working an MPEG video/audio player
The binaries and or the source code for the MPEG decoder
8) July of 2000 was spent getting Full Screen Support for the Macintosh browser to work
Due to the pending offical release of 2.8 I've pulled the source. If you read the Squeak List you will have noticed that I've been make part of the team that does the "official VM" releases for the macintosh, so for now you will need to wait a few days for us to roll this all out as part of the official 2.8 VM
-----------------
But in doing this I also had to fix some problems with the Socket code, did some carbonization, and at the last minute decided to make Squeak a more macintosh like application. Thus Squeak now has an icon, etc.
You can get a new VM to test here {Pulled waiting the offical release} You should of course test things out before committing to use it as a production version. Some changes due to further Carbonization will follow shortly.
The change set for all these macintosh related changes is {Pulled awaiting the offical release} You should be able to build your VM if you wish, this patch set contains:
1) A fix for the macintosh Socket plugin to quickly abort a connect if the port is invalid
2) A fix to abort a connection if a disconnect flows at the same time
3) Dropped the OT libraries from the 68K version.
4) The SqueakTermination routine will run on a force quit, or when the code gets unloaded to cleanup any plugin issues (aka Socket code failing to close OT after VM failure)
5) I've added Finder Icons for Squeak and fixed up a number of issues with Squeak on the Macintosh. No close box, balloon help in finder, version string, etc.
6) A step towards Carbonization was done (not yet complete). Accessors are now used, p2cstr/c2pstr usage was reviewed, scrap manger rewritten, menu logic examined.
7) Full screen support for macintosh browsers was added
8) Fixed issue with wrong path to plugins directory
9) Fixed issue with switching applications using cmd-tab under full screen
10) Cleaned up some stuff in the readme
11) Rebuilt the PPC Squeak App Project was corrupt
7) Lots of time in June of 2000 spent porting Craig Latta's Correspondents/Flow work
Now supports the Disney Socket Primitives and the current exception handlers. This brings a marvelous streaming package to Squeak that allows you to create streams on Sockets, MIDI(*), and serial devices. If you don't care for the existing Socket support in Squeak, then check this out! Being able to stream over a socket is MUCH nicer!
First if you are using 2.7 you need the JMMFlowWorkbackTo27.1.cs patch. If you are using 2.8 or 2.9 then you do NOT need this change set. This adds some changes made to the system from the 2.8 patch set which we are relying upon.
Next you need the JMMExternalTableByIndex.1.cs patch, which adds functionality to a 2.8 kernel to allow you to access the externalSemaphore Table by number, versus value.
Next you need the JMMChgFlowPreSetup.1.cs patch. This adds enhancements to the existing base classes, I've broken it out from the Correspondents/Flow/ work so you know what's happening to the rest of Squeak. {Actually streaming does stuff too, but I didn't break it out :-{}
Next you need the streaming1g1JMM.1.cs patch. This patch provides streaming over external resources, like the midi, serial ports, and of course Sockets.
Next you need a version of the Correspondents/Flow work which provides the actual code for the serial, midi and socket support. This rather large filein is at correspondents1b4JMM.1.cs.
Finally a test SUnit (JMMSUnitsForFlow.1.cs). Were would you be without one?
Up the creek without a paddle comes to mind.
This software has been tested on a macintosh at the current 2.8 level. The test suite runs fine. It also has been tested on a macintosh with a 2.7 image/VM and runs fine, excluding the UDP support and issues with attempting to get a TCP/IP Server model to work with the somewhat broken listen to logic in the Mac 2.7 VM. If you want to host a server with a macintosh 2.7 VM/image, one word DON'T.
Things left to do...
Testing on windows and Linux.
*MIDI isn't tested yet, need someone with actual mac+serial ports+MIDI device to test.
6) An example TCP/IP server to test Squeak performance
See my notes on this Open Transport based server.
5) A test suite to test Socket plugin code for compliance
See my notes on the Socket Test Suite.
4) Squeak deferred screen updates. (a change set)
(some thoughts on MinCycleLapse first)
To implement this change you must file in this change set, then create a new interp.c, then build a new VM.
When Squeak alters its screen image it is writing to an internal bitmap. From time to time the VM asks the platform specific code to copy those bits to the actual BitMap that is the window. I have an example where 100 screen restores causes 41,168 copies to occur, well over 1000 updates per second on my Mac. Cool but a problem occurs when using Squeak as a X-Client were the X-Server is remotely located. Then those thousands of updates take a long time to do since network latency plays a big part in the equation. In fact my friends tell me they just watch the screen paint, slowly...
My solution is to change the VM, by changing the Squeak Interpreter of course. My change focuses around alter the original calls to ioShowScreen to call deferShowDisplayBits. My modified routine is responsible for remembering the largest enclosing rectangle, and tracking how long a screen update has been deferred for. If it called and the time limit has been exceeded then the original ioShowScreen is invoked using the rectangle that should encompass all required drawing.
To ensure pending screen updates occur in a timely manner, I altered checkForInterrupts to ensure if an update is pending then an update is forced once the timer expires.
For my previous example we can reduce the actual number of bitmap copies to 1,885 if you set the update frequency to 16 milliseconds, or 60 times a second.
Note in order to tell the VM about the update frequency I created a method SystemDictionary>>delayScreenUpdatesBy: Use this method to set the defer delay to zero to get original behavior, otherwise use a number that gives good performance, but doesn't impact animation. You must set this value each time you restart your VM since the VM does not remember it from execution to execution.
3) Squeak 68K, 68881 (floating point enabled)
(a 2.6 VM) (a 2.6 VM with deferred updates)
The generic Disney VM uses emulated floating point for the Macintosh. If you've a floating point equipped Mac, say 3with a 68040, but not an 68040LC, or have a 68881 or 68882 FP chip installed, then this VM will improve performance of floating point calculations by a good 12%.
If you choose to use the 2.6VM with deferred updates you need this piece of code to set the defer time.
For SystemDictionary add this method.
delayScreenUpdatesBy: timeDelayInMilliseconds
"Request that the VM delay screen updates for X milliseconds, a 0 value means no delay.
Use this to improve X-windows performance, 16 is 1/60 or so of second, use 100 for remote screens?"
^ Smalltalk vmParameterAt: 12 put: timeDelayInMilliseconds
2) rgbMap:from:to: speedup (a change set) (THIS IS 2.6 ONLY, a 2.7 is pending)
Late last month before I got caught up in deferring updates I was looking at BitBit>>rgbMap:from:to: It seems this method is called a lot. For my 100 screen restores test case it is used well over 37 million times. But most of the time the incoming parms and outgoing result is the same (usually adjacent pixels are the same color). So I decided to cache the value.
For my 100 screen restore example, 35,239,118 calls are now cached, and only 1,827,024 calls are execute as uncached. This results in about a 5% speed up. I've not yet done performance profiling on 68K or intel yet, perhaps the speedup will be greater?
You need to file in the attached change set in and build a new VM.
PS I noticed the inlining didn't work as I expected it too, I guess I'm not sure of the rules. For example:
^x := self foo: y
Didn't inline
But
x := self foo: y
^x
Does inline.
1) CCodeGenerator isForcedInline (a change set)
I really really wanted to force the inlining of success: in the VM. But the logic prevents that for some cases. This change allows it, we force inlining, but only for allowable methods that we know are safe.