When I try to update I get the message that there are 0 new updates. 
I'm currently at change 2299 and holding. Is there something special 
to do to get changes 2300 and on???

Mark


>Folks -
>
>I have just issued 11 new updates.  Beyond sundry fixes, this 
>includes John McIntosh's rewrite of Mac Sockets to support Open 
>Transport.  It should run compatibly with earlier VMs, but if you 
>fetch or build a new VM, you will be able to take advantage of the 
>new Socket implementation and support for Open Transport.  The new 
>(backward-compatible) VM can be found in the 2.8 folder on the UIUC 
>server, called
>	SqueakVM2.8beta3.sea
>
>John will probably post further information about the new Sockets. 
>It would be great to get some early testing, both so we can fix any 
>bugs and so we can find out whether the substantially better 
>benchmarks make a real difference "out in the field".
>
>Enjoy
>	- Dan
>-------------------------------------
>2300AsyncFile-failComment
>
>2301TurtleTrailMods-di -- Dan Ingalls -- 23 May 2000
>Makes batched pen trails work depending on the setting of a preference.
>Also pen trails work in the world as well as in any other PasteUp.
>Most important, pen trails now work for embedded objects with 
>arbitrary flexing.
>
>2302BigTextFixes-di -- Dan Ingalls -- 7 June 2000
>Changes NewParagraph>>selectionRectsFrom:to: to return a single 
>rectangle for all lines between the first and last when the 
>container is a simple rectangle.  This changes the time to display a 
>full selection in a megabyte file from over 10 seconds to about 1/4 
>second.
>Changes CharacterBlock copy to do a simple shallowCopy.  It had been 
>inheriting deepCopy from Rectangle, thus making an unneeded copy of 
>the entire text as well.  Greatly improves typing into a megabyte 
>file.
>
>2303resetExtent-raa -- Bob Arning -- 8 June 2000
>Recent changes to #showScrollBar and #hideScrollBar in 
>2282HiddenScrollBar-dew have unfortunate side-effects for users of 
>retractable scrollbars - they send #extent: whenever the scrollbar 
>is hidden or shown. This leads to:
>- long pauses when leaving a text pane with lots of text in which 
>there is a selection
>- shifting the contents so that the selection is visible.
>I think both (certainly the first) are undesirable. This change set 
>sends #extent: only when the scrollbars are inboard."
>
>2304FXColorFixes -- Andreas Raab -- 8 June 2000
>A bunch of fixes for external forms with non-squeak RGBA formats. 
>Found and fixed on the new demo laptop which uses a neat 5x6x5 RGB 
>format in 16 bit depth. Very good for testing.
>
>2305sketchThumbnail-sw -- Scott Wallace -- 9 June 2000
>Further chasings of ones own tail regarding the pursuit of 
>consistent dockup of morph and player in the presence of 
>TransformationMorphs...  When a new Sketch was drawn in a quite 
>large painting area, the painting system was often returning a 
>spurious,  nonzero but vanishingly small (order of 1E-14) 
>forward-direction, resulting in the premature launching of an 
>unwanted TransformationMorph for the newborn -- the result of 
>round-off error when computing forward-direction.  This workaround 
>simply maps such spurious tiny offsets returned from the painting 
>system back to zero, which appears to avoid the problem of plain 
>gray thumbnails, which can be traced to this situation."
>
>2306HQTextures -- Andreas Raab -- 9 June 2000
>The change set allows the definition of explicit high quality 
>textures when using Morphs as a texture in 3D. The need for such 
>high quality textures comes from the (unfortunate) requirement of 
>all current 3D hardware to deal with textures that are powers of two 
>only. Although that's kinda stupid we gotta play by their rules here.
>The dilemma occurs when considering a morph which is, say, 384 at 384 
>wide. Downsampling to 256 at 256 does require less space (good for 
>limited VRAM/AGP resources on the card) but can lead to bad, bad 
>distortions. Upscaling to 512 at 512 on the other hand requires four 
>times as much space. But it looks just beautiful then. So with this 
>change set we have a choice of what to use and the tradeoffs are 
>made explicit with a new menu entry in the Wonderland wrapper morphs.
>As a side effect, the change set introduces a method for scaling 
>arbitrary forms through the best available method (which is using 
>bilinear interpolation if possible, and if not, to use WarpBlt 
>instead).
>"
>
>2307JMM-SemaTableAndLessInt -- johnmci at smalltalkconsulting.com -- 7 June 2000
>When I was building a high performance tcp/ip test server I found a 
>number of problems with the external interrupt interface. The first 
>problem is the table at 25 elements is too small, I had test cases 
>that triggered upto 216 interrupts. The second issue was the 
>signalSemaphoreWithIndex: method consolidated semaphores, so two 
>calls on the same semaphore might become one call. This isn't how 
>the Semaphore logic work in the Squeak Class. The third and more 
>difficult problem to solve is that the code used to populate the 
>table and reading from the table is not thread safe. As Squeak is 
>reading from the table then setting the counter to zero you can be 
>busy placing elements in the table via interrupt driven routines. 
>The more complicated fix is to use a OS thread safe queue. The less 
>complicated solution is to use a dual buffered array. This fix uses 
>the dual buffered array. Two arrays of 500 are created and alternate 
>usage based on who is read and who is writting. This should limit 
>problems with interrupt driven code attempting to place items in a 
>array that is being itterated over. In this solution 
>signalExternalSemaphores iternates over the array that isn't active, 
>the signalSemaphoreWithIndex: routine places items in the active 
>array without fear of stomping on the signalExternalSemaphores logic.
>Note of course you can still exceed the 500 element fixed limit and 
>loose interrupts, but of course you could compile a new VM with a 
>larger limit.
>I also discovered various race conditions on the access to the 
>externalSemaphore table. This new class uses class side methods to 
>restrict access using a mutex semaphore. It seemed cleaner to 
>deligate the reponsibility here versus adding more code and another 
>class variable to SystemDictionary
>Note that in Smalltalk recreateSpecialObjectsArray we still directly 
>play with the table.
>Lastly on the faster machines of today I found that 
>checkForInterrupts was being called well over a thousand times per 
>second. If there is no interrupt activity or other extraordinary 
>events then a simple counter is used to dicate how often the call 
>should be made. Problem is machines are so fast now that the 
>original 1000 counter start value is too small. This change attempts 
>to use feedback to dictate the number of calls to about 200 per 
>second (perhaps too high?) As time progresses it attempts to make 
>the counter start number float to a optimistic value. Clock 
>overFlows, long delays etc should not drastically affect the 
>algoritmn, we still limit the lower end to 1000. On a PowerBook 
>500Mhz the value floated between 5200 and 10500, and gave me a 2% 
>improvement in bytescodes per second.
>Note that interruptChecksEveryNms is the target delay between calls, 
>this value is in milliseconds, to use a different value you must 
>then build a new VM.
>Beware if your implementation's millisecond clock doesn't record in 
>resolutions of at least 5 milliseond increments. If for example your 
>clock will only give you 1/60 of a second accuracy this change set 
>will cause problems. in this case change interruptChecksEveryNms to 
>0 to keep the historical behavior when you are building your VM"
>
>2308JMM-Socket-Changes -- John M McIntosh -- 5 June 2000
>A number of changes were made to NetNameResolver and Socket when I 
>was creating the Macintosh Open Transport plugin. These changes 
>range from adding some accessors to get at instance variables to a 
>fundamental change in semaphore signalling logic.
>We now have three semaphores: one for open/close/listen, one for 
>reading, one for writing. Existing applications and existing C code 
>are unaffected by this change since I attempted to make this change 
>backwards compatible. However this change makes mult-threaded 
>applications safer to write since you now can have seperate 
>processes in a application that have the responsiblity for 
>listening, reading, and writing to a socket. Implementation of this 
>feature depends on the underlying VM implementation. As of June 5th 
>2000 it is fully supported on the Macintosh. Beware you can of 
>course write a Squeak application that will not behave correctly on 
>an older VM. Use the accessor primitiveOnlySupportsOneSemaphore to 
>find out if the C code supports one or three semaphores and make a 
>decision about continuing.
>Additional support for UDP was added, now you can set the host for 
>an outgoing UDP datagrams, and on reading a UDP datagram get 
>information about who it came from, this support of course relies on 
>the underlying VM implementation. Although this feature was support 
>somewhat in the in the previous implementation we now tie host 
>information to the datagram which ensures race conditions or high 
>volume UDP traffic from multiple locations does not affect who we 
>think we are talking to.
>Support for setting and getting Socket, TCP/IP, and UDP options was 
>added.  You should be able to set or get information about socket 
>options for all of the common options and most of the uncommon ones. 
>Again support relies on the underlying VM implementation.
>Lastly some cleanup of the test examples and new examples were 
>added, but for testing purposes you should use the SUnit test suite 
>that I created to run tests when making socket C code changes or 
>changes to the Classes"
>
>2309JMM-PLG-New-Mac-Socket
>
>2310JMM-MacCcodeChangesForOT