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

How to compile Spur VM in Windows?

by HernÃ¡n Morales Durand

Hello I am trying to compile Spur VM in Windows 8.1. As far as I understand Spur VM needs the Pharo 5.0 image format, is that right? Apparently instructions here https://github.com/pharo-project/pharo-vm/blob/master/README-Win32-fasttrac… are only applicable to "Old VM" in Pharo 3.0 Does anyone have any idea how to clone/compile the Spur VM (i.e. Pharo 5.0) ? Cheers, HernÃ¡n

Jan. 6, 2016

Atomic commits

by Nicolas Cellier

Hi, I wish the commits were much more atomic than they currently are... With current practice, reviewing the changes is near to impossible: - it requires far too much concentration - it's just impossible through github web interface For example, I did wander if the structure fields were correclty aligned in: https://github.com/pharo-project/pharo-core/blame/5986a695fb28834247a90dbf8… because I see no code for aligning the offsets... But I cannot even navigate in the history... If I do so, https://github.com/pharo-project/pharo-core/commit/dfd4f3ae0f0b0af7766c1405… the page tells me "Sorry, we could not display the entire diff because too many files (2,121) changed" and I couldn't find a way of displaying the portion of interest. I thus loose the ability to deposit a comment. I can still open a fresh Pharo image and browse and review the whole code snapshot there. Or I can navigate more easily in history with git tools. But if I wanted a lightweight review thru web, focusing on the diffs and navigating a bit in history without replicating the repository, I can't. While ranting, it's nice to have the commits performed by a jenkins server, but how do we track the authors of original modifications? In a normal git based development, there would be feature branches integrated/merged in trunk/master by whatever process. But in current process i fail to capture such information... This gives a taste of under-powered use of the tools, and I wander if being visible in these conditions is a good thing: we don't expose the best practices.

Jan. 6, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Denis Kudriashov

I realize that current approach to handle situation in the #terminate method is the only way. But we need to generalize it somehow and make more explicit. It should be visible inside method which required such logic (like current Semaphore>>critical:). You suggest something like culling unwind context to ensure method. But it looks like too radical solution. And it is not easy to implement. Cant we implement Semaphore>>waitIfInterrupted: interruptingBlock? And we put in terminating logic only this knowledge. Terminate method should detect this method and call interruptingBlock . So clients can set simple flag in such cases that lock was not acquired. For example: critical: aBlock [signalRequired := true. semaphore waitIfInterrupted: [signalRequired := false]. ^aBlock value] ensure: [signalRequired ifTrue: [semaphore signal]] What you think? 2016-01-06 14:48 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 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] [Pharo-users] [ANN] The next Pharo Sprints (Lille)

by Marcus Denker

Very nice! I will put a news entry on pharo.org <http://pharo.org/> with the dates. Marcus > On 06 Jan 2016, at 15:24, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > > 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

[pharo-project/pharo-core]

by GitHub

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

Jan. 6, 2016

[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