Squeak-dev Digest, Vol 7, Issue 49Robert Bourgeois robert-philippe.bourgeois at wanadoo.frSun Jul 20 07:01:04 UTC 2003
Bonjour At 08:01 20/07/2003 +0200, you wrote: >Send Squeak-dev mailing list submissions to > squeak-dev at lists.squeakfoundation.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.squeakfoundation.org/listinfo/squeak-dev >or, via email, send a message with subject or body 'help' to > squeak-dev-request at lists.squeakfoundation.org > >You can reach the person managing the list at > squeak-dev-owner at lists.squeakfoundation.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Squeak-dev digest..." > > >Today's Topics: > > 1. [BUG][FIX] Wrong stepping time in JoystickMorph with real Joystick > ( [update - 5337] ) > 2. [FIX][3.6a] MoreKCPFixes-nk ( [update - 5338] ) > 3. [FIX][ENH] DoOneCycleNowFixAndComment-nk-ls ( [update - 5339] ) > 4. [FIX] ImageReaderDepFix-nk ( [update - 5340] ) > 5. [FIX] removeChessConstants-asm ( [update - 5341] ) > 6. [ENH] InheritanceDecoratedButton-nk ( [update - 5343] ) > 7. [FIX][3.6b] WindowPositioningFix-nk ( [update - 5342] ) > 8. [FIX] Lexicon>>initialLimitClass fix ( [update - 5344] ) > 9. [FIX][3.6b] ProcessBrowserDeadProcessFix-nk ( [update - 5345] ) > 10. [FIX][3.6b] DebuggerDeadProcessFix-nk [approved] ( [update - > 5346] ) > 11. [FIX] newMethodNoCatSel-asm ( [update - 5347] ) > 12. [BUG][FIX][TEST] ClassBuilder does not move iVars correctly ( > [update - 5348] ) > 13. [FIX] ObsoleteNetClassesFix-nk ( [update - 5349] ) > 14. [FIX] TTCFontPixelSizeFix-nk ( [update - 5350] ) > 15. [FIX] FITBFocusFix-nk ( [update - 5351] ) > 16. [FIX] CPUWatcherShutDown-nk ( [update - 5352] ) > 17. non-inlined VM. (John M McIntosh) > 18. Re: squeak linux woes (Ted Wright) > 19. Re: [Q][VM] mulithreaded ? (Martin Drautzburg) > 20. > [FIX] ContextCleanupDebugFix (useful enough to incorporate latest > changes?) (Doug Way) > 21. re: mulithreaded? (Craig Latta) > 22. [ENH] Remove the old outer window for "The Worlds of Squeak" > (can't > enter project by clicking) (Doug Way) > 23. Re: [Q][VM] mulithreaded ? (John M McIntosh) > 24. Re: squeak linux woes (Bert Freudenberg) > 25. re: mulithreaded? (Tim Rowledge) > 26. Conflict checking, 3.6gamma (was Re: [FIX][3.6b] > FileListCleanup-nk > ( [cd][er][et] )) (Doug Way) > 27. Re: [FIX] ContextCleanupDebugFix (useful enough to incorporate > latest changes?) (Ned Konz) > 28. RE: [VM] HashBits, a lazy way (Andreas Raab) > 29. RE: [Q][VM] mulithreaded ? (Andreas Raab) > 30. [FIX] NoDoitInPackageInfo-nk > 31. Re: [FIX] NoDoitInPackageInfo-nk ([er][et][sm]) (Avi Bryant) > 32. RE: [VM] HashBits, a lazy way (Andreas Raab) > 33. Nebraska removal (Adam Spitz) > 34. [FIX][ENH] BoundsInHaloFix-nk ( [et][er][approved] ) > 35. [FIX] EventRecorderPosFix-nk ( a couple of questions ) (Doug Way) > 36. Re: Wanted - dynamic keybindings for Squeak (was: be a web url > -textMorph menus) (Chris Reuter) > 37. [BUG][FIX] SocketStream|next: (Luciano Notarfrancesco) > 38. RE: [VM] HashBits, a lazy way (John M McIntosh) > > >---------------------------------------------------------------------- > >Date: Sat, 19 Jul 2003 16:57:49 -0400 >From: dway at riskmetrics.com >To: squeak-dev at lists.squeakfoundation.org >Subject: [BUG][FIX] Wrong stepping time in JoystickMorph with real Joystick > ( [update - 5337] ) >Message-ID: <200307192057.h6JKvnxT129110 at pimout5-ext.prodigy.net> >In-Reply-To: <E19Zxc4-0000GO-00 at i09nbmarcus.ira.uka.de> >References: <0HGL0085P9ENY9 at mxout1.netvision.net.il> > <E19Zxc4-0000GO-00 at i09nbmarcus.ira.uka.de> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 1 > > > > > > > > > > > > > > > > >< I'm a bug-fixing machine! > > >This post brought to you by the BugFixArchiveViewer, a handy tool that >makes it easy to comment on proposed fixes and enhancements for Squeak. >For more information, check out the Web page for the BugFixArchiveViewer >project: http://minnow.cc.gatech.edu/squeak/3214 > >< I'm a bug-fixing machine! > >------------------------------ > >Date: Sat, 19 Jul 2003 16:58:13 -0400 >From: dway at riskmetrics.com >To: squeak-dev at lists.squeakfoundation.org >Subject: [FIX][3.6a] MoreKCPFixes-nk ( [update - 5338] ) >Message-ID: <200307192058.h6JKwD3S187620 at pimout6-ext.prodigy.net> >In-Reply-To: <E19Zxr2-0000HA-00 at i09nbmarcus.ira.uka.de> >References: <E19YGgJ-0000bu-KV at mail5.whidbey.net> > <E19Zxr2-0000HA-00 at i09nbmarcus.ira.uka.de> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 2 > > > > > > > > > > > > > > > > >< I'm a bug-fixing machine! > > >This post brought to you by the BugFixArchiveViewer, a handy tool that >makes it easy to comment on proposed fixes and enhancements for Squeak. >For more information, check out the Web page for the BugFixArchiveViewer >project: http://minnow.cc.gatech.edu/squeak/3214 > >< I'm a bug-fixing machine! > >------------------------------ > >Date: Sat, 19 Jul 2003 16:59:23 -0400 >From: dway at riskmetrics.com >To: squeak-dev at lists.squeakfoundation.org >Subject: [FIX][ENH] DoOneCycleNowFixAndComment-nk-ls ( [update - 5339] ) >Message-ID: <200307192059.h6JKxN3S233702 at pimout6-ext.prodigy.net> >In-Reply-To: <E19ZyXD-0000Ii-00 at i09nbmarcus.ira.uka.de> >References: <E19YaOZ-0003At-SE at mail5.whidbey.net> > <E19ZyXD-0000Ii-00 at i09nbmarcus.ira.uka.de> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 3 > > > > > > > > > > > > > > > > >< I'm a bug-fixing machine! > > >This post brought to you by the BugFixArchiveViewer, a handy tool that >makes it easy to comment on proposed fixes and enhancements for Squeak. >For more information, check out the Web page for the BugFixArchiveViewer >project: http://minnow.cc.gatech.edu/squeak/3214 > >< I'm a bug-fixing machine! > >------------------------------ > >Date: Sat, 19 Jul 2003 17:00:37 -0400 >From: dway at riskmetrics.com >To: squeak-dev at lists.squeakfoundation.org >Subject: [FIX] ImageReaderDepFix-nk ( [update - 5340] ) >Message-ID: <200307192100.h6JL0b3S187440 at pimout6-ext.prodigy.net> >In-Reply-To: <E19aCoM-0000XH-00 at i09nbmarcus.ira.uka.de> >References: > ><7C13C222DC9ED711A9F90008C7917368E0C56E at mstelefonica3.telefonica.com.ar> > <E19aCoM-0000XH-00 at i09nbmarcus.ira.uka.de> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 4 > > > > > > > > > > > > > > > > >< I'm a bug-fixing machine! > > >This post brought to you by the BugFixArchiveViewer, a handy tool that >makes it easy to comment on proposed fixes and enhancements for Squeak. >For more information, check out the Web page for the BugFixArchiveViewer >project: http://minnow.cc.gatech.edu/squeak/3214 > >< I'm a bug-fixing machine! > >------------------------------ > >Date: Sat, 19 Jul 2003 17:00:55 -0400 >From: dway at riskmetrics.com >To: squeak-dev at lists.squeakfoundation.org >Subject: [FIX] removeChessConstants-asm ( [update - 5341] ) >Message-ID: <200307192100.h6JL0t3S050128 at pimout6-ext.prodigy.net> >In-Reply-To: <E19aDWD-0000YY-00 at i09nbmarcus.ira.uka.de> >References: <20030219174758.A5578 at conch.msen.com> > <E19aDWD-0000YY-00 at i09nbmarcus.ira.uka.de> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 5 > > > > > > > > > > > > > > > > >< I'm a bug-fixing machine! > > >This post brought to you by the BugFixArchiveViewer, a handy tool that >makes it easy to comment on proposed fixes and enhancements for Squeak. >For more information, check out the Web page for the BugFixArchiveViewer >project: http://minnow.cc.gatech.edu/squeak/3214 > >< I'm a bug-fixing machine! > >------------------------------ > >Date: Sat, 19 Jul 2003 17:01:33 -0400 >From: dway at riskmetrics.com >To: squeak-dev at lists.squeakfoundation.org >Subject: [ENH] InheritanceDecoratedButton-nk ( [update - 5343] ) >Message-ID: <200307192101.h6JL1XxT028698 at pimout5-ext.prodigy.net> >In-Reply-To: <E19aE9O-0000Zj-00 at i09nbmarcus.ira.uka.de> >References: > ><7C13C222DC9ED711A9F90008C7917368E0C538 at mstelefonica3.telefonica.com.ar> > <E19aE9O-0000Zj-00 at i09nbmarcus.ira.uka.de> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 6 > > > > > > > > > > > > > > > > >< I'm a bug-fixing machine! > > >This post brought to you by the BugFixArchiveViewer, a handy tool that >makes it easy to comment on proposed fixes and enhancements for Squeak. >For more information, check out the Web page for the BugFixArchiveViewer >project: http://minnow.cc.gatech.edu/squeak/3214 > >< I'm a bug-fixing machine! > >------------------------------ > >Date: Sat, 19 Jul 2003 17:01:12 -0400 >From: dway at riskmetrics.com >To: squeak-dev at lists.squeakfoundation.org >Subject: [FIX][3.6b] WindowPositioningFix-nk ( [update - 5342] ) >Message-ID: <200307192101.h6JL1C3S111080 at pimout6-ext.prodigy.net> >In-Reply-To: <E19aE1e-0000ZT-00 at i09nbmarcus.ira.uka.de> >References: <E19Zatp-0001iv-1N at mail5.whidbey.net> > <E19aE1e-0000ZT-00 at i09nbmarcus.ira.uka.de> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 7 > > > > > > > > > > > > > > > > >< I'm a bug-fixing machine! > > >This post brought to you by the BugFixArchiveViewer, a handy tool that >makes it easy to comment on proposed fixes and enhancements for Squeak. >For more information, check out the Web page for the BugFixArchiveViewer >project: http://minnow.cc.gatech.edu/squeak/3214 > >< I'm a bug-fixing machine! > >------------------------------ > >Date: Sat, 19 Jul 2003 17:01:55 -0400 >From: dway at riskmetrics.com >To: squeak-dev at lists.squeakfoundation.org >Subject: [FIX] Lexicon>>initialLimitClass fix ( [update - 5344] ) >Message-ID: <200307192101.h6JL1txT093888 at pimout5-ext.prodigy.net> >In-Reply-To: <E19aFji-0000dD-00 at i09nbmarcus.ira.uka.de> >References: <E19ZbWQ-0002Lc-Jr at mail5.whidbey.net> > <E19aFji-0000dD-00 at i09nbmarcus.ira.uka.de> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 8 > > > > > > > > > > > > > > > > >< I'm a bug-fixing machine! > > >This post brought to you by the BugFixArchiveViewer, a handy tool that >makes it easy to comment on proposed fixes and enhancements for Squeak. >For more information, check out the Web page for the BugFixArchiveViewer >project: http://minnow.cc.gatech.edu/squeak/3214 > >< I'm a bug-fixing machine! > >------------------------------ > >Date: Sat, 19 Jul 2003 17:02:20 -0400 >From: dway at riskmetrics.com >To: squeak-dev at lists.squeakfoundation.org >Subject: [FIX][3.6b] ProcessBrowserDeadProcessFix-nk ( [update - 5345] ) >Message-ID: <200307192102.h6JL2KxT045078 at pimout5-ext.prodigy.net> >In-Reply-To: <E19aFks-0000dF-00 at i09nbmarcus.ira.uka.de> >References: <E19Zb7L-00030g-Ah at mail4.whidbey.net> > <E19aFks-0000dF-00 at i09nbmarcus.ira.uka.de> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 9 > > > > > > > > > > > > > > > > >< I'm a bug-fixing machine! > > >This post brought to you by the BugFixArchiveViewer, a handy tool that >makes it easy to comment on proposed fixes and enhancements for Squeak. >For more information, check out the Web page for the BugFixArchiveViewer >project: http://minnow.cc.gatech.edu/squeak/3214 > >< I'm a bug-fixing machine! > >------------------------------ > >Date: Sat, 19 Jul 2003 17:02:41 -0400 >From: dway at riskmetrics.com >To: squeak-dev at lists.squeakfoundation.org >Subject: [FIX][3.6b] DebuggerDeadProcessFix-nk [approved] ( [update - 5346] ) >Message-ID: <200307192102.h6JL2f3S032362 at pimout6-ext.prodigy.net> >In-Reply-To: <E19aHeJ-0003iC-V4 at mail5.whidbey.net> >References: <E19aHeJ-0003iC-V4 at mail5.whidbey.net> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 10 > > > > > > > > > > > > > > > > >< I'm a bug-fixing machine! > > >This post brought to you by the BugFixArchiveViewer, a handy tool that >makes it easy to comment on proposed fixes and enhancements for Squeak. >For more information, check out the Web page for the BugFixArchiveViewer >project: http://minnow.cc.gatech.edu/squeak/3214 > >< I'm a bug-fixing machine! > >------------------------------ > >Date: Sat, 19 Jul 2003 17:04:00 -0400 >From: dway at riskmetrics.com >To: squeak-dev at lists.squeakfoundation.org >Subject: [FIX] newMethodNoCatSel-asm ( [update - 5347] ) >Message-ID: <200307192104.h6JL40xT044470 at pimout5-ext.prodigy.net> >In-Reply-To: <200307130534.h6D5YiW9082266 at pimout5-ext.prodigy.net> >References: > ><7C13C222DC9ED711A9F90008C7917368E0C578 at mstelefonica3.telefonica.com.ar> > <200307130534.h6D5YiW9082266 at pimout5-ext.prodigy.net> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 11 > > > > > > > > > > > > > > > > >< I'm a bug-fixing machine! > > >This post brought to you by the BugFixArchiveViewer, a handy tool that >makes it easy to comment on proposed fixes and enhancements for Squeak. >For more information, check out the Web page for the BugFixArchiveViewer >project: http://minnow.cc.gatech.edu/squeak/3214 > >< I'm a bug-fixing machine! > >------------------------------ > >Date: Sat, 19 Jul 2003 17:04:55 -0400 >From: dway at riskmetrics.com >To: squeak-dev at lists.squeakfoundation.org >Subject: [BUG][FIX][TEST] ClassBuilder does not move iVars correctly ( > [update - 5348] ) >Message-ID: <200307192104.h6JL4txT034854 at pimout5-ext.prodigy.net> >In-Reply-To: <E19aeu6-0001Kx-00 at i09nbmarcus.ira.uka.de> >References: <000201c31b35$297c1440$8ef7fea9 at atlantis> > <E19aeu6-0001Kx-00 at i09nbmarcus.ira.uka.de> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 12 > > > > > > > > > > > > > > > > >< I'm a bug-fixing machine! > > >This post brought to you by the BugFixArchiveViewer, a handy tool that >makes it easy to comment on proposed fixes and enhancements for Squeak. >For more information, check out the Web page for the BugFixArchiveViewer >project: http://minnow.cc.gatech.edu/squeak/3214 > >< I'm a bug-fixing machine! > >------------------------------ > >Date: Sat, 19 Jul 2003 17:05:59 -0400 >From: dway at riskmetrics.com >To: squeak-dev at lists.squeakfoundation.org >Subject: [FIX] ObsoleteNetClassesFix-nk ( [update - 5349] ) >Message-ID: <200307192106.h6JL5xxT017124 at pimout5-ext.prodigy.net> >In-Reply-To: <E19agqX-0001N4-00 at i09nbmarcus.ira.uka.de> >References: <E19ZAYH-0001sa-Mf at mail5.whidbey.net> > <E19agqX-0001N4-00 at i09nbmarcus.ira.uka.de> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 13 > > > > > > > > > > > > > > > > >< I'm a bug-fixing machine! > > >This post brought to you by the BugFixArchiveViewer, a handy tool that >makes it easy to comment on proposed fixes and enhancements for Squeak. >For more information, check out the Web page for the BugFixArchiveViewer >project: http://minnow.cc.gatech.edu/squeak/3214 > >< I'm a bug-fixing machine! > >------------------------------ > >Date: Sat, 19 Jul 2003 17:06:32 -0400 >From: dway at riskmetrics.com >To: squeak-dev at lists.squeakfoundation.org >Subject: [FIX] TTCFontPixelSizeFix-nk ( [update - 5350] ) >Message-ID: <200307192106.h6JL6W3S185318 at pimout6-ext.prodigy.net> >In-Reply-To: <E19autU-0001dA-00 at i09nbmarcus.ira.uka.de> >References: <E19alkR-0007CG-0r at mail5.whidbey.net> > <E19autU-0001dA-00 at i09nbmarcus.ira.uka.de> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 14 > > > > > > > > > > > > > > > > >< I'm a bug-fixing machine! > > >This post brought to you by the BugFixArchiveViewer, a handy tool that >makes it easy to comment on proposed fixes and enhancements for Squeak. >For more information, check out the Web page for the BugFixArchiveViewer >project: http://minnow.cc.gatech.edu/squeak/3214 > >< I'm a bug-fixing machine! > >------------------------------ > >Date: Sat, 19 Jul 2003 17:09:55 -0400 >From: dway at riskmetrics.com >To: squeak-dev at lists.squeakfoundation.org >Subject: [FIX] FITBFocusFix-nk ( [update - 5351] ) >Message-ID: <200307192109.h6JL9txT243160 at pimout5-ext.prodigy.net> >In-Reply-To: <E19bOL6-0000ge-Tg at mail5.whidbey.net> >References: <E19bOL6-0000ge-Tg at mail5.whidbey.net> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 15 > > > > > > > > > > > > > > > > >< I'm a bug-fixing machine! > > >This post brought to you by the BugFixArchiveViewer, a handy tool that >makes it easy to comment on proposed fixes and enhancements for Squeak. >For more information, check out the Web page for the BugFixArchiveViewer >project: http://minnow.cc.gatech.edu/squeak/3214 > >< I'm a bug-fixing machine! > >------------------------------ > >Date: Sat, 19 Jul 2003 17:10:25 -0400 >From: dway at riskmetrics.com >To: squeak-dev at lists.squeakfoundation.org >Subject: [FIX] CPUWatcherShutDown-nk ( [update - 5352] ) >Message-ID: <200307192110.h6JLAP3S032246 at pimout6-ext.prodigy.net> >In-Reply-To: <E19af3u-0001L4-00 at i09nbmarcus.ira.uka.de> >References: <E19Se2Z-0006hI-Jg at mail5.whidbey.net> > <E19af3u-0001L4-00 at i09nbmarcus.ira.uka.de> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 16 > > > > > > > > > > > > > > > > >< I'm a bug-fixing machine! > > >This post brought to you by the BugFixArchiveViewer, a handy tool that >makes it easy to comment on proposed fixes and enhancements for Squeak. >For more information, check out the Web page for the BugFixArchiveViewer >project: http://minnow.cc.gatech.edu/squeak/3214 > >< I'm a bug-fixing machine! > >------------------------------ > >Date: Sat, 19 Jul 2003 14:17:52 -0700 >From: John M McIntosh <johnmci at mac.com> >To: squeak-dev at lists.squeakfoundation.org >Subject: non-inlined VM. >Message-ID: <74E9182A-BA2E-11D7-8A45-00306540A296 at mac.com> >Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed >MIME-Version: 1.0 (Apple Message framework v552) >Content-Transfer-Encoding: 7bit >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 17 > >For the curious, where the time goes running the macrobenchmarks with a >VM built without inlining. >This breaks out better the 40% or so numbers we see in interpret() in >the inlined version. > > 14.2% fetchNextBytecode > 11.9% interpret (40% of that 11.9% is taken resolving the > case >statement) > 4.4% fetchByte (3.6% of this is via fetchNextByteCode) > 3.9% internalActivateNewMethod > 3.4% internalFetchContextRegisters > 3.4% fetchPointerofObject > 2.5% internalStackValue > 2.4% internalPush > 2.2% startField > 1.9% internalExecuteNewMethod > 1.8% booleanCheat > 1.7% fetchClassOf > 1.6% lookupInMethodCacheSelclass > 1.5% pushTemporaryVariable > 1.3% upward > 1.3% headerType > 1.3% startObj > 1.2% instantiateSmallClasssizeInBytes > 1.1% internalStoreContextRegisters > 1.1% oopFromChunk > 1.1% quickFetchIntegerofObject > 1.1% storePointerUncheckedofObjectwithValue > 1.1% remapFieldsAndClassOf > 1.0% internalPop > 1.0% markAndTrace > 1.0% internalStackTop > > >-- >======================================================================== >=== >John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659 >Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >======================================================================== >=== > >------------------------------ > >Date: Sat, 19 Jul 2003 17:42:21 -0400 >From: Ted Wright <batlist at adelphia.net> >To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Subject: Re: squeak linux woes >Message-ID: <5.2.0.9.2.20030719174001.023e5638 at cobb.consequential.org> >In-Reply-To: <281D1470-B9E5-11D7-86EB-00039398C242 at isg.cs.uni-magdeburg. > de> >References: <5.2.0.9.2.20030719075346.023b7c00 at cobb.consequential.org> >Content-Type: text/plain; charset="us-ascii" >MIME-Version: 1.0 >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 18 > >Bert Freudenberg <bert at isg.cs.uni-magdeburg.de> wrote: > >Am Samstag, 19.07.03 um 13:55 Uhr schrieb Ted Wright: > >>I have not had much luck making a VM that runs reliably with the version 3 > >>C compiler that is the default on Red Hat 8.0 and 9, which is why I'm using > >>gcc 2.96 (from the compat-gcc package) here. > > > >Could you building from my src rpm, which includes the gcc3 patch? > > > > http://isgwww.cs.uni-magdeburg.de/~bert/squeak/RPMS/ > > > >And could you also check if my binary works, by chance? > >I tried your binary and rebuilt the source RPM on Red Hat 8.0, and both >seemed to work fine. My only suggestion is to include the "Requires" and >"Provides" portions of the .spec file: > > BuildRequires: XFree86-devel compat-gcc > Requires: XFree86-libs glibc > Provides: %{name} = %{version} > >I use the apt (for RPM) program from http://freshrpms.net to help maintain >my systems, and getting all the dependencies right in .spec files lets apt >resolve dependencies automatically. > >I won't have more than terminal access to a Red Hat 9 computer until Monday, >so I won't be able to check out your binary on RH9 until then. However, I >did try >to rebuild the source RPM on RH9, and it had a problem. Everything looked >like >it was compiling normally until near the end of the build process: > ># rpmbuild --rebuild Squeak-vm-3.4-1bert.src.rpm >... >strip /usr/lib/squeak/3.4-1/npsqueak.so >+ /usr/lib/rpm/redhat/brp-compress >+ /usr/lib/rpm/redhat/brp-strip /usr/bin/strip >+ /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip >+ /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump >Processing files: Squeak-vm-3.4-1bert >Checking for unpackaged file(s): /usr/lib/rpm/check-files %{buildroot} >getOutputFrom(): Broken pipe > >I'm not sure what would cause this or why it would work on Red Hat 8.0 but >not Red Hat 9. > >Ted > >------------------------------ > >Date: 19 Jul 2003 23:10:12 +0200 >From: Martin Drautzburg <martin.drautzburg at web.de> >To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Subject: Re: [Q][VM] mulithreaded ? >Message-ID: <87oezqz0i3.fsf at web.de> >In-Reply-To: <000801c34e26$298cc140$8ef7fea9 at atlantis> >References: <000801c34e26$298cc140$8ef7fea9 at atlantis> >Content-Type: text/plain; charset=us-ascii >MIME-Version: 1.0 >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 19 > >"Andreas Raab" <andreas.raab at gmx.de> writes: > > > > Actually you forgot the most important condition: > > > > e) You do not pass any arguments around which may be relocated due to GC > > activity. In my understanding that's the most important reason why we don't > > use any kind of threaded calls within primitives. > >This concerns only smalltalk objects, right ? Other memory allocated >by my plugin will not be touched by the GC ? > >Still I wonder ... If the system is frozen as long as the plugin >executes the GC has no chance to run. I can see how threads will be a >problem, but don't the same concerns apply to any stateful code ? >------------------------------ > >Date: Sat, 19 Jul 2003 17:43:57 -0400 >From: Doug Way <dway at riskmetrics.com> >To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Cc: ajh18 at cornell.edu >Subject: > [FIX] ContextCleanupDebugFix (useful enough to incorporate latest changes?) >Message-ID: <19E91764-BA32-11D7-A38F-00306558B8E0 at riskmetrics.com> >In-Reply-To: <200307190808.49091 at ned.bike-nomad.com> >Content-Type: text/plain; charset=US-ASCII; format=flowed >MIME-Version: 1.0 (Apple Message framework v551) >Content-Transfer-Encoding: 7bit >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 20 > > >Is this latest (v2) fix from Anthony useful enough to incorporate for >now (for people to use and test), even though there are still a couple >more things which need to be fixed? It does fix some significant >problems, and it doesn't look like it introduces any new problems, at >least. > >These are the problems which still need to be fixed, as far as I know: >- Allow a process to be debugged without having to suspend it >explicitly (as Ned describes below) >- Something I noticed: If you enter some code in a workspace and select >"debug it" (or "do it" with a halt in the code), the debugger loses the >temporary variable names > >- Doug Way > > >On Saturday, July 19, 2003, at 11:08 AM, Ned Konz wrote: > > > On Friday 18 July 2003 08:36 pm, Anthony Hannan wrote: > >> Ned Konz <ned at bike-nomad.com> wrote: > >>> Can we do something about the broken debugger? I also notice that > >>> #popTo: has lost its return value. > >> > >> Attached is a new version of ContextCleanupDebugFix. It includes > >> its previous fixes plus fixes to new bugs found by Ned. I could > >> not reproduce the OSProcess terminate bug. Maybe Ned's > >> DeadProcessFix fixed it or my changes here fix it. Process>>popTo: > >> purposely no longer has a return value to match its previous > >> signature. Decompiler>>popTo: is an entirely different message > >> that is never sent to a Process (it just happens to have the same > >> selector name). > > > > OK, now make it work with the Process Browser :-) > > > > Stepping looks much better; thanks! > > > > However... > > > > You seem to need to suspend a process before debugging it now, for > > some reason (this breaks "debug" from the Process Browser). > > In other words, this no longer works: > > > > [ Project uiProcess debug ] fork > > > > You have to do this instead: > > > > [ Project uiProcess suspend; debug ] fork > > > > Or more accurately, you have to check to see if it's suspended first. > > > > In fact, if you open the debugger on a running process you get the > > interesting effect of having the process running at the same time. > > > > -- > > Ned Konz > > http://bike-nomad.com > > GPG key ID: BEEA7EFE > > > >------------------------------ > >Date: Sat, 19 Jul 2003 14:55:43 -0700 >From: Craig Latta <craig at netjam.org> >To: squeak-dev at lists.squeakfoundation.org >Subject: re: mulithreaded? >Message-ID: <3F19BE5F.3D84469 at netjam.org> >References: <87smp2zdry.fsf at web.de> >Content-Type: text/plain; charset=us-ascii >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 21 > > >Hi Martin-- > > I wrote a plugin that uses POSIX threads. I allocate all the > stuff that >the threads care about on the heap, then store the addresses in >ByteArrays that my Smalltalk objects hold onto. A Smalltalk object can >then invoke primitives which use those addresses to manipulate the >threads. Smalltalk processes are synchronized with host threads via >Smalltalk semaphores, which the interpreter proxy can signal. > > Extending the virtual machine to use multiple host threads is no >problem at all. > > >-C > >p.s. The only platform that can't deal with threads is Risc-OS. I look >forward to the day when we are liberated from it (i.e., when Tim stops >using it :) or when the POSIX project there is done. > >-- >Craig Latta >http://netjam.org/resume >craig at netjam.org >[|] Proceed for Truth! > >------------------------------ > >Date: Sat, 19 Jul 2003 18:12:12 -0400 >From: Doug Way <dway at riskmetrics.com> >To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Subject: [ENH] Remove the old outer window for "The Worlds of Squeak" (can't > enter project by clicking) >Message-ID: <0BED96AA-BA36-11D7-A38F-00306558B8E0 at riskmetrics.com> >In-Reply-To: <5.2.1.1.0.20030714213803.00ae1040 at mail.consultar.com> >Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed >MIME-Version: 1.0 (Apple Message framework v551) >Content-Transfer-Encoding: 7bit >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 22 > > >I think it's a good idea to get rid of the old non-matching window >frame, but it seems that you can no longer enter the resulting project >by clicking on it, and you don't get the frame-highlighting on >mouse-over. Since the point of this project is to be something simple >for newbies to try, we probably want to make sure it's easy to enter >the project. > >(Also might be nice to get rid of the extra black border that remains >around the windowless project. I noticed I can do that by executing >something like "content extent: content extent - (1 at 1)".) > >- Doug Way > > >On Monday, July 14, 2003, at 03:40 PM, Diego Gomez Deck wrote: > > > Hi, > > > > We're dragging the old outer window since, iirc, squeak 3.0. Time to > > remove it! > > > > Enjoy it, > > > > Diego > > > > PS: Nothing happens if the window is not more there. > > > > ----------------------------------------------------------------------- > > --- > > " > > Change Set: RemoveOldWindowForTheWorldsOfSqueak-dgd > > Date: 14 July 2003 > > Author: Diego Gomez Deck > <DiegoGomezDeck at ConsultAr.com> > > > > - remove the old outer window for 'The Worlds of Squeak' Projectview > > > > " > > > > (SystemWindow > > windowsIn: World > > satisfying: [:each | each label = 'The Worlds of Squeak']) > > do:[:each | > > | content | > > content := each paneMorphs first. > > each model: nil. > > World addMorphFront: content. > > each delete. > > ]. > > > > <RemoveOldWindowForTheWorldsOfSqueak-dgd.1.cs.gz> > >------------------------------ > >Date: Sat, 19 Jul 2003 15:14:26 -0700 >From: John M McIntosh <johnmci at mac.com> >To: squeak-dev at lists.squeakfoundation.org >Subject: Re: [Q][VM] mulithreaded ? >Message-ID: <5C2CD290-BA36-11D7-8A45-00306540A296 at mac.com> >Content-Type: text/plain; delsp=yes; charset=ISO-8859-1; format=flowed >MIME-Version: 1.0 (Apple Message framework v552) >Content-Transfer-Encoding: quoted-printable >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 23 > > > From: =A0 Martin Drautzburg < martin.drautzburg at w... > > > Date: =A0 Sat=A0Jul=A019,=A02003=A0 9:10 pm > > Subject: =A0 Re: [Q][VM] mulithreaded ? > > > > > > > > This concerns only smalltalk objects, right ? Other memory allocated > > by my plugin will not be touched by the GC ? > > > > Still I wonder ... If the system is frozen as long as the plugin > > executes the GC has no chance to run. I can see how threads will be a > > problem, but don't the same concerns apply to any stateful code ? > >Technically the VM, allocates/malloc/etc one huge memory segment to =20 >contain the contents >of your.image plus head room for youngspace. > >Most unix vm (linux/bsd/os-x) mmap 1GB (or 512mb (mac)) and write the =20= > >image there, with the >1GB-sizeof(your.image) as youngspace. > >The GC then manages memory within that one huge memory segment. The VM =20= > >then of course can >malloc/allocate/etc memory for other things in what is known as the C =20= > >heap. > >Since the VM is not threaded then within a primitive call, a GC won't =20= > >happen, unless you invoke a VM call that results in allocating =20 >smalltalk objects which could then trigger a IGC or fullGC. There is a =20= > >call, push/popRemappableOops that you can make to record oops address =20= > >that will be remapped on a GC. Usually these are made when the =20 >primitive is allocating a number of objects to contain data coming up =20= > >from a primitive call, look at the plugins for an example. > >Now for example if in your primitive call, you malloc memory, then copy =20= > >the oops data into those storage areas, then place some token/indicator =20= > >on a thread safe queue, which your other pthread process is waiting on, =20= > >or by passing that mallocated memory to a pthread somehow you will be =20= > >fine. > >Getting the data back will require some thought. > >Although signalling a semaphore is kinda thread safe, care was taken by =20= > >me a few years back to make it somewhat thread safe to support Apple's =20= > >open transport tcp/ip callbacks but it's not perfect. > >Please review the code in Interpreter>>signalExternalSemaphores & =20 >Interpreter>>signalSemaphoreWithIndex: and see if it passes your =20 >thread safe thresholds. CPUS are WAY faster today that when it was =20 >written, then also consider the issue if your signalSemaphoreWithIndex =20= > >is ignored/forgotten/missed by the VM, because this code doesn't work =20= > >just right. Nothing of course prevents you from cleaning this code up =20= > >with pthread safe code in your own custom VM. > >Making interpreter callbacks in the pthread is fraught with danger, =20 >certainly none that references Oops can be made, unless of course you =20= > >build a custom VM that allows that, yes one could pthread safe or spin =20= > >lock the allocation routine then allow allow threads to allocate oops =20= > >memory. > >Also note that past experience has shown that pthread creation is =20 >expensive, so having a pool of threads to use, or some sort of queue to =20= > >feed a pthread is more efficient that attempting to create dozens of =20 >pthreads per second. > >-- >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 >=3D=3D=3D >John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659 >Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 >=3D=3D=3D= > >------------------------------ > >Date: Sun, 20 Jul 2003 00:35:35 +0200 >From: Bert Freudenberg <bert at isg.cs.uni-magdeburg.de> >To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Subject: Re: squeak linux woes >Message-ID: <50825C07-BA39-11D7-86EB-00039398C242 at isg.cs.uni-magdeburg.de> >In-Reply-To: <5.2.0.9.2.20030719174001.023e5638 at cobb.consequential.org> >Content-Type: text/plain; charset=US-ASCII; format=flowed >MIME-Version: 1.0 (Apple Message framework v552) >Content-Transfer-Encoding: 7bit >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 24 > > >Am Samstag, 19.07.03 um 23:42 Uhr schrieb Ted Wright: > > > Bert Freudenberg <bert at isg.cs.uni-magdeburg.de> wrote: > >> Am Samstag, 19.07.03 um 13:55 Uhr schrieb Ted Wright: > >>> I have not had much luck making a VM that runs reliably with the > >>> version 3 > >>> C compiler that is the default on Red Hat 8.0 and 9, which is why > >>> I'm using > >>> gcc 2.96 (from the compat-gcc package) here. > >> > >> Could you building from my src rpm, which includes the gcc3 patch? > >> > >> http://isgwww.cs.uni-magdeburg.de/~bert/squeak/RPMS/ > >> > >> And could you also check if my binary works, by chance? > > > > I tried your binary and rebuilt the source RPM on Red Hat 8.0, and both > > seemed to work fine. > >Great! Thanks for trying! > > > My only suggestion is to include the "Requires" and > > "Provides" portions of the .spec file: > > > > BuildRequires: XFree86-devel compat-gcc > > Requires: XFree86-libs glibc > > Provides: %{name} = %{version} > >We wouldn't need compat-gcc with the gcc3 patch, right? > >But some dependencies definetly are in order. Suppose I'd like to build >one src RPM for all distributions. Are you sure the packages are called >like this in every distro? Otherwise we might be better of listing >individual lib files in the Requires section, and headers plus tools >(sh, sed, awk, make) in the BuildRequires section. > > > I use the apt (for RPM) program from http://freshrpms.net to help > > maintain > > my systems, and getting all the dependencies right in .spec files lets > > apt > > resolve dependencies automatically. > >Neat, I didn't know that existed. > > > I won't have more than terminal access to a Red Hat 9 computer until > > Monday, > > so I won't be able to check out your binary on RH9 until then. > > However, I did try > > to rebuild the source RPM on RH9, and it had a problem. Everything > > looked like > > it was compiling normally until near the end of the build process: > > > > # rpmbuild --rebuild Squeak-vm-3.4-1bert.src.rpm > > ... > > strip /usr/lib/squeak/3.4-1/npsqueak.so > > + /usr/lib/rpm/redhat/brp-compress > > + /usr/lib/rpm/redhat/brp-strip /usr/bin/strip > > + /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip > > + /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip > > /usr/bin/objdump > > Processing files: Squeak-vm-3.4-1bert > > Checking for unpackaged file(s): /usr/lib/rpm/check-files %{buildroot} > > getOutputFrom(): Broken pipe > > > > I'm not sure what would cause this or why it would work on Red Hat 8.0 > > but > > not Red Hat 9. > >No idea. Looks like this has nothing to do with the build, but with the >check-files script? I googled for that, some people have reported the >problem, but no solution so far. Maybe it barfs on the directories in >the %files section? Perhaps one should list each file. Would be better >anyway, I was just being lazy. > >-- Bert > >------------------------------ > >Date: Sat, 19 Jul 2003 15:58:07 -0700 >From: Tim Rowledge <tim at sumeru.stanford.edu> >To: squeak-dev at lists.squeakfoundation.org >Subject: re: mulithreaded? >Message-ID: <f77dad144c.rowledge at goldskin.attbi.com> >In-Reply-To: <3F19BE5F.3D84469 at netjam.org> >References: <87smp2zdry.fsf at web.de> <3F19BE5F.3D84469 at netjam.org> >Content-Type: text/plain; charset=us-ascii >MIME-Version: 1.0 >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 25 > >Craig Latta <craig at netjam.org> wrote: > > > p.s. The only platform that can't deal with threads is Risc-OS. I look > > forward to the day when we are liberated from it (i.e., when Tim stops > > using it :) >Never! They'll have to pry my cold dead fingers off the keyboard! > > >tim >-- >Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim >Strange OpCodes: JSP: Jump on Sexy Programmer >------------------------------ > >Date: Sat, 19 Jul 2003 19:07:16 -0400 >From: Doug Way <dway at riskmetrics.com> >To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Subject: Conflict checking, 3.6gamma (was Re: [FIX][3.6b] FileListCleanup-nk > ( [cd][er][et] )) >Message-ID: <BDBA6873-BA3D-11D7-A38F-00306558B8E0 at riskmetrics.com> >In-Reply-To: <E19doxt-0004yR-00 at i09nbmarcus.ira.uka.de> >Content-Type: text/plain; charset=US-ASCII; format=flowed >MIME-Version: 1.0 (Apple Message framework v551) >Content-Transfer-Encoding: 7bit >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 26 > > >On Saturday, July 19, 2003, at 06:29 AM, marcus at ira.uka.de wrote: > > > ... > > Ok, I looked at the code, no problems visible. This touches some more > > classes, but the > > changes are simple and local to the FileList services.... but maybe > > better > > for 3.7alpha (don't know...). (This makes me again feel bad about > > beeing > > beta > > at this point...). Should this be approved for 3.6? Approvals for 3.7 > > do > > not > > make sense IMHO, because it is important that approved stuff gets added > > to the update stream ASAP. If approved stuff rots for 2 months, we need > > to > > look closely again, because chances of conflicts with other stuff is > > high. > >Actually 3.7alpha will be started quite soon, when we move 3.6 to >gamma, which should be in less than a week. So I think it would be >okay to postpone this sort of stuff until 3.7alpha, since it won't >"rot" for very long. :-) We can just incorporate fixes into 3.6beta >right now. > >3.6 was supposed to move to gamma yesterday, I believe, but since we >shrunk the beta cycle a bit, I think we could probably shrink the gamma >cycle an equivalent amount. Say, 2 1/2 weeks for beta, 1 1/2 weeks for >gamma. Which would mean we should to 3.6gamma around next Tuesday. >3.6final is still August 1st. > >By the way, I have been checking all of the approved changesets for >conflicts as I incorporate them, with the ConflictChecker. It makes >sense for me to do it because incorporation-time is the time when we >are sure that conflicts can be resolved... On the other hand, at >approval time, you never know if some other change is going to conflict >in the next week or so. > >Checking for conflicts hasn't been too painful so far... the >ConflictChecker just requires a single button-push to find direct >conflicts for a changeset. For example, in the last batch of 21 >updates, there was one changeset which had a conflict that I had to >manually fix. However, if a changeset is quite old and has lots of >conflicts as I'm trying to incorporate it, I might give it back to the >author to resolve the conflicts, but I haven't had to do this yet. > >- Doug Way > >------------------------------ > >Date: Sat, 19 Jul 2003 17:05:25 -0700 >From: Ned Konz <ned at bike-nomad.com> >To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Subject: Re: [FIX] ContextCleanupDebugFix (useful enough to incorporate > latest changes?) >Message-ID: <200307191705.25179 at ned.bike-nomad.com> >In-Reply-To: <19E91764-BA32-11D7-A38F-00306558B8E0 at riskmetrics.com> >References: <19E91764-BA32-11D7-A38F-00306558B8E0 at riskmetrics.com> >Content-Type: text/plain; > charset="iso-8859-1" >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 27 > >On Saturday 19 July 2003 02:43 pm, Doug Way wrote: > > Is this latest (v2) fix from Anthony useful enough to incorporate > > for now (for people to use and test), even though there are still a > > couple more things which need to be fixed? It does fix some > > significant problems, and it doesn't look like it introduces any > > new problems, at least. > > > > These are the problems which still need to be fixed, as far as I > > know: - Allow a process to be debugged without having to suspend it > > explicitly (as Ned describes below) > >I don't think this is that critical, since it apparently only affects >the Process Browser. > > > - Something I noticed: If you enter some code in a workspace and > > select "debug it" (or "do it" with a halt in the code), the > > debugger loses the temporary variable names > >It looks like CompiledMethod>>decompileString has been broken. The >temp names are in the CompiledMethod. > >-- >Ned Konz >http://bike-nomad.com >GPG key ID: BEEA7EFE > >------------------------------ > >Date: Sun, 20 Jul 2003 02:19:14 +0200 >From: "Andreas Raab" <andreas.raab at gmx.de> >To: "'The general-purpose Squeak developers list'" > <squeak-dev at lists.squeakfoundation.org> >Subject: RE: [VM] HashBits, a lazy way >Message-ID: <000001c34e54$8d9a39a0$8ef7fea9 at atlantis> >In-Reply-To: <04948D9C-BA28-11D7-8A45-00306540A296 at mac.com> >Content-Type: text/plain; > charset="us-ascii" >MIME-Version: 1.0 >Content-Transfer-Encoding: quoted-printable >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 28 > >John, > > > gcc version is 2.95.2 > > -g -O2 -fomit-frame-pointer > >What about -O3 -mpentium and -funroll-loops? Those are included in my = >builds >by default (though I'm not certain if it makes any big difference). > > > We are comparing AHC changes versus your localization=20 > > changes. Versus say a interp.c that has 20+ t1,t2,... in it... > > Don't know if the 10% you talk about is AHC(sp) > > CGeneratorEnhancements-ajh.1.cs versus yours? =20 > > or to a VM that didn't have the change... > >My comparison was based on a pure VMMaker package as you get it from >SqueakMap. All of my comparisons are against this - I don't know if it >includes the changes you are talking about. > >Which reminds me: The thing you said about "headerTypeBytes" or so = >having an >off-by-one in the C indexing - is this bug in the VMMaker package? > > > Sure declare JMMWhy float as a global, set to zero, then inspect > > this below. > >Err ... I don't get it. You aren't measuring anything here. Shouldn't a >benchmark look somewhere along the lines of: > Time millisecondsToRun:[ > n timesRepeat: [ > 1 asFloat. 1 asFloat. 1 asFloat. 1 asFloat. 1 asFloat. > 1 asFloat. 1 asFloat. 1 asFloat. 1 asFloat. 1 asFloat. > ]. > ]. > >What (and how) are you measuring with the forked process? > >Cheers, > - Andreas > >------------------------------ > >Date: Sun, 20 Jul 2003 02:31:44 +0200 >From: "Andreas Raab" <andreas.raab at gmx.de> >To: "'The general-purpose Squeak developers list'" > <squeak-dev at lists.squeakfoundation.org> >Subject: RE: [Q][VM] mulithreaded ? >Message-ID: <000301c34e56$4c5070c0$8ef7fea9 at atlantis> >In-Reply-To: <87oezqz0i3.fsf at web.de> >Content-Type: text/plain; > charset="us-ascii" >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 29 > > > This concerns only smalltalk objects, right ? Other memory allocated > > by my plugin will not be touched by the GC ? > >Yes. > > > Still I wonder ... If the system is frozen as long as the plugin > > executes the GC has no chance to run. I can see how threads will be a > > problem, but don't the same concerns apply to any stateful code ? > >Yes it would. However, most primitives/ffi calls require the state only for >life-time of the primitive call itself in which case this isn't a problem. >If you do need state to be persistent across primitive calls you will have >to allocate it on the C heap and pass a handle to it back to the Smalltalk >side. > >Cheers, > - Andreas > >------------------------------ > >Date: Sat, 19 Jul 2003 17:35:11 -0700 >From: avi at beta4.com >To: squeak-dev at lists.squeakfoundation.org >Subject: [FIX] NoDoitInPackageInfo-nk >Message-ID: <E19e2AR-0000hB-00 at yukon> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 30 > >Although this has been worked around in PackageInfo, Colin's last post >(modifying MethodReference>>isValid) is the "right" fix from my point of >view, and should be included in the image. It's only one line and could >easily go into 3.6. > > > > > > > > > > > > > >< I'm a bug-fixing machine! > > >The BugFixArchiveViewer is a handy tool that makes it easy to comment on >proposed fixes and enhancements for Squeak. The BugFixArchiveViewer >enables you to browse the Bug Fixes Archive, evaluate the changeset(s) >for a given post, and correctly post a comment to the Bug Fixes Archive >-- all from within the Squeak image. > > Bug Fixes Archive on the Web -> http://swiki.gsug.org/sqfixes > > Guidelines for reporting bugs and fixes -> >http://minnow.cc.gatech.edu/squeak/398 > > Do-it for installing the BugFixArchiveViewer from SqueakMap: > > { '8f502bf8-63bf-43e4-9b85-ec7870ceebac'. >'0a52d654-0b9a-4e1d-abfa-ce8d0f320cfb'. } > do: [ :uuid | SMSqueakMap default > installPackageWithId: uuid ]. >------------------------------ > >Date: Sat, 19 Jul 2003 17:52:40 -0700 (PDT) >From: Avi Bryant <avi at beta4.com> >To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Subject: Re: [FIX] NoDoitInPackageInfo-nk ([er][et][sm]) >Message-ID: <Pine.LNX.4.43L0.0307191752080.9395-100000 at cable.beta4.com> >In-Reply-To: <E19e2AR-0000hB-00 at yukon> >Content-Type: TEXT/PLAIN; charset=US-ASCII >MIME-Version: 1.0 >Content-Transfer-Encoding: 7BIT >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 31 > > >Somehow the BFAV didn't catch my tags... > >On Sat, 19 Jul 2003 avi at beta4.com wrote: > > > Although this has been worked around in PackageInfo, Colin's last post > > (modifying MethodReference>>isValid) is the "right" fix from my point of > > view, and should be included in the image. It's only one line and could > > easily go into 3.6. > >------------------------------ > >Date: Sun, 20 Jul 2003 03:27:26 +0200 >From: "Andreas Raab" <andreas.raab at gmx.de> >To: "'The general-purpose Squeak developers list'" > <squeak-dev at lists.squeakfoundation.org> >Subject: RE: [VM] HashBits, a lazy way >Message-ID: <000401c34e5e$14743bc0$8ef7fea9 at atlantis> >In-Reply-To: <8C5AEBA5-BA22-11D7-8A45-00306540A296 at mac.com> >Content-Type: text/plain; > charset="us-ascii" >MIME-Version: 1.0 >Content-Transfer-Encoding: quoted-printable >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 32 > > > However when I looked at allocation rates for 1 asFloat, =20 > > 2 at 3, Array =20 > > new: 5 I saw > >=20 > > june30thVM 37,654, 40,198, 31,037 > >=20 > > 3.6.1bxVM 75,952, 82,524, 39,325 > >=20 > > Ah, much nicer, also quite remarkable as compared to the powerpc =20 > > benchmarks. > >I reran a couple of allocation benchmarks based on the hash-table = >allocation >and I got a 10-20% speedup in allocating floats and points but = >unfortunately >they didn't translate into anything measurable for the macros (there's a = >.2% >advantage but I don't trust it given that the improvements are not >consistent across the board). So it seems as if using the table lookup >definitely has some advantages (even though their mileage apparently >varies). Here are my benchmarks + results: > >Float allocation benchmark: > >Time millisecondsToRun:[ > 1 to: 1000000 do:[:i| > 1 asFloat. 1 asFloat. 1 asFloat. 1 asFloat. 1 asFloat. > 1 asFloat. 1 asFloat. 1 asFloat. 1 asFloat. 1 asFloat. > ]. >]. > >Point allocation benchmark: > >Time millisecondsToRun:[ > 1 to: 1000000 do:[:i| > 1 at 1. 1 at 1. 1 at 1. 1 at 1. 1 at 1. > 1 at 1. 1 at 1. 1 at 1. 1 at 1. 1 at 1. > ]. >]. > >3.5.1: >Float allocation: 2567 msecs (100%) >Point allocation: 2253 msecs (100%) >Bytecode speed: 117,323,556 bps (100%) >Send speed: 3,419,636 sps (100%) >Macrobenchmarks: #(8798 57570 20546 9797 0 6425 3828)=20 > =3D> 106964 msecs (100%) > >3.5.1 + CodeGenEnh-ar: >Float allocation: 2409 msecs (+6%) >Point allocation: 2245 msecs (+0%) >Bytecode speed: 128,514,056 bps (+9%) >Send speed: 3,755,704 sps (+10%) >Macrobenchmarks: #(8272 53889 18588 9395 0 6105 3683) > =3D> 99932 msecs (+7%) > >3.5.1 + CodeGenEnh-ar + BitOfGCTuning-JMM + AllocateNoFillHashTable-JMM: >Float allocation: 2160 msecs (+18%/+12%) >Point allocation: 1900 msecs (+18%/+18%) >Bytecode speed: 128,643,216 bps ( +9%/ +0%) >Send speed: 3,755,704 sps (+10%/ +0%) >Macrobenchmarks: #(8181 53922 18771 9109 0 6042 3692) > =3D> 99717 msecs ( +7%/ +0%) > >Give or take a few percent as I have been running other apps while doing = >the >benchmarks. > >Cheers, > - Andreas > >------------------------------ > >Date: Sat, 19 Jul 2003 22:33:26 -0500 >From: Adam Spitz <adspitz at yahoo.ca> >To: squeak-dev at lists.squeakfoundation.org >Subject: Nebraska removal >Message-ID: <20030720023545.WDHQ27536.tomts19-srv.bellnexxia.net at adam> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 33 > >Does Nebraska work in the latest 3.6 image? I've made a first cut at a >removal script for it (and it's up on SqueakMap, along with the >reinstallation package), but I've been having trouble getting Nebraska >actually running so that I can test the darned thing. > >Either way, here are a couple of other issues that came up: > > - The removal script leaves a bunch of obsolete classes in the system. >I think this is because of Squeak's history-keeping stuff, because if I >go to a change sorter and destroy changeset 5240MCP-Complete, a bunch of >the obsolete classes go away. What's the right way to fix this? > > - We might want some kind of registry for the buttons on the Navigator >flap (since Nebraska wants to have that "Share" button on it). Right now >the reinstallation package just overwrites the method that creates the >buttons. > > >Adam Spitz >------------------------------ > >Date: Sat, 19 Jul 2003 23:34:57 -0400 >From: dway at riskmetrics.com >To: squeak-dev at lists.squeakfoundation.org >Subject: [FIX][ENH] BoundsInHaloFix-nk ( [et][er][approved] ) >Message-ID: <200307200334.h6K3YvxT151736 at pimout5-ext.prodigy.net> >In-Reply-To: <E19c5wj-0000Sm-K8 at mail1.whidbey.net> >References: <E19YGWv-000167-BH at mail1.whidbey.net> > <E19c5wj-0000Sm-K8 at mail1.whidbey.net> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 34 > > > > > > > > > > > > > > > > >< I'm a bug-fixing machine! > > >This post brought to you by the BugFixArchiveViewer, a handy tool that >makes it easy to comment on proposed fixes and enhancements for Squeak. >For more information, check out the Web page for the BugFixArchiveViewer >project: http://minnow.cc.gatech.edu/squeak/3214 > >< I'm a bug-fixing machine! > >------------------------------ > >Date: Sat, 19 Jul 2003 23:57:21 -0400 >From: Doug Way <dway at riskmetrics.com> >To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Subject: [FIX] EventRecorderPosFix-nk ( a couple of questions ) >Message-ID: <43713690-BA66-11D7-A38F-00306558B8E0 at riskmetrics.com> >In-Reply-To: <E19azBu-0006s4-Tb at mail5.whidbey.net> >Content-Type: text/plain; charset=US-ASCII; format=flowed >MIME-Version: 1.0 (Apple Message framework v551) >Content-Transfer-Encoding: 7bit >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 35 > > >Just looking at this... is there an example of when a position is >needed when replaying a keyboard event? I couldn't come up with an >example where it mattered, although I'm sure there must be one. > >Also, I assume by "cleaned up for MCP approval" you mean that you've >merged the MCP changes with your previous (March 3) changeset? If so, >it looks like you overwrote this MCP change: "lastEvent _ nextEvent >isMouse ifTrue: [nextEvent]." (this looks like it was just a >non-behavior changing simplification though) > >- Doug Way > > >On Friday, July 11, 2003, at 10:48 AM, ned at bike-nomad.com wrote: > > > from preamble: > > > > "Change Set: EventRecorderPosFix-nk > > Date: 11 July 2003 > > Author: Ned Konz > > > > This CS ensures that keyboard events are given positions when replayed > > from the Event Recorder > > > > 11 July: cleaned up for MCP approval > > "! > > > > <EventRecorderPosFix-nk.cs.gz> > >------------------------------ > >Date: Sat, 19 Jul 2003 22:40:52 -0400 >From: cgreuter at csclub.uwaterloo.ca (Chris Reuter) >To: squeak-dev at lists.squeakfoundation.org >Subject: Re: Wanted - dynamic keybindings for Squeak (was: be a web url > -textMorph menus) >Message-ID: <kfvcfb.864.ln at catarneh.blit.ca> >References: <0HHR00MAULRLED at mxout4.netvision.net.il> > <6DD5FD36-B2EC-11D7-8D6A-000393B2AA24 at iam.unibe.ch> >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 36 > >In article <6DD5FD36-B2EC-11D7-8D6A-000393B2AA24 at iam.unibe.ch>, >Stephane Ducasse <squeak-dev at lists.squeakfoundation.org> wrote: > >On Wednesday, July 9, 2003, at 06:32 PM, Daniel Vainsencher wrote: > > > >> We really should be able to configure specific keybindings for > >> applications easily, and the user really should be able to customize > >> them. In short, they should not be hard coded. > > >long time ago I created this kind of functionaluty. I could defined a > >table of binding per window. > >Prefab also has the beginnings of this. It's not very sophisticated >yet, though, and it doesn't extended to non-Prefab interfaces. > > --Chris > >-- >Chris >Reuter http://www.csclub.uwaterloo.ca/~cgreuter >"You're smiling!! Does that mean you'll teach us a lesson?" > --Nukees, 2002/3/8 > >------------------------------ > >Date: Sat, 19 Jul 2003 18:59:02 -0300 >From: Luciano Notarfrancesco <lnotarfrancesco at yahoo.com> >To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Subject: [BUG][FIX] SocketStream|next: >Message-ID: <3F19BF26.50706 at yahoo.com> >Content-Type: multipart/mixed; > boundary="------------090101020808040607080200" >MIME-Version: 1.0 >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 37 > >This is a multi-part message in MIME format. >--------------090101020808040607080200 >Content-Type: text/plain; charset=us-ascii; format=flowed >Content-Transfer-Encoding: 7bit > >Hi, > >In some cases SocketStream|next: answers fewer than the requested number >of bytes. This was driving me crazy untl I found it. I agree that there >should be a method like Flow's nextAvailable: (which answers at most the >requested number of bytes), but I believe next: should block until the >requested data has arrived or raise an exception. > >Luciano > >--------------090101020808040607080200 >Content-Type: application/x-tar; > name="SocketStream-nextFix.cs.gz" >Content-Transfer-Encoding: base64 >Content-Disposition: inline; > filename="SocketStream-nextFix.cs.gz" > >H4sICNG1GT8CA1NvY2tldFN0cmVhbS1uZXh0Rml4LmNzAF2PQU/CQBBGzz3sf/iKhz1ZWCpI >Gy8mhkSv9UZqssAAG9rdujsV8de7ikmDt8nL5M0bufSuRfXekz7m2XxNrOF2kPIOL31zxnQy >yaXEqtFMgdF32ziUuJnls2kNZ6GKYRGaMS9VUaocXStTIdLKbY7EFXvSLVrig9uGpfMlZLgw >YyUC67aLqCGL+7Eqxr8ytYiqKLH0ySW0fbZMe/IiGT3acCI/IKzPse6nO9bpbCSSVaBmF91/ >h4P5ItziGnYuGDbxhYfBVIskOR1MQ6++j29eNJ42ZD7oKbrrTCRv15p/eSlS8Q1C3VkJVQEA >AA== >--------------090101020808040607080200-- > >------------------------------ > >Date: Sat, 19 Jul 2003 23:00:25 -0700 >From: John M McIntosh <johnmci at mac.com> >To: squeak-dev at lists.squeakfoundation.org >Subject: RE: [VM] HashBits, a lazy way >Message-ID: <74EDCDDA-BA77-11D7-8A45-00306540A296 at mac.com> >Content-Type: text/plain; delsp=yes; charset=ISO-8859-1; format=flowed >MIME-Version: 1.0 (Apple Message framework v552) >Content-Transfer-Encoding: quoted-printable >Precedence: list >Reply-To: The general-purpose Squeak developers list > <squeak-dev at lists.squeakfoundation.org> >Message: 38 > > > From:=A0 "Andreas Raab" <andreas.raab at g...> > > Date:=A0 Sun=A0Jul=A020,=A02003=A0 12:19 am > > Subject:=A0 > > > > John, > > > > > gcc version is 2.95.2 > > > -g -O2 -fomit-frame-pointer > > > > What about -O3 -mpentium and -funroll-loops? Those are included in my = >=20 > > builds > > by default (though I'm not certain if it makes any big difference). > >I just used the defaults that Ian used in his make, didn't touch it. > >For unroll-loops this just unrolls for loops, but most loops in the =20 >Squeak VM are while loops. >unroll-all-loops for them, but I don't think it makes a difference. In =20= > >a few places in Squeak we >move memory about in different ways, I think we could change those to a =20= > >for loop and have the >compiler generated unrolled loops, might be better. > >The O3 causes inlining, I noticed in the allocation routine, the object =20= > >initialize routine which isn't inlined by Squeak does get inlined by =20 >the O3, this makes a difference on the powerpc, because we using =20 >working registers to hold values, and avoid 2 register store/load =20 >operation pairs. > > > > > > We are comparing AHC changes versus your localization > > > changes. Versus say a interp.c that has 20+ t1,t2,... in it... > > > Don't know if the 10% you talk about is AHC(sp) > > > CGeneratorEnhancements-ajh.1.cs versus yours? > > > or to a VM that didn't have the change... > > > > My comparison was based on a pure VMMaker package as you get it from > > SqueakMap. All of my comparisons are against this - I don't know if = >it > > includes the changes you are talking about. > >For this test the 100% allocation difference really is just measuring =20= > >the changes to the allocation >routine and hash table lookup. The other changes happen to be along =20 >for the ride but don't really affect things. > > > > Which reminds me: The thing you said about "headerTypeBytes" or so =20= > > > having an > > off-by-one in the C indexing - is this bug in the VMMaker package? > >It's not a bug, it's due to my originally using an Array versus =20 >CArrayAccessor in Interpreter for headerTypeBytes. (PS I wonder if =20 >there are other array indexing issues like that in the VM?) > >The change I made there was not to do the +1, that of course was there =20= > >so the InterpreterSimulator won't choke on (headTypeBytes at: 0 for an =20= > >Array, ok for CArrayAccessor). > >For the powerpc this makes no difference because I think the integer =20 >unit(s) consume the addition in step with the other arithmetic =20 >instructions. Less capable CPUS (68K) will benefit by not having to do =20= > >the addition. > > > > > > Sure declare JMMWhy float as a global, set to zero, then inspect > > > this below. > > > > Err ... I don't get it. You aren't measuring anything here. Shouldn't = >=20 > > a > > benchmark look somewhere along the lines of: > > Time millisecondsToRun:[ > > n timesRepeat: [ > > 1 asFloat. 1 asFloat. 1 asFloat. 1 asFloat. 1 asFloat. > > 1 asFloat. 1 asFloat. 1 asFloat. 1 asFloat. 1 asFloat. > > ]. > > ]. > > > > What (and how) are you measuring with the forked process? > > > > Cheers, > > - Andreas > > > > Ah, yes I've a Morphic along the lines of the framerate morphic to =20 >grab the JMMwhy value >every second or so, then look at current - old remembered counter =20 >divided by the actual time interval. Also to remember the peak. This =20 >allows me to watch the allocations per second in real time, and after =20= > >running enough gather the peak allocation rate. You could of course do =20= > >a TIme millisecond and a calculation to get the average... > > >-- >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 >=3D=3D=3D >John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659 >Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 >=3D=3D=3D= > >------------------------------ > >_______________________________________________ >Squeak-dev mailing list >Squeak-dev at lists.squeakfoundation.org >http://lists.squeakfoundation.org/listinfo/squeak-dev > >End of Squeak-dev Digest, Vol 7, Issue 49 >*****************************************
More information about the Squeak-dev mailing list |