January 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Ann] ReadWriteLock

by Denis Kudriashov

Ok. I wrote MutextTests which show problems. See in attachment. Attached Mutex.st contains fix which suggest Ben for his scenario. But it broke other scenario. Mutex>>critical: aBlock "Evaluate aBlock protected by the receiver." | activeProcess signalRequired blockValue | activeProcess := Processor activeProcess. activeProcess == owner ifTrue:[^aBlock value]. signalRequired := false. [ signalRequired := true. semaphore wait. owner:= activeProcess. blockValue := aBlock value ] ensure: [signalRequired & (owner == activeProcess) ifTrue: [owner := nil. semaphore signal]]. ^blockValue My idea of ifCurtailed: usage not helps too. But if you change MutexTest to use Semaphore instead of Mutex then all tests will be green. 2016-01-06 13:38 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > If you run it, and are confused '2 start' never shows up in transcript, I > intended the start messages to be outside critical blocks, sorry for old > copypasta. > > Cheers, > Henry > > On 06 Jan 2016, at 1:29 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> > wrote: > > > On 05 Jan 2016, at 7:52 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> > wrote: > > > On 05 Jan 2016, at 7:24 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-01-05 18:49 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > >> ifCurtailed: only unwinds if an error/termination occured, so that would >> mean not signalling the semaphore when everything goes as planned, and we >> leave the critical section... > > > I not suppose to replace #ensure: with #ifCurtailed:. I think about: > > signalRequired := false. > [ > [signalRequired := true. > self wait] ifCurtailed: [signalRequired := false]. > blockValue := mutuallyExcludedBlock value > ] ensure: [signalRequired ifTrue: [self signal]]. > ^blockValue > > > Ah, that makes more sense, yes, much simpler than what I wrote! > AFAICT, it should work too ;) > > > After thinking a bit more, it suffers from a similar edge case where the > semaphore has been signaled, but process is terminated before it's had a > chance to run, after changing to ifCurtailed and cleaning #terminate: > > "This runs on UI thread, pri 40" > waiter := Semaphore new. > waiter2 := Semaphore new. > lock := Semaphore forMutualExclusion. > > proc := [lock critical: [ Transcript crShow: '1 start'. > waiter wait. > Transcript crShow: '1 done'.]] newProcess. > proc priority: 70. > proc resume. > > proc2 := [lock critical: [ Transcript crShow: '2 start'. > waiter2 wait. > Transcript crShow: '2 done'. ]] newProcess. > proc2 priority: 15. > proc2 resume. > > "Yield for proc2 so it gets to waiting on lock" > 1 second wait. > "Signal waiter and yield, causing proc1 to run, and release the lock. lock > will then remove proc2 from waiting list" > waiter signal. > Processor yield. > "We have a higher pri than proc2, and will resume execution here before > proc2 has chance to run" > proc2 terminate. > "proc2 has been curtailed before running, thus ifCurtailed: guard is still > on stack and will be run as part of termination." > (lock instVarNamed: 'excessSignals') 0 "Should be 1" > > Cheers, > Henry > > >

Jan. 6, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Henrik Johansen

If you run it, and are confused '2 start' never shows up in transcript, I intended the start messages to be outside critical blocks, sorry for old copypasta. Cheers, Henry > On 06 Jan 2016, at 1:29 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >> >> On 05 Jan 2016, at 7:52 , Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: >> >> >>> On 05 Jan 2016, at 7:24 , Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >>> >>> >>> 2016-01-05 18:49 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>>: >>> ifCurtailed: only unwinds if an error/termination occured, so that would mean not signalling the semaphore when everything goes as planned, and we leave the critical section... >>> >>> I not suppose to replace #ensure: with #ifCurtailed:. I think about: >>> >>> signalRequired := false. >>> [ >>> [signalRequired := true. >>> self wait] ifCurtailed: [signalRequired := false]. >>> blockValue := mutuallyExcludedBlock value >>> ] ensure: [signalRequired ifTrue: [self signal]]. >>> ^blockValue >>> >> >> Ah, that makes more sense, yes, much simpler than what I wrote! >> AFAICT, it should work too ;) > > After thinking a bit more, it suffers from a similar edge case where the semaphore has been signaled, but process is terminated before it's had a chance to run, after changing to ifCurtailed and cleaning #terminate: > > "This runs on UI thread, pri 40" > waiter := Semaphore new. > waiter2 := Semaphore new. > lock := Semaphore forMutualExclusion. > > proc := [lock critical: [ Transcript crShow: '1 start'. > waiter wait. > Transcript crShow: '1 done'.]] newProcess. > proc priority: 70. > proc resume. > > proc2 := [lock critical: [ Transcript crShow: '2 start'. > waiter2 wait. > Transcript crShow: '2 done'. ]] newProcess. > proc2 priority: 15. > proc2 resume. > > "Yield for proc2 so it gets to waiting on lock" > 1 second wait. > "Signal waiter and yield, causing proc1 to run, and release the lock. lock will then remove proc2 from waiting list" > waiter signal. > Processor yield. > "We have a higher pri than proc2, and will resume execution here before proc2 has chance to run" > proc2 terminate. > "proc2 has been curtailed before running, thus ifCurtailed: guard is still on stack and will be run as part of termination." > (lock instVarNamed: 'excessSignals') 0 "Should be 1" > > Cheers, > Henry

