- Pharo-dev - lists.pharo.org

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

by Sven Van Caekenberghe

Esteban, Maybe you could extend the job that generates the catalog with a log file that describes what goes wrong and how and then also publish that ? Sven > On 05 Jan 2016, at 18:39, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Hi Esteban, > > Something weird: Woden contains the catalog information. Version 41 of ConfigurationOfWoden contains the 3 catalog methods. For pharo 5 > > Any idea what happened? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Jan 5, 2016, at 12: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' >> >> >

Jan. 5, 2016

Re: [Pharo-dev] small refactor on files.pharo.org

by Andrei Chis

Thanks. Makes sense. Cheers, Andrei On Tue, Jan 5, 2016 at 7:22 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 05 Jan 2016, at 19:14, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > What's the recommended way of loading the VM through zeroconf scripts? > > Just http://get.pharo.org/vm loads the non-spur vm and > http://get.pharo.org/vm50 loads the spur one. Will http://get.pharo.org/vm > be updated to the spur one in the future? > > > Hi, > > no it will not be updated. > In fact if you see is not listed anymore (since almost one year now). It > is just there for backward compatibility. > > you need to use the VM corresponding with your image version (in case of > Pharo 50, vm50). > > Esteban > > ps: this was described when I made the change like one year agoâ¦ but now I > do not find the mail :P > > > Cheers, > Andrei > > On Tue, Jan 5, 2016 at 11:47 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> I move old VMs from files.pharo.org/vm to files.pharo.org/vm/old >> >> because it was confusing and some students were lost (Stef too :P). >> >> cheers, >> Esteban >> > > >

Jan. 5, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Denis Kudriashov

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

Jan. 5, 2016

Re: [Pharo-dev] small refactor on files.pharo.org

by Esteban Lorenzano

> On 05 Jan 2016, at 19:14, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > What's the recommended way of loading the VM through zeroconf scripts? > > Just http://get.pharo.org/vm <http://get.pharo.org/vm> loads the non-spur vm and http://get.pharo.org/vm50 <http://get.pharo.org/vm50> loads the spur one. Will http://get.pharo.org/vm <http://get.pharo.org/vm> be updated to the spur one in the future? Hi, no it will not be updated. In fact if you see is not listed anymore (since almost one year now). It is just there for backward compatibility. you need to use the VM corresponding with your image version (in case of Pharo 50, vm50). Esteban ps: this was described when I made the change like one year agoâ¦ but now I do not find the mail :P > > Cheers, > Andrei > > On Tue, Jan 5, 2016 at 11:47 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > I move old VMs from files.pharo.org/vm <http://files.pharo.org/vm> to files.pharo.org/vm/old <http://files.pharo.org/vm/old> > > because it was confusing and some students were lost (Stef too :P). > > cheers, > Esteban >

Jan. 5, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Denis Kudriashov

2016-01-05 18:15 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > But Semaphore>>forMutualExclusion *encourages* people to believe > semaphores can be used *on*their*own* for mutual exclusion, when they > *shouldn't*. You *must* add ownership. If the mutual exclusion > object doesnât have ownership then, irrelevant of what it is called, > it is not a mutex!!! [1]. > > "Strictly speaking [2]... > -- A mutex is *locking* mechanism used to synchronize access to a > resource. Only one task (can be a thread or process based on OS > abstraction) can acquire the mutex. It means there is *ownership* > associated with mutex, and only the owner can release the lock > (mutex). > -- A semaphore is *signaling* mechanism (âI am done, you can carry > onâ kind of signal). For example, if you are listening songs (assume > it as one task) on your mobile and at the same time your friend calls > you, an interrupt is triggered upon which an interrupt service routine > (ISR) signals the call processing task to wakeup > > > >It is common case that semaphore "free" by default. > > With an implementation like.. > Semaphore>>forMutualExclusion > ^self new signal > > we don't gain a lot, and its a misleading convenience method since its > doesn't provide the proper facility for mutual exclusion (and I do > conflate mutual exclusion == mutex). Indeed, "Semaphore > forMutualExclusion + roll your ownership management + problems since > you weren't aware you needed to roll your own ownership management" is > not more convenient than "Mutex new" > > If you want to keep a convenience method for a pre signalled > Semaphore, then we could provide something like "Semaphore > newSignalled" > > > And this name is explicitly said about this. > > Actually no. It explicitly says it provides mutual exclusion - which > without ownership, it does not. It only implicitly provides a > pre-signalled Semaphore - you have to *know* of look at the source. > Ok Ben. I got it. Thank's for detailed explanation. It makes sense. I will prepare slice with your proposed changes. We will make Semaphore>>critical: and #forMutualExclusion deprecated (if nobody against it).

