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

Re: [Pharo-dev] [Ann] ReadWriteLock

by Ben Coman

okay. I'll have a go. cheers -ben On Wed, Jan 6, 2016 at 3:28 AM, stepharo <stepharo(a)free.fr> wrote: > Ben > > would you not be interested to write a little chapter on concurrency because > we would all benefit from it. > I can help but I'm pretty bad with concurrency. > I'm sure that doing that we will find a lot of things to improve in Pharo :) > > Stef > > Le 5/1/16 18:15, Ben Coman a Ã©crit : > >> On Tue, Jan 5, 2016 at 11:59 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >>> >>> 2016-01-05 16:06 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >>>> >>>> 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*. >>> >>> >>> I have same feeling when analyse problem of critical: implementation. But >>> I >>> not think that Semaphore>>forMutualExclusion is bad. >> >> 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. >> >> [1] >> https://blog.feabhas.com/2009/09/mutex-vs-semaphores-%E2%80%93-part-2-the-m… >> [2] http://www.geeksforgeeks.org/mutex-vs-semaphore/ >> >> cheers -ben >> >> > >

Jan. 5, 2016

Re: [Pharo-dev] context mirror primitives

by Tudor Girba

Ok. No problem. Please let me know if I can help. Doru > On Jan 5, 2016, at 10:04 PM, stepharo <stepharo(a)free.fr> wrote: > > All the Inria integration got a problem and this is restarting to work. > So we will get there. > > Stef > > Le 5/1/16 20:38, Tudor Girba a Ã©crit : >> Hi, >> >> In summary, it seems we should integrate this one. >> >> I resolved the issue to "Resolved (Fix Review Needed)â, but it seems that the Monkey is still on holidays :). Does anyone know if there is a problem with it? >> >> Cheers, >> Doru >> >> >>> On Jan 4, 2016, at 5:42 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Hi, >>> >>> The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo: >>> >>> object: anObject basicAt: index >>> object: anObject basicAt: index put: value >>> object: anObject eqeq: anOtherObject >>> object: anObject instVarAt: anIndex >>> object: anObject instVarAt: anIndex put: aValue >>> object: anObject perform: selector withArguments: argArray inClass: lookupClass >>> objectClass: anObject >>> objectSize: anObject >>> >>> I added an issue and the slice: >>> https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context >>> >>> As I note in the issue, I think it is certainly interesting to have a more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides. >>> >>> I would like to use these primitives now to make the GT Inspector and Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods? >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Problem solving efficiency grows with the abstractness level of problem understanding." >>> >>> >>> >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "We are all great at making mistakes." >> >> >> >> >> >> >> >> >> >> > > -- www.tudorgirba.com www.feenk.com "When people care, great things can happen."

Jan. 5, 2016

Re: [Pharo-dev] context mirror primitives

by stepharo

All the Inria integration got a problem and this is restarting to work. So we will get there. Stef Le 5/1/16 20:38, Tudor Girba a Ã©crit : > Hi, > > In summary, it seems we should integrate this one. > > I resolved the issue to "Resolved (Fix Review Needed)â, but it seems that the Monkey is still on holidays :). Does anyone know if there is a problem with it? > > Cheers, > Doru > > >> On Jan 4, 2016, at 5:42 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo: >> >> object: anObject basicAt: index >> object: anObject basicAt: index put: value >> object: anObject eqeq: anOtherObject >> object: anObject instVarAt: anIndex >> object: anObject instVarAt: anIndex put: aValue >> object: anObject perform: selector withArguments: argArray inClass: lookupClass >> objectClass: anObject >> objectSize: anObject >> >> I added an issue and the slice: >> https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context >> >> As I note in the issue, I think it is certainly interesting to have a more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides. >> >> I would like to use these primitives now to make the GT Inspector and Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Problem solving efficiency grows with the abstractness level of problem understanding." >> >> >> >> > -- > www.tudorgirba.com > www.feenk.com > > "We are all great at making mistakes." > > > > > > > > > >

Jan. 5, 2016

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

by Esteban Lorenzano

> On 05 Jan 2016, at 20:06, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > but this still works as expected yes ? > > wget -O- get.pharo.org/alpha+vmLatest <http://get.pharo.org/alpha+vmLatest> | bash yes > > > > On Tue, Jan 5, 2016 at 8:23 PM Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> On 05 Jan 2016, at 19:14, Andrei Chis <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@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

Process/Delay waiting on multiple Semaphores at once?

by Holger Freyther