Jan. 6, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Henrik Johansen

> On 05 Jan 2016, at 7:52 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > >> On 05 Jan 2016, at 7:24 , Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> >> 2016-01-05 18:49 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>>: >> ifCurtailed: only unwinds if an error/termination occured, so that would mean not signalling the semaphore when everything goes as planned, and we leave the critical section... >> >> I not suppose to replace #ensure: with #ifCurtailed:. I think about: >> >> signalRequired := false. >> [ >> [signalRequired := true. >> self wait] ifCurtailed: [signalRequired := false]. >> blockValue := mutuallyExcludedBlock value >> ] ensure: [signalRequired ifTrue: [self signal]]. >> ^blockValue >> > > Ah, that makes more sense, yes, much simpler than what I wrote! > AFAICT, it should work too ;) After thinking a bit more, it suffers from a similar edge case where the semaphore has been signaled, but process is terminated before it's had a chance to run, after changing to ifCurtailed and cleaning #terminate: "This runs on UI thread, pri 40" waiter := Semaphore new. waiter2 := Semaphore new. lock := Semaphore forMutualExclusion. proc := [lock critical: [ Transcript crShow: '1 start'. waiter wait. Transcript crShow: '1 done'.]] newProcess. proc priority: 70. proc resume. proc2 := [lock critical: [ Transcript crShow: '2 start'. waiter2 wait. Transcript crShow: '2 done'. ]] newProcess. proc2 priority: 15. proc2 resume. "Yield for proc2 so it gets to waiting on lock" 1 second wait. "Signal waiter and yield, causing proc1 to run, and release the lock. lock will then remove proc2 from waiting list" waiter signal. Processor yield. "We have a higher pri than proc2, and will resume execution here before proc2 has chance to run" proc2 terminate. "proc2 has been curtailed before running, thus ifCurtailed: guard is still on stack and will be run as part of termination." (lock instVarNamed: 'excessSignals') 0 "Should be 1" Cheers, Henry

Jan. 6, 2016

Re: [Pharo-dev] Catalog statistics (Who know this projects?)

by Serge Stinckwich