Jan. 5, 2016

Re: [Pharo-dev] small refactor on files.pharo.org

by Andrei Chis

What's the recommended way of loading the VM through zeroconf scripts? Just http://get.pharo.org/vm loads the non-spur vm and http://get.pharo.org/vm50 loads the spur one. Will http://get.pharo.org/vm be updated to the spur one in the future? Cheers, Andrei On Tue, Jan 5, 2016 at 11:47 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > I move old VMs from files.pharo.org/vm to files.pharo.org/vm/old > > because it was confusing and some students were lost (Stef too :P). > > cheers, > Esteban >

Jan. 5, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Henrik Johansen

> On 05 Jan 2016, at 5:25 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > I found problem. Look at Process>>terminate. There is special place: > > "Figure out if we are terminating the process while waiting in Semaphore>>critical: > In this case, pop the suspendedContext so that we leave the ensure: block inside > Semaphore>>critical: without signaling the semaphore." > (oldList class == Semaphore and: [ > self halt. > suspendedContext method == (Semaphore compiledMethodAt: #critical:) ]) ifTrue: [ > suspendedContext := suspendedContext home ]. > > Really crazy. Comment inside #critical: method said that we should signal in any case. But #terminate method said that we should not allow signalling in that case. > Why it is not implemented inside #critical: method by #ifCurtailed: logic? 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... There are only two cases: - Have I been unblocked by the semaphore? (IE, have I consumed a signal?) Then, signal when exiting section (whether through normal execution, termination, or an unhandled error). - Has it not? Then, do not signal. Here, there are two subcases - I have entered the section that will unwind in the ensure: block, but am not yet waiting for Semaphore. (handled by caught variable) - I have started waiting for semaphore, but not consumed a signal. (handled by #terminate). The last bit is potentially really tricky, if the callback code in suspend is actually used, and is not performed atomically. (Strangely, a haltOnce in the suspend fallback code *did* trigger for me, despite the comment that it is purely for old VM's) If the terminating process is interrupted on the remove:ifAbsent: call (which could/should be removeLink:ifAbsent:, btw) by a thread signalling its semaphore, and the semaphore selects the process being terminated as the one to resume, but terminating thread is resumed before terminated (which is no longer *really* suspended), the fallback code will happily return the (now no longer really suspended) semaphore it recorded before removeLink:ifAbsent: call. The terminating process then checks that it is indeed a semaphore, and that the terminating threads suspendedContext is still the critical call, and promptly decides to not signal the semaphore as part of termination. The net result of which, would be an entered critical section without a corresponding exit, and a hung semaphore until someone feeds it a few extra signals, if we're talking input semaphore, say, by wiggling the mouse a bit or something... Sound familiar to anyone? A possible fix would be changing: oldList remove: self ifAbsent: [] to oldList removeLink: self ifAbsent:[oldList := nil] In other words. if someone (ie, the waiting list ) has removed a thread from the old waiting list before the thread was able to do it, don't just proceed as if nothing has happened, but consider the terminated thread as no longer having on the old waiting list at the time of suspension. Then, terminate will find a nil oldList (whose class is not Semaphore), and the ensure: block will execute as the semaphore expects. Combined with the suggesting in preceeding mail, that would mean not doing the checks in terminate, but #cull:'ing the oldList into ensure contexts during unwind. Cheers, Henry Timeline: [Terminating Thread] Wanting to terminate a victim thread, it tries to suspend it. [Terminating Thread] Suspend call records the oldList (semaphore) victim is currently blocked on , then is interrupted at the remove:ifAbsent: call. [Signalling Tread] Signals the semaphore [Signalling Tread] Semaphore decides to resume the victim thread. Primitive removes it from list, and readies it for resumption. [Signalling Tread yields, expecting a signal from victim thread when it is done] [Terminating Thread resumed] [Terminating Tread] Checks oldList and suspendedContext, find them both satisfying its check for whether the victim was waiting for a semaphore, and pops the ensure block

Jan. 5, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Ben Coman

On Wed, Jan 6, 2016 at 12:30 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On 05 Jan 2016, at 5:10 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-01-05 16:54 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >> 2016-01-05 16:06 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >>> >>> This is really strange! Why does the copied class Semaphore2 behave >>> differently to the original class Semaphore? This was in build 50510. >> >> >> It is so frustrating. >> I add tests for your cases which is red now. And one for Semaphore (inside >> ReadWriteLockTests) which is green > > > It is really crazy. I just try two experiments: > 1) I move semaphore critical: logic to Mutex. Our test with mutex become > red. > 2) I copy Semaphore>>critical: to #critical2:. And with it Semaphore test > become red. After Semaphore to Semaphore2 and running my test case above showing its bad terminate behaviour without the special handling in Process>>terminate, I then copied Mutex to Mutex2 and made the following mod... Mutex2>>initiialize super initialize. semaphore := Semaphore2 forMutualExclusion. such that my test case with lock := Mutex2 new. also showed the bad terminate behaviour. But then copying Mutex2 to Mutex3 with the following mod to replace the call to Semaphore>>critical:... Mutex3>>critical: aBlock "Evaluate aBlock protected by the receiver." | activeProcess ensureRelease blockResult| activeProcess := Processor activeProcess. activeProcess == owner ifTrue:[^aBlock value]. ensureRelease := false. blockResult := [ ensureRelease := true. semaphore wait. owner := activeProcess. aBlock value ] ensure: [ (ensureRelease and: [ activeProcess == owner ]) ifTrue: [ owner := nil. semaphore signal ] ]. ^blockResult and my test case with lock := Mutex3 new. works fine . So again I push that Semaphore>critical: is *bad*. > > So somebody definitely know about #critical: selector and it receiver #critical: is mutual exclusion, thus a Mutex, not a Semaphore. > > > Yes, check Process >> #terminate, there's special code for skipping a > context if the suspended process was waiting for Semaphore. Well spotted. > > The way I see it, the purpose of the caught variable in Semaphore is to not > execute the ensure: if the process was suspended (and then terminated)*in* > the ensure: method, before block ever executes and one starts waiting on the > semaphore. > > If one has made it to the wait call, caught is already true, and the ensure > block would be executed on termination unwind.. > That part is, as I said above, handled directly in Process >> #terminate > (near the bottom) > AFAICT, both parts would be need to be reflected for Monitor >> #critical: > to work correctly under termination. > At which point, it would seem to me a better idea (if possible) if the > terminated context was culled into the ensure block, instead of muddying up > Process >> #terminate further, one could then write a few ugly, but > localized: > ensure: [:unwoundContext | (caught and: [unwoundContext isWaitContext notl]) > ifTrue: [sem signal]] > instead of having to keep adding special case handling to Process >> > #terminate. > > Cheers, > Henry Simply, if we eliminate Semaphore>>critical: then of course no special processing is required in Process>>terminate. I suggest that after a bit of review and testing, all we'll need is Mutex3>>critical: described above. cheers -ben

Jan. 5, 2016

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

by Alexandre Bergel

Hi Esteban, Something weird: Woden contains the catalog information. Version 41 of ConfigurationOfWoden contains the 3 catalog methods. For pharo 5 Any idea what happened? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jan 5, 2016, at 12: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' > >

Jan. 5, 2016

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

by Esteban A. Maringolo

2016-01-05 13:35 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: > I happen to know quite a number of projects. > > So, what's the best path to follow to put a description in them? > > Editing configs and saving to MetaRepo is not an issue but will put my name > all over upon save, which is not really nice to people making the work. > > I can spend a couple hours on it this week. I wouldn't mind if you put your name in any of my repos, please let me know if you need write access. I tried to copy a Config to the MetaRepoForPharo40 and got a MCPermissionDenied error. My user and pass are okay because I could upload the package to my STHub repo before. Regards! Esteban A. Maringolo

Jan. 5, 2016