Hi, I look into a way to implement something like Erlang's selective process by having Delay or something like it wait on multiple Semaphores (and maybe blocks in the future but that leads the question of side-effects if the event is not used) and fire on the first one ready without having to deal with many Processes. The usecases I have in mind right now are: * Wait for a delivery time or if any new work has come up * When connecting a call (e.g. two SIP calls) I want to manage the state from a central place (e.g. like an event inbox) and dispatch events from the same context and I do not know which side the event occurs. SelectiveReceive new check: database readableSemaphore do: [ev := self nextDatabaseEvent]; check: file readableSemaphore do: []; timeoutDo: []; runFor: 30 seconds. A prototype to get a feel for the API could be built by spawning n-processes that each wait on their own semaphore for the timeout and then create another semaphore that is signalled by these processes in case of a wakeup signal the new Semaphore and then in the runFor: selector kill all remaining processes.. What do you think of this pattern instead of having to deal with concurrency with more locking, more fine grained locking? What would it take to get this deeper into Pharo? I think fundamentally a Process would need to be able to sleep on a list of semaphores? Is that feasible? kind regards holger

Jan. 5, 2016

Re: [Pharo-dev] context mirror primitives

by Tudor Girba

Hi, In summary, it seems we should integrate this one. I resolved the issue to "Resolved (Fix Review Needed)â, but it seems that the Monkey is still on holidays :). Does anyone know if there is a problem with it? Cheers, Doru > On Jan 4, 2016, at 5:42 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo: > > object: anObject basicAt: index > object: anObject basicAt: index put: value > object: anObject eqeq: anOtherObject > object: anObject instVarAt: anIndex > object: anObject instVarAt: anIndex put: aValue > object: anObject perform: selector withArguments: argArray inClass: lookupClass > objectClass: anObject > objectSize: anObject > > I added an issue and the slice: > https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context > > As I note in the issue, I think it is certainly interesting to have a more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides. > > I would like to use these primitives now to make the GT Inspector and Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods? > > Cheers, > Doru > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > -- www.tudorgirba.com www.feenk.com "We are all great at making mistakes."

Jan. 5, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by stepharo

Ben would you not be interested to write a little chapter on concurrency because we would all benefit from it. I can help but I'm pretty bad with concurrency. I'm sure that doing that we will find a lot of things to improve in Pharo :) Stef Le 5/1/16 18:15, Ben Coman a Ã©crit : > On Tue, Jan 5, 2016 at 11:59 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> 2016-01-05 16:06 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >>> 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*. >> >> I have same feeling when analyse problem of critical: implementation. But I >> not think that Semaphore>>forMutualExclusion is bad. > 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. > > [1] https://blog.feabhas.com/2009/09/mutex-vs-semaphores-%E2%80%93-part-2-the-m… > [2] http://www.geeksforgeeks.org/mutex-vs-semaphore/ > > cheers -ben > >

Jan. 5, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by stepharo

This code looks quite bad to me. Le 5/1/16 17:25, Denis Kudriashov a Ã©crit : > 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? > > > 2016-01-05 17:10 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com > <mailto:dionisiydk@gmail.com>>: > > > 2016-01-05 16:54 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com > <mailto:dionisiydk@gmail.com>>: > > 2016-01-05 16:06 GMT+01:00 Ben Coman <btc(a)openinworld.com > <mailto:btc@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. > > So somebody definitely know about #critical: selector and it receiver > >

Jan. 5, 2016

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

by stepharo

Thanks for this help. Stef Le 5/1/16 19:51, Alexandre Bergel a Ã©crit : > By the way, There is an help included in the base image. > I have just submitted a slice that indicates the catalog methods have > to be on the class side. > > Cheers, > Alexandre > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Jan 5, 2016, at 3:35 PM, Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>> wrote: >> >> >>> On 05 Jan 2016, at 19:32, Sven Van Caekenberghe <sven(a)stfx.eu >>> <mailto:sven@stfx.eu>> wrote: >>> >>> 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 ? >> >> I have a log, but it will not have much information that you can use. >> For example, in case of Alex problem, it would say: no catalog >> methods found. Witch is more or less what we already know :) >> >> Esteban >> >>> >>> Sven >>> >>>> On 05 Jan 2016, at 18:39, Alexandre Bergel <alexandre.bergel(a)me.com >>>> <mailto:alexandre.bergel@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 <mailto:estebanlm@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 stepharo

We also added a PreSpur description on the donwload so that in case of emergency people can find the latest prespur image with the VM Le 5/1/16 11:47, Esteban Lorenzano a Ã©crit : > 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