Catalog update for Kendrick & CORMAS project. Alex already did the work for A4BP project. Regards, On Tue, Jan 5, 2016 at 4:21 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Soâ¦ I took a couple of minutes to do a small list of project description status: > > From a total of 379 projects currently in the catalog, just 115 have a description and/or keywords associated. > Which means 264 are mysterious projects nobody can guess what are they about. > > I was thinking most of this projects would be in Unsorted (or Pharo 3), but I found that many are also on Pharo 5 and 4â¦. which is frankly unacceptable :) > Even very important projects like Seaside or Garage and Glorp are not documented. > > So, please peopleâ¦ take a look at your projects and PLEASE, provide a description and proper keywordsâ¦ Nobody can guess what is Aconcagua (besides a cool mountain in south america), or Telescope, etc., etc., etc. > > Here the list of non-documented projects: > > > http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main > --- > 'A4BP' > 'Aconcagua' > 'BootstrapMagritte' > 'Chalten' > 'CommandShell' > 'Cormas' > 'DependencyAnalyser' > 'FamixJS' > 'FontAwesome' > 'Garage' > 'GarageConnectionPool' > 'GarageGlorp' > 'Glorp' > 'Grease' > 'IniModules' > 'Kendrick' > 'Magritte3' > 'MagritteMagic' > 'MetaBoardBoard' > 'MyFirstWebApp' > 'NBOpenGL' > 'NeoJSON' > 'OSProcess' > 'PetitParser' > 'Phexample' > 'Pier3' > 'Pier3AddOns' > 'ProcessWrapper' > 'RewriteTool' > 'Seaside3' > 'SimplePersistence' > 'Ston' > 'Telescope' > 'Woden' > âXtreams' > > http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo40/main > --- > 'AconcaguaDeluxe' > 'AthensSVG' > 'Autotest' > 'CPanel' > 'CreativeCommonsLive' > 'DevFlow' > 'EventRecorder' > 'ExtendedNumberParser' > 'ExternalWebBrowser2' > 'FixedDecimal' > 'Ghost' > 'GraphViz' > 'Gravatar' > 'Hubcap' > 'Infinity' > 'Mandrill' > 'Mathex' > 'MemoryMonitor' > 'MinimalConnectors' > 'Mocketry' > 'MongoTalk' > 'NBSQLite3' > 'NumericalMethods' > 'ODBC' > 'OSOSX' > 'OSWindows' > 'PackageDependenciesAnalysis' > 'PharoLauncher' > 'PlagueDoctor' > 'Pomodoro' > 'RemoteAnnouncement' > 'SandstoneDb' > 'Scheduler' > 'ScriptManager' > 'Shapes' > 'SmallUML' > 'Spreadsheet' > 'Spy' > 'StateSpecs' > 'SuffixConditionals' > 'Teachable' > 'TestMock' > 'Trees' > 'Twilio' > 'Vidi' > 'VistaCursors' > 'Viva' > 'WiringPi' > 'WorkingSet' > 'XBase' > 'sQuick' > âsQuick_new' > > http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main > --- > 'Actalk' > 'Arduino' > 'BabyMock2' > 'CTranslator' > 'DBPedia' > 'DigitalOcean' > 'Forum' > 'Fuel' > 'GTDebugger' > 'GTInspector' > 'GTInspectorCore' > 'GTPlayground' > 'GTPlaygroundCore' > 'GTSpotter' > 'GToolkit' > 'GlamourCore' > 'GlorpDBX' > 'GraphET' > 'InstanceEncoder' > 'Marina' > 'Mechanize' > 'Memcached' > 'Moose' > 'Pastell' > 'PharoOnlineHelp' > 'ProfStef' > 'PythonParser' > 'RFB' > 'Roassal3d' > 'SQLite3' > 'Smallapack' > 'SmalltalkHub' > 'Snapshotcello' > 'SortFunctions' > 'Spotlight' > 'Stamp' > 'Tide' > 'VersionBrowser' > âVersionner' > > http://www.squeaksource.com/MetacelloRepository > --- > 'AXAnnouncements' > 'Adore' > 'Aida' > 'Ajp' > 'Algernon' > 'Alien' > 'Amers' > 'Announcements' > 'AutomaticMethodCategorizer' > 'BetaNineIPAddress' > 'CAnalyzer' > 'CairoGraphics' > 'CampSmalltalkLondon' > 'Cecinestpasunepomme' > 'CharacterMap' > 'Chronos' > 'CloudforkAWS' > 'Cog' > 'Connectors' > 'ContextS' > 'Control' > 'Country' > 'Countryside' > 'DBXBrowser' > 'DBXTools' > 'DependencyBrowser' > 'DependencyView' > 'EnhancedOmniBrowser' > 'ExternalIconFamily' > 'ExternalWebBrowser' > 'FileMan' > 'FileTree' > 'Filesystem' > 'GemTools' > 'Gitocello' > 'Glamour' > 'Gofer' > 'GoferProjectLoader' > 'GoogleAnalytics' > 'HPDF' > 'HealthReportProducer' > 'HelpSystem' > 'ICal' > 'InstancesBrowser' > 'JQueryWidgetBox' > 'JavaScriptAnalyzer' > 'Jejak' > 'Keymapping' > 'Kozen' > 'KyotoTycoonClient' > 'MaBase' > 'MaClientServer' > 'Magma' > 'Magmafy' > 'Magritte' > 'Magritte2' > 'Magritte3AddOns' > 'MagritteAddOns2' > 'Metacello' > 'MetacelloBrowser' > 'MetacelloPreview' > 'MockGemStone' > 'Mondrian' > 'Money' > 'MonticelloRedirect' > 'Murmansk' > 'Nagare' > 'NativeBoost' > 'Neo4reSt' > 'NewECompletion' > 'NewInspector' > 'NewOCompletion' > 'Nile' > 'NotificationsArea' > 'O2' > 'OCompletion' > 'OPAX' > 'ObjectMetaTools' > 'OmniBrowser' > 'OmniBrowserLukas' > 'Orca' > 'PagedReader' > 'Pharo' > 'PharoMorphicExtras' > 'PharoNonCore' > 'Phriak' > 'Pier' > 'Pier2' > 'PierAddOns' > 'PierAddOns2' > 'PostMark' > 'ProcessModel' > 'Quaternion' > 'REPL' > 'Raphael' > 'RatPack' > 'RefactoringBrowser' > 'RefactoringTools' > 'RoelTyper' > 'SIXX' > 'SPort2' > 'SandcastleThemes' > 'Scamper' > 'Scribo' > 'Seafox' > 'Seaside' > 'Seaside28' > 'Seaside28Examples' > 'Seaside30' > 'SeasideJSON' > 'SeasideRest' > 'SeasideTesting' > 'SharedWorkspace' > 'Shout' > 'SimpleApplescript' > 'SoapOpera' > 'SpellingServices' > 'SpyForO2' > 'Sqnappy' > 'SqueakCheck' > 'SqueakDBX' > 'SqueakFS' > 'SqueakSource' > 'StOMP' > 'Stripe' > 'SunnysidePlanning2' > 'SwaLint' > 'Swazoo2' > 'TODO' > 'TimerDaemon' > 'Tuio' > 'VMMaker' > 'Waterfall' > 'WebClient' > 'WebTester' > 'XMLRPC' > 'XMLSupport' > 'Zodiac' > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Jan. 6, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50512 Home: https://github.com/pharo-project/pharo-core

Jan. 6, 2016

[pharo-project/pharo-core] 73b130: 50512

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 73b130f0abcc51cb3c21a5004bba1909a6717631 https://github.com/pharo-project/pharo-core/commit/73b130f0abcc51cb3c21a500… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-06 (Wed, 06 Jan 2016) Changed paths: A ContributingToTheCatalogHelp.package/ContributingToTheCatalogHelp.class/class/accessing/bookName.st A ContributingToTheCatalogHelp.package/ContributingToTheCatalogHelp.class/class/accessing/pages.st R ContributingToTheCatalogHelp.package/ContributingToTheCatalogHelp.class/class/as yet unclassified/bookName.st R ContributingToTheCatalogHelp.package/ContributingToTheCatalogHelp.class/class/as yet unclassified/pages.st M ContributingToTheCatalogHelp.package/ContributingToTheCatalogHelp.class/class/pages/addingYourProject.st M Kernel.package/Context.class/instance/mirror primitives/objectSize_.st A Kernel.package/Context.class/instance/mirror primitives/object_basicAt_.st A Kernel.package/Context.class/instance/mirror primitives/object_basicAt_put_.st A Kernel.package/Context.class/instance/mirror primitives/object_eqeq_.st A Kernel.package/Context.class/instance/mirror primitives/object_instVarAt_.st A Kernel.package/Context.class/instance/mirror primitives/object_instVarAt_put_.st A Kernel.package/Context.class/instance/mirror primitives/object_perform_withArguments_inClass_.st M RPackage-Core.package/RPackage.class/instance/accessing/methods.st M RPackage-Core.package/RPackage.class/instance/accessing/name_.st M RPackage-Core.package/RPackage.class/instance/accessing/renameTo_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50511.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50512.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50511.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50512.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50512 17321 Improvement of CatalogHelp https://pharo.fogbugz.com/f/cases/17321 17305 Comments on the class RPackage https://pharo.fogbugz.com/f/cases/17305 17313 Missing primitive methods in Context https://pharo.fogbugz.com/f/cases/17313 http://files.pharo.org/image/50/50512.zip

Jan. 6, 2016

Re: [Pharo-dev] Catalog statistics (Who know this projects?)

by Yuriy Tymchuk

