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

Catalog statistics (Who know this projects?)

by Esteban Lorenzano

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. 5, 2016

Re: [Pharo-dev] Syntax Highlighting error (RBParseErrorNode(Object)>>doesNotUnderstand: #isInstance)

by Marcus Denker

yes, this is fixed by https://pharo.fogbugz.com/f/cases/17276/Semantic-Analysis-needs-refactoring I am now back from holidays and will review/intergrate this soon. > On 05 Jan 2016, at 16:15, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I am seeing the following very annoying error in 50511 spur. > > Open a Playground, > type [ (both open en close are inserted, with the cursor in-between), > type : (to start a block arg), > boom: > > RBParseErrorNode(Object)>>doesNotUnderstand: #isInstance > OCASTClosureAnalyzer>>changeVariableClass: > OCASTClosureAnalyzer>>visitArgumentNode: > [ :each | self visitArgumentNode: each ] in OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitArgumentNodes: > OrderedCollection>>do: > OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitArgumentNodes: > OCASTClosureAnalyzer>>visitBlockNode: > RBBlockNode>>acceptVisitor: > OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: > [ :each | self visitNode: each ] in OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitSequenceNode: > OrderedCollection>>do: > OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitSequenceNode: > RBSequenceNode>>acceptVisitor: > OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: > OCASTClosureAnalyzer>>visitMethodNode: > RBMethodNode>>acceptVisitor: > OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: > OCASTSemanticAnalyzer>>analyze: > RBMethodNode>>doSemanticAnalysis > RBBlockNode(RBProgramNode)>>doSemanticAnalysis > RubSHTextStylerST80(SHRBTextStyler)>>privateStyle: > [ self privateStyle: text. > view ifNotNil: [ view stylerStyledInBackground: text ] ] in [ backgroundProcess := [ self privateStyle: text. > view ifNotNil: [ view stylerStyledInBackground: text ] ] > forkAt: Processor userBackgroundPriority ] in RubSHTextStylerST80(SHTextStyler)>>styleInBackgroundProcess: > [ self value. > Processor terminateActive ] in BlockClosure>>newProcess > > Has this already been reported ? > > It makes the image almost unusable... > > Sven > >

Jan. 5, 2016

Syntax Highlighting error (RBParseErrorNode(Object)>>doesNotUnderstand: #isInstance)

by Sven Van Caekenberghe

I am seeing the following very annoying error in 50511 spur. Open a Playground, type [ (both open en close are inserted, with the cursor in-between), type : (to start a block arg), boom: RBParseErrorNode(Object)>>doesNotUnderstand: #isInstance OCASTClosureAnalyzer>>changeVariableClass: OCASTClosureAnalyzer>>visitArgumentNode: [ :each | self visitArgumentNode: each ] in OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitArgumentNodes: OrderedCollection>>do: OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitArgumentNodes: OCASTClosureAnalyzer>>visitBlockNode: RBBlockNode>>acceptVisitor: OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: [ :each | self visitNode: each ] in OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitSequenceNode: OrderedCollection>>do: OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitSequenceNode: RBSequenceNode>>acceptVisitor: OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: OCASTClosureAnalyzer>>visitMethodNode: RBMethodNode>>acceptVisitor: OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: OCASTSemanticAnalyzer>>analyze: RBMethodNode>>doSemanticAnalysis RBBlockNode(RBProgramNode)>>doSemanticAnalysis RubSHTextStylerST80(SHRBTextStyler)>>privateStyle: [ self privateStyle: text. view ifNotNil: [ view stylerStyledInBackground: text ] ] in [ backgroundProcess := [ self privateStyle: text. view ifNotNil: [ view stylerStyledInBackground: text ] ] forkAt: Processor userBackgroundPriority ] in RubSHTextStylerST80(SHTextStyler)>>styleInBackgroundProcess: [ self value. Processor terminateActive ] in BlockClosure>>newProcess Has this already been reported ? It makes the image almost unusable... Sven

Jan. 5, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Ben Coman

On Tue, Jan 5, 2016 at 1:39 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > I implemented small package ReadWriteLock > http://smalltalkhub.com/mc/Pharo/ReadWriteLock/main. > > Gofer it > smalltalkhubUser: 'Pharo' project: 'ReadWriteLock'; > configurationOf: 'ReadWriteLock'; > loadStable > > > It is reentral read write lock which described in > https://en.wikipedia.org/wiki/Readersâwriter_lock. From the article: > >> An ReadWriteLock allows concurrent access for read-only operations, while >> write operations require exclusive access. This means that multiple threads >> can read the data in parallel but an exclusive lock is needed for writing or >> modifying data. When a writer is writing the data, all other writers or >> readers will be blocked until the writer is finished writing. > > > Public API and Key Messages > > - lock := ReadWriteLock new > - lock criticalRead: aBlock > - lock criticalWrite: aBlock > > Implementation based on two semaphores and readers counter. > > Main difficulty is carefully handle process termination during execution of > critical sections. This problem described in Semaphore>>critical: comment. > Same approach is used here. But synchronisation logic around two semaphores > for reading and writing complicates things very much. No simple way to > decompose logic on multiple methods because information about process > interruption become hidden. > From the Semaphore comment: >> >> The main trick is assignment right before we go into the wait primitive >> (which is not a real send and therefore not interruptable either). So after >> we can check that waiting is happen or not. > > > Tests are implemented only for lock scenarios. No tests for described > termination process cases. It is not really clear how to write it. > I will be appreciate if people review code. Maybe you will suggest > simplifications. It is always difficult to implement concurrent code. > > Best regards, > Denis I don't think /writeIsLocked/ is a good variable name in #criticalWrite: . Even though its a local var, its semantic "feels" object wide. Consider process A enters #criticalWrite and gains the write lock, then process B enters #criticalWrite: where it does "writeIsLocked := false" -- but A still has the lock, so the semantic is confusing. Perhaps renaming to something like "ensureRelease" is more intention revealing. waiting inside the ensure-main-block is interrupted. If B is terminated, then the ensure-block executes Now there is a problem with the logic of #criticalWrite: Consider a scenario where process p1 is holding the writersSemaphore for a long time, and processes p2 and p3 are waiting on it. If p2 is terminated, then its ensure-block executes, which signals writersSemaphore and p3 proceeds prematurely. By way of example, try this... | lock p1 p2 p3| Transcript clear. lock := ReadWriteLock new. p1 := [ Transcript crShow: '1A'. lock criticalWrite: [ Transcript crShow: '1B'. self halt ] ] newProcess name: 'LOCK1' . p2 := [ Transcript crShow: '2A'. lock criticalWrite: [ Transcript crShow: '2B' ] ] newProcess name: 'LOCK2' . p3 := [ Transcript crShow: '3A'. lock criticalWrite: [ Transcript crShow: '3B' ] ] newProcess name: 'LOCK3' . p1 resume. p2 resume. p3 resume. " (1 second wait). p2 terminate. " ...with the last two lines commented, you get the expected result... A1 A2 B1 C1 "Correctly pauses until <Proceed> debugger" B2 C2 ..but if you uncomment the last two lines you get... 1A 1B 2A 3A "whoops, did not pause here until <Proceed> in debugger" 3B You can observe this further by adding the following logging to the top of the ensure block... ] ensure: [ Transcript crShow: writersSemaphore excessSignals ; tab ; show: activeProcess == writeLockOwner ; tab ; show: aBlock. ... So when p2 is terminated, it is no longer waiting on /writersSemaphore/ and thus will not be consuming a signal, so we should avoid signalling it when the process it terminated. One solution might be... criticalWrite: aBlock | activeProcess ensureRelease blockResult| activeProcess := Processor activeProcess. activeProcess == writeLockOwner ifTrue:[ ^aBlock value]. ensureRelease := false. blockResult := [ ensureRelease := true. writersSemaphore wait. writeLockOwner := activeProcess. aBlock value ] ensure: [ "Need to avoid signalling when terminated, since it never consumed a signal" (ensureRelease and: [ activeProcess == writeLockOwner ]) ifTrue: [ writeLockOwner := nil. writersSemaphore signal ]. ]. ^ blockResult Now I was curious why Semaphore>>critical: did not exhibit the same problem, since the following... | lock p1 p2 p3| Transcript clear. lock := Semaphore forMutualExclusion. p1 := [ Transcript crShow: '1A'. lock critical: [ Transcript crShow: '1B'. self halt ] ] newProcess name: 'LOCK1' . p2 := [ Transcript crShow: '2A'. lock critical: [ Transcript crShow: '2B' ] ] newProcess name: 'LOCK2' . p3 := [ Transcript crShow: '3A'. lock critical: [ Transcript crShow: '3B' ] ] newProcess name: 'LOCK3' . p1 resume. p2 resume. p3 resume. (1 second wait). p2 terminate. which produces... 1A 1B 2A 3A "Correctly pauses until <Proceed> debugger" 3B However, if I copy Semaphore to Semaphore2 and do this... | lock p1 p2 p3| Transcript clear. lock := Semaphore2 forMutualExclusion. p1 := [ Transcript crShow: '1A'. lock critical: [ Transcript crShow: '1B'. self halt ] ] newProcess name: 'LOCK1' . p2 := [ Transcript crShow: '2A'. lock critical: [ Transcript crShow: '2B' ] ] newProcess name: 'LOCK2' . p3 := [ Transcript crShow: '3A'. lock critical: [ Transcript crShow: '3B' ] ] newProcess name: 'LOCK3' . p1 resume. p2 resume. p3 resume. (1 second wait). p2 terminate. it produces... 1A 1B 2A 3A "whoops, did not pause here until <Proceed> in debugger" 3B This is really strange! Why does the copied class Semaphore2 behave differently to the original class Semaphore? This was in build 50510. btw I have this growing suspicion that we should eliminate Semaphore>>critical: and Semaphore>>forMutualExclusion. Semaphores on their own should *not* provide a facility for to protect critical regions since they suffer from accidental release [1] due to *lack*of*ownership*. This is the root cause of the problem scenario above. Mutex>>critical: which does have a sense of ownership should be used instead. Indeed, [2] advises "The correct use of a semaphore is for *signaling* from one task to another. A mutex is meant to be taken and released, always in that order, by *[the same]* task that uses the shared resource it protects." -- But this is a subtle distinction and having Semaphore>>critical: leads people to incorrect thinking and exposes them to subtle errors. Mutex>>critical: cold still be implemented using Semaphore, but rather than just forwarding to Semaphore>>critical: pull that method's code out into Mutex>>critical: so it looks like what Denis did for #criticalWrite: Or alternatives, we should consider directly using the mutex primitives Eliot mentioned some time ago were already in the VM. [1] https://blog.feabhas.com/2009/09/mutex-vs-semaphores-%E2%80%93-part-1-semap… [2] http://www.barrgroup.com/Embedded-Systems/How-To/RTOS-Mutex-Semaphore cheers -ben

Jan. 5, 2016

Re: [Pharo-dev] Monitor>>critical: implementation

by Denis Kudriashov

:) 5 ÑÐ½Ð². 2016 Ð³. 2:18 PM Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Max Leske" <maxleske(a)gmail.com> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > > On 05 Jan 2016, at 13:29, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-01-05 12:59 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > >> What I donât quite understand is why Monitor doesnât use >> Semaphore>>critical:. If it did that, then there wouldnât be a problem. The >> problem only exists because #wait and #signal are explicitly sent by the >> monitor. > > > Monitor is reentral which means that two recursive critical sections in > same process should not be blocked. This logic implemented in #enter and > #exit methods > > > I should start using my head again. This is a new yearâ¦ :) > > Thanks Denis. > >

Jan. 5, 2016

Re: [Pharo-dev] Monitor>>critical: implementation

by Max Leske

> On 05 Jan 2016, at 13:29, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-01-05 12:59 GMT+01:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: > What I donât quite understand is why Monitor doesnât use Semaphore>>critical:. If it did that, then there wouldnât be a problem. The problem only exists because #wait and #signal are explicitly sent by the monitor. > > Monitor is reentral which means that two recursive critical sections in same process should not be blocked. This logic implemented in #enter and #exit methods > I should start using my head again. This is a new yearâ¦ :) Thanks Denis.

Jan. 5, 2016

[pharo-project/pharo-core]

by GitHub

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

Jan. 5, 2016

[pharo-project/pharo-core] 37b451: 50511

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 37b4510f6cb328b6f8c46222a65cc445db6d0578 https://github.com/pharo-project/pharo-core/commit/37b4510f6cb328b6f8c46222… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-05 (Tue, 05 Jan 2016) Changed paths: A Athens-Cairo.package/AthensCairoMatrix.class/instance/copying/postCopy.st M Athens-Cairo.package/AthensCairoMatrix.class/instance/private/copyFromMatrix_.st M Athens-Cairo.package/AthensCairoMatrix.class/instance/transformations/restoreAfter_.st A Athens-Cairo.package/AthensCairoMatrixTest.class/README.md A Athens-Cairo.package/AthensCairoMatrixTest.class/definition.st A Athens-Cairo.package/AthensCairoMatrixTest.class/instance/tests/testCopy.st A Athens-Cairo.package/AthensCairoMatrixTest.class/instance/tests/testInverted.st M NativeBoost-Core.package/NativeBoost.class/class/testing/isEnabled.st M Nautilus.package/AbstractNautilusUI.class/instance/icon/classIconFor_.st A SUnit-Core.package/TestCase.class/class/testing/hasTestSelectors.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50510.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50511.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50510.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50511.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-MorphicAdapters.package/MorphicLabelAdapter.class/instance/factory/buildWidget.st Log Message: ----------- 50511 17280 Athens restoreAfter: doesnt work https://pharo.fogbugz.com/f/cases/17280 17308 Only show clickable testIcon for non abstract test classes that has tests https://pharo.fogbugz.com/f/cases/17308 17263 Monkey fails with Exception: PrimitiveFailed: primitive #isEnabled in NativeBoost class failed https://pharo.fogbugz.com/f/cases/17263 17306 MorphicLabelAdapter does not honor initial color https://pharo.fogbugz.com/f/cases/17306 http://files.pharo.org/image/50/50511.zip

Jan. 5, 2016

Re: [Pharo-dev] Monitor>>critical: implementation

by Denis Kudriashov

2016-01-05 12:59 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > What I donât quite understand is why Monitor doesnât use > Semaphore>>critical:. If it did that, then there wouldnât be a problem. The > problem only exists because #wait and #signal are explicitly sent by the > monitor. Monitor is reentral which means that two recursive critical sections in same process should not be blocked. This logic implemented in #enter and #exit methods

Jan. 5, 2016

Re: [Pharo-dev] Monitor>>critical: implementation

by Max Leske

> On 05 Jan 2016, at 13:23, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-01-05 12:59 GMT+01:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: > You may have a point there. Although the monitor uses a Semaphore #forMutualExclusion, which is a semaphore with one signal. So the case where the semaphore gets signalled without #wait is less likely I think. > > No. It has no relation to incorrect scenarios of semaphore signalling. > #forMutualExclusion just make semaphore free to use. So first caller of #wait will grab lock. And others will wait. > Two times signalled semaphore will allow two critical sections be performed simultaneously which should not happen True >

Jan. 5, 2016