- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 5986a6: 50513

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 5986a695fb28834247a90dbf85c0d1e02a54b6fc https://github.com/pharo-project/pharo-core/commit/5986a695fb28834247a90dbf… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-06 (Wed, 06 Jan 2016) Changed paths: A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/README.md A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/class/accessing/project.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/class/development support/DevelopmentSupport.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/class/development support/validate.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/class/loading/load.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/class/loading/loadBleedingEdge.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/class/loading/loadDevelopment.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/class/metacello tool support/isMetacelloConfig.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/class/private/baseConfigurationClassIfAbsent_.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/class/private/ensureMetacello.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/class/private/ensureMetacelloBaseConfiguration.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/definition.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/instance/accessing/customProjectAttributes.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/instance/accessing/project.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/instance/baselines/baseline0%5F9_.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/instance/external projects/alien_.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/instance/external projects/ffi_.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/instance/symbolic versions/development_.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/instance/symbolic versions/stable_.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/instance/versions/v0%5F9%5F0_.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/instance/versions/v0%5F9%5F1_.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/instance/versions/v0%5F9%5F2_.st A FFI-NB-Legacy.package/extension/Object/instance/nbCall_module_options_.st A FFI-NB-Legacy.package/extension/Object/instance/nbCall_options_.st R FFI-NB-Tests.package/FFICalloutObjectForTest.class/class/converting/asNBExternalType_.st A FFI-NB-Tests.package/FFICalloutTests.class/instance/tests/testParseOptions.st M FFI-NB.package/FFICallout.class/definition.st A FFI-NB.package/FFICallout.class/instance/accessing/optionAt_.st A FFI-NB.package/FFICallout.class/instance/accessing/options.st A FFI-NB.package/FFICallout.class/instance/accessing/options_.st A FFI-NB.package/FFICallout.class/instance/accessing/parseOptions_.st M FFI-NB.package/FFICallout.class/instance/argument loaders/indirectLoader_byIndex_.st A FFI-NB.package/FFICallout.class/instance/initialization/initialize.st M FFI-NB.package/FFICalloutMethodBuilder.class/instance/accessing/createFFICallout.st M FFI-NB.package/FFIExternalStructure.class/class/accessing/structureSize.st R FFI-NB.package/FFIFunctionSpec.class/class/instance creation/namedFunctionFrom_.st R FFI-NB.package/FFISizeT.class/class/converting/asNBExternalType_.st A FFI-NB.package/extension/OSPlatform/instance/ffiAlignment.st A FFI-NB.package/extension/Win32Platform/instance/ffiAlignment.st R NativeBoost-Core.package/extension/Object/instance/nbCall_module_options_.st R NativeBoost-Core.package/extension/Object/instance/nbCall_options_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50512.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50513.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50512.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50513.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-Base.package/extension/SystemNavigation/instance/confirmRemovalOfSelectors_on_.st M Traits.package/TClass.class/instance/copying/duplicateClassWithNewName_.st Log Message: ----------- 50513 17312 VM crash when using Athens + FreeType in Windows https://pharo.fogbugz.com/f/cases/17312 17317 Simplify line 8 in TClass>>#duplicateClassWithNewName: https://pharo.fogbugz.com/f/cases/17317 17318 Multi deletion of methods do not work anymore https://pharo.fogbugz.com/f/cases/17318 http://files.pharo.org/image/50/50513.zip

Jan. 6, 2016

Re: [Pharo-dev] [Pharo-users] [ANN] The next Pharo Sprints (Lille)

by Juraj Kubelka

Hi, thatâs great. We will organize Pharo Sprint in Santiago at the same time except of February (vacations). Cheers, Juraj > On Jan 6, 2016, at 04:27, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hello, > > We looked at the calendar and fixed the dates for all public sprints that we will do this > year here locally. These are all Fridays: > > 29 Januar > 26 Feb > 25 March > 29 April > 27 May > > They will be at the Inria Lille, Building B, third floor (RMoD offices). > Remotely, you can join us on Slack or the IRC channel #pharo on > irc.freenode.net server. During the sprint, we will try to synchronize > local and remote Pharo sprinters. > > One nice idea is to organise local sprints yourself. E.g. over the last > sprints we had one in Chile at the same time. > > Marcus > > >

Jan. 6, 2016

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

by Pierce Ng

On Tue, Jan 05, 2016 at 04:21:37PM +0100, Esteban Lorenzano wrote: > 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. Done for NBSQLite3 for Pharo 4. Will update accordingly for v5 and v3. Thanks for pushing. Pierce >

Jan. 6, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Denis Kudriashov

I publish slice with MutexTest. So future changes around all this will be verified by CI 2016-01-06 14:32 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 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 Denis Kudriashov

2016-01-06 14:32 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 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. > And I don't know how to fix it inside critical method.

Jan. 6, 2016

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