Iâve fixed my project > On 05 Jan 2016, at 16:21, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Soâ¦ I took a couple of minutes to do a small list of project description status: > > From a total of 379 projects currently in the catalog, just 115 have a description and/or keywords associated. > Which means 264 are mysterious projects nobody can guess what are they about. > > I was thinking most of this projects would be in Unsorted (or Pharo 3), but I found that many are also on Pharo 5 and 4â¦. which is frankly unacceptable :) > Even very important projects like Seaside or Garage and Glorp are not documented. > > So, please peopleâ¦ take a look at your projects and PLEASE, provide a description and proper keywordsâ¦ Nobody can guess what is Aconcagua (besides a cool mountain in south america), or Telescope, etc., etc., etc. > > Here the list of non-documented projects: > > > http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main > --- > 'A4BP' > 'Aconcagua' > 'BootstrapMagritte' > 'Chalten' > 'CommandShell' > 'Cormas' > 'DependencyAnalyser' > 'FamixJS' > 'FontAwesome' > 'Garage' > 'GarageConnectionPool' > 'GarageGlorp' > 'Glorp' > 'Grease' > 'IniModules' > 'Kendrick' > 'Magritte3' > 'MagritteMagic' > 'MetaBoardBoard' > 'MyFirstWebApp' > 'NBOpenGL' > 'NeoJSON' > 'OSProcess' > 'PetitParser' > 'Phexample' > 'Pier3' > 'Pier3AddOns' > 'ProcessWrapper' > 'RewriteTool' > 'Seaside3' > 'SimplePersistence' > 'Ston' > 'Telescope' > 'Woden' > âXtreams' > > http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo40/main > --- > 'AconcaguaDeluxe' > 'AthensSVG' > 'Autotest' > 'CPanel' > 'CreativeCommonsLive' > 'DevFlow' > 'EventRecorder' > 'ExtendedNumberParser' > 'ExternalWebBrowser2' > 'FixedDecimal' > 'Ghost' > 'GraphViz' > 'Gravatar' > 'Hubcap' > 'Infinity' > 'Mandrill' > 'Mathex' > 'MemoryMonitor' > 'MinimalConnectors' > 'Mocketry' > 'MongoTalk' > 'NBSQLite3' > 'NumericalMethods' > 'ODBC' > 'OSOSX' > 'OSWindows' > 'PackageDependenciesAnalysis' > 'PharoLauncher' > 'PlagueDoctor' > 'Pomodoro' > 'RemoteAnnouncement' > 'SandstoneDb' > 'Scheduler' > 'ScriptManager' > 'Shapes' > 'SmallUML' > 'Spreadsheet' > 'Spy' > 'StateSpecs' > 'SuffixConditionals' > 'Teachable' > 'TestMock' > 'Trees' > 'Twilio' > 'Vidi' > 'VistaCursors' > 'Viva' > 'WiringPi' > 'WorkingSet' > 'XBase' > 'sQuick' > âsQuick_new' > > http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main > --- > 'Actalk' > 'Arduino' > 'BabyMock2' > 'CTranslator' > 'DBPedia' > 'DigitalOcean' > 'Forum' > 'Fuel' > 'GTDebugger' > 'GTInspector' > 'GTInspectorCore' > 'GTPlayground' > 'GTPlaygroundCore' > 'GTSpotter' > 'GToolkit' > 'GlamourCore' > 'GlorpDBX' > 'GraphET' > 'InstanceEncoder' > 'Marina' > 'Mechanize' > 'Memcached' > 'Moose' > 'Pastell' > 'PharoOnlineHelp' > 'ProfStef' > 'PythonParser' > 'RFB' > 'Roassal3d' > 'SQLite3' > 'Smallapack' > 'SmalltalkHub' > 'Snapshotcello' > 'SortFunctions' > 'Spotlight' > 'Stamp' > 'Tide' > 'VersionBrowser' > âVersionner' > > http://www.squeaksource.com/MetacelloRepository > --- > 'AXAnnouncements' > 'Adore' > 'Aida' > 'Ajp' > 'Algernon' > 'Alien' > 'Amers' > 'Announcements' > 'AutomaticMethodCategorizer' > 'BetaNineIPAddress' > 'CAnalyzer' > 'CairoGraphics' > 'CampSmalltalkLondon' > 'Cecinestpasunepomme' > 'CharacterMap' > 'Chronos' > 'CloudforkAWS' > 'Cog' > 'Connectors' > 'ContextS' > 'Control' > 'Country' > 'Countryside' > 'DBXBrowser' > 'DBXTools' > 'DependencyBrowser' > 'DependencyView' > 'EnhancedOmniBrowser' > 'ExternalIconFamily' > 'ExternalWebBrowser' > 'FileMan' > 'FileTree' > 'Filesystem' > 'GemTools' > 'Gitocello' > 'Glamour' > 'Gofer' > 'GoferProjectLoader' > 'GoogleAnalytics' > 'HPDF' > 'HealthReportProducer' > 'HelpSystem' > 'ICal' > 'InstancesBrowser' > 'JQueryWidgetBox' > 'JavaScriptAnalyzer' > 'Jejak' > 'Keymapping' > 'Kozen' > 'KyotoTycoonClient' > 'MaBase' > 'MaClientServer' > 'Magma' > 'Magmafy' > 'Magritte' > 'Magritte2' > 'Magritte3AddOns' > 'MagritteAddOns2' > 'Metacello' > 'MetacelloBrowser' > 'MetacelloPreview' > 'MockGemStone' > 'Mondrian' > 'Money' > 'MonticelloRedirect' > 'Murmansk' > 'Nagare' > 'NativeBoost' > 'Neo4reSt' > 'NewECompletion' > 'NewInspector' > 'NewOCompletion' > 'Nile' > 'NotificationsArea' > 'O2' > 'OCompletion' > 'OPAX' > 'ObjectMetaTools' > 'OmniBrowser' > 'OmniBrowserLukas' > 'Orca' > 'PagedReader' > 'Pharo' > 'PharoMorphicExtras' > 'PharoNonCore' > 'Phriak' > 'Pier' > 'Pier2' > 'PierAddOns' > 'PierAddOns2' > 'PostMark' > 'ProcessModel' > 'Quaternion' > 'REPL' > 'Raphael' > 'RatPack' > 'RefactoringBrowser' > 'RefactoringTools' > 'RoelTyper' > 'SIXX' > 'SPort2' > 'SandcastleThemes' > 'Scamper' > 'Scribo' > 'Seafox' > 'Seaside' > 'Seaside28' > 'Seaside28Examples' > 'Seaside30' > 'SeasideJSON' > 'SeasideRest' > 'SeasideTesting' > 'SharedWorkspace' > 'Shout' > 'SimpleApplescript' > 'SoapOpera' > 'SpellingServices' > 'SpyForO2' > 'Sqnappy' > 'SqueakCheck' > 'SqueakDBX' > 'SqueakFS' > 'SqueakSource' > 'StOMP' > 'Stripe' > 'SunnysidePlanning2' > 'SwaLint' > 'Swazoo2' > 'TODO' > 'TimerDaemon' > 'Tuio' > 'VMMaker' > 'Waterfall' > 'WebClient' > 'WebTester' > 'XMLRPC' > 'XMLSupport' > 'Zodiac' > >

Jan. 6, 2016

Re: [Pharo-dev] ExternalSemaphoreTable strange mutual exclusion

by Henrik Johansen

> On 06 Jan 2016, at 10:25 , Ben Coman <btc(a)openinworld.com> wrote: > > In ExternalSemaphoreTable I noticed two class variables set by class > initialization as: > ProtectAdd := Semaphore forMutualExclusion. > ProtectRemove := Semaphore forMutualExclusion > > and I'm curious, what are the TWO shared resources that these TWO are > meant to protect? it seems there is only one, that being > unprotectedExternalObjects. There is only one resource, but two classes of operations that need to be independently serialized. You can safely add and remove from the array concurrently, just concurrent adds or concurrent removes might lead to trouble. Using two semaphores in this case is probably less useful in practice than as an example of how more finely grained locks are sometimes possible. > > I notice that "ExternalSemaphoreTable class>>safelyUnregisterExternalObject:" > stores unprotectedExternalObjects in its local variable "objects" > and then up removes an object from it. The safely: should be moved to private category, probably renamed private* , and have a comment stating that they are the inner critical sections; calls must be protected by the appropriate locks. > > But "ExternalSemaphoreTable class>>safelyRegisterExternalObject:" > also stores unprotectedExternalObjects in its local variable "objects" > which it then passes to "ExternalSemaphoreTable > class>>collectionBasedOn:withRoomFor:" > which takes a copy to grow a new collection to store into > unprotectedExternalObjects. > > Even though its a rare case that the external semaphore might grow at > just the same time that an object is being unregistered, and also > practically #safelyUnregisterExternalObject: might not be preemptable, > this smells bad having two mutual exclusions covering one resource - > thus no mutual exclusion at all. Is there something I'm missing? Not really. The only valid caller of collectionBasedOn: is addExternalObject, so the method always executes inside ProtectAdd critical section. There is, however, a ProtectRemove critical section missing, should be one around: newObjects replaceFrom: 1 to: externalObjects size with: externalObjects startingAt: 1. self unprotectedExternalObjects: newObjects. Cheers, Henry

Jan. 6, 2016

Re: [Pharo-dev] CasInsensitiveOrder map with upper/lower case characters for all latin1 entries

by Nicolai Hess

2016-01-06 11:09 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > > On 06 Jan 2016, at 10:09 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Hallo Nicolai, > > > >> On 06 Jan 2016, at 09:58, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > >> > >> > >> see issues 17302/17242/17227 > >> String>>findString:startindAt:caseSensitive appears to be failing for > extended charsets > >> String>>compare:caseSensitive seems to be failing for extended charset > comparisons > >> String>>beginsWithEmpty:caseSensitive: has test failure for some cases > >> > >> the problem is, the standard character set used for building the > CaseInsensitiveOrder map > >> only maps characters from the set of ascii characters but it is used in > the findString/compare/beginsWith-methods for all byte characters. > >> > >> Any objections if we fill this map like it is suggested in case 17242 ? > >> > >> CaseInsensitiveOrder := AsciiOrder copy. > >> (0 to: 255) do:[ :v | > >> | char upper | > >> char := v asCharacter. > >> upper := char asUppercase. > >> upper isOctetCharacter > >> ifFalse: [ upper := char ]. > >> CaseInsensitiveOrder at: char asciiValue + 1 put: > (CaseInsensitiveOrder at: upper asciiValue + 1) ]. > >> > >> (the check for #isOctectCharacter is needed because for some entries > the correspondending > >> uppercase character is not within this character set). > >> > >> This would solve all three issues. > >> > >> > >> nicolai > > > > That looks like a beautiful fix that makes perfect sense. > > If all tests are green, I see no reason not to do it. > > > > Thanks and well done (again), > > > > Sven > > > > > If you use asLowercase as the "canonical" ordering index instead, can you > drop the isOctetCharacter test, or are there uppercase characters in latin1 > with no corresponding lowercases? > Interesting, good idea, there are no uppercase characters without lowercases. > > I was about to suggest copying the CaseSensitiveOrder mapping instead of > the AsciiOrder, since it has an ordering more refined than just A-Z, but > that would quickly lead to wanting to extend it to a generic Latin1 sort > order rather than just ASCII (Ã© between e and f, for example), which is a > can of worms that is hard to solve without making the ordering locale > specific... > I mean, one could use the default Unicode ordering, but would inevitably > receive complaints from, say, Norwegians, that Ã¥ sorts between a and b > instead of after z. > I didn't thought about ordering..., and I think I don't want to :) > > After all, it only affects the case where compare is used for ordering > anyways. > > Cheers, > Henry >

Jan. 6, 2016

Re: [Pharo-dev] CasInsensitiveOrder map with upper/lower case characters for all latin1 entries

by Nicolai Hess

2016-01-06 10:09 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Hallo Nicolai, > > > On 06 Jan 2016, at 09:58, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > see issues 17302/17242/17227 > > String>>findString:startindAt:caseSensitive appears to be failing for > extended charsets > > String>>compare:caseSensitive seems to be failing for extended charset > comparisons > > String>>beginsWithEmpty:caseSensitive: has test failure for some cases > > > > the problem is, the standard character set used for building the > CaseInsensitiveOrder map > > only maps characters from the set of ascii characters but it is used in > the findString/compare/beginsWith-methods for all byte characters. > > > > Any objections if we fill this map like it is suggested in case 17242 ? > > > > CaseInsensitiveOrder := AsciiOrder copy. > > (0 to: 255) do:[ :v | > > | char upper | > > char := v asCharacter. > > upper := char asUppercase. > > upper isOctetCharacter > > ifFalse: [ upper := char ]. > > CaseInsensitiveOrder at: char asciiValue + 1 put: > (CaseInsensitiveOrder at: upper asciiValue + 1) ]. > > > > (the check for #isOctectCharacter is needed because for some entries the > correspondending > > uppercase character is not within this character set). > > > > This would solve all three issues. > > > > > > nicolai > > That looks like a beautiful fix that makes perfect sense. > If all tests are green, I see no reason not to do it. > Thanks for you feedback. > Thanks and well done (again), > :) > > Sven > > >

Jan. 6, 2016