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

Re: [Pharo-dev] last opened window does not go away

by Andrei Chis

We checked again and with the Spur VM all the strange memory leaks that we had with the GLMSystemWindow/Inspector/Playground seem to have disappeared (for now :) ) Cheers, Andrei On Mon, Nov 16, 2015 at 3:52 PM, Henrik Nergaard <henrin10(a)student.uia.no> wrote: > The RubFindReplaceDialogWindow is made and held by RubFindReplaceService > ivar dialog. There is also the ivar textAreaHolder which holds the active > text area. When setting this variable from #textArea: an announcement is > created for the textArea to the RubFindReplaceService, this should probably > be a weak one. > > I think the main issue is that the textArea instance variable is not > cleared from RubFindReplaceService when it is deleted. > > > > There is also announcements linked to RubFindReplaceService made by: > RubAbstractTextArea>>#plugFindReplace. I guess these announcements should > be weak. > > > > Hope this helps, > > Best regards, > > Henrik > > > > *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf > Of *Andrei Chis > *Sent:* Monday, November 16, 2015 3:23 PM > *To:* Discusses Development of Pharo <pharo-dev(a)lists.pharo.org> > *Subject:* [Pharo-dev] last opened window does not go away > > > > Hi, > > > > In the latest Pharo image there is a rogue instance of GLMSystemWindow. > > If I do in the console the following code I get one instance: > > > > /pharo Pharo.image eval "GLMSystemWindow allInstances" > > an Array(a GLMSystemWindow(58720256)) > > > > There are actually two windows, but one is RubFindReplaceDialogWindow and > it should have no link with the glamour window. > > > > ./pharo Pharo.image eval "SystemWindow allSubInstances" > > an OrderedCollection(a RubFindReplaceDialogWindow(534511616) a > GLMSystemWindow(58720256)) > > > > If I create another window that contains a morph that can take the focus > then the glamour window disappears and the new window stays: > > > > ./pharo Pharo.image eval "(PluggableTextMorph on: ' ' text: nil accept: > nil) openInWindow close. Smalltalk garbageCollect. SystemWindow > allSubInstances" > > an OrderedCollection(a SystemWindow(234094592) an > EditorFindReplaceDialogWindow(130547712)) > > > > Any idea if the find-replace service from rubric/textmorph holds one > somehow to the last opened window or if there is another global cache that > does it? > > > > Cheers, > > Andrei >

Jan. 6, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Ben Coman

On Thu, Jan 7, 2016 at 1:48 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 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? I'm not qualified to judge, but is sounds okay. I have an alternative proposal to consider that hopefully might remove Semaphore handling completely from Process>>terminate. What if we have a wait primitive that instead of returning itself (i.e. a Semaphore), it always returns true. Then if the process is terminated while the primitive is waiting, before it consumes a signal, the assignment to signalConsumed never occurs. Then we have... critical: mutuallyExcludedBlock signalConsumed := false. [ signalConsumed := self primWaitSucceeded. blockValue := mutuallyExcludedBlock value ] ensure: [ signalConsumed ifTrue: [self signal] ]. ^blockValue It *feels* more atomic. Someone knowledgeable with the vm would need to advise whether after the primitive wakes up and consumes a signal, the assignment into signalConsumed can be guaranteed to occur before the process gets a chance to terminate, even if the primitive needs to directly poke the value into signalConsumed. Maybe the following alternative would be required... critical: mutuallyExcludedBlock signalConsumed := false. [ self primWaitSucceeded: signalConsumed. blockValue := mutuallyExcludedBlock value ] ensure: [ signalConsumed ifTrue: [self signal] ]. ^blockValue but I think my first proposal reads better. OR.... we could have a primitive similar to ensure: ensure: | complete returnValue | <primitive: 198> returnValue := self valueNoContextSwitch. complete ifNil:[ complete := true. aBlock value ]. ^ returnValue where I guess the primitive manipulates local variable "complete" (??). Then it could set that based on whether the primitive consumed a signal or not... afterWaitSucceedsEnsure: aBlock | completeAndNeedSignal mutuallyExcludedValue | <primitive: 198b > mutuallyExcludedValue := self valueNoContextSwitch. completeAndNeedSignal ifNil:[ completeAndNeedSignal := true. aBlock value. ]. ^ mutuallyExcludedValue Then we could just have critical: mutuallyExcludedBlock mutuallyExcludedBlock afterWaitSucceedsEnsure: [ self signal ]. but I still like my first proposal better. cheers -ben > > > 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] [Vm-dev] How to compile Spur VM in Windows?

by HernÃ¡n Morales Durand

Hola Esteban :) As suggested, I am using sources from https://ci.inria.fr/pharo/view/VM/job/PharoVM/Architecture=32,Slave=vm-buil… I have some questions: 1) The sources.tgz file in CI already includes the generated C code (in src/ directories) and CMake files (in build/ directories) ? So for checking the build it would not be necessary to evaluate "PharoVMBuilder buildWin32". 2) Just out of curiosity, VMMakerTool is usable these days? 3) I evaluated : PharoVMBuilder buildWin32. and received a lot of warnings (conflicting return types, undeclareds, etc) in Transcript - attached - Is this expected or should I try to update PharoVMMaker? And if so, from where? HernÃ¡n 2016-01-06 16:08 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > btw you might be able to build SpurVM using an old non-spur Pharo 5.0 > imageâ¦ not sure, but I do not see a reason why you couldnât :) > > Esteban > > > On 06 Jan 2016, at 20:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > https://github.com/estebanlm/pharo-vm/tree/spur64 > > because I still do not merge with master > instructions should work, but right now you WILL NOT be able to build a > VM, because there is a bug in OpalCompiler who prevents building the VM in > spur imagesâ¦ and probably there are other issues, I couldnât test further. > > So I would say you need to wait until I can restore the builds here: > https://ci.inria.fr/pharo/view/5.0-VM-Spur/job/PharoVM-spur32/ > > (itâs been almost one month since I cannot build :( ) > > Esteban > > > On 06 Jan 2016, at 19:33, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > wrote: > > 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

Re: [Pharo-dev] What is the current status of flow (flow-stack)?

by sebastian＠flowingconcept.com

Hi Erik, 2015 was a Smalltalk-sabbatical year for me Erik, that's one of the reasons why as you see in the github commits, development has not moved further. But to be honest there is more, the direction of Amber doesn't look too exciting to me because in the end, the frontend productivity output is not convincing me anymore. In the frontend/Smalltalk world this is way more interesting than Amber: https://bertfreudenberg.github.io/SqueakJS/ But I after the initial modest interest on flow-stack, the reality check of the lack of strong commercial projects on it made it stall. Maintaining a framework is not a small thing. Not being backed is a no-no. But it's all MIT so anyone can take over and give it life on its own if found valuable. BTW I'm currently quite happy with Meteor myself. Feel free to ask anything -- View this message in context: http://forum.world.st/What-is-the-current-status-of-flow-flow-stack-tp48696… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 6, 2016

What is the current status of flow (flow-stack)?

by Erik Stel

Hi, What is the status of flow? Having worked on a Meteor project I got the idea this would be nice to have such a platform/stack in Pharo/Amber combo (back-end/front-end). Searched the web and found https://github.com/flow-stack/flow <https://github.com/flow-stack/flow> . No updates for several months. Sebastian's host (and therefore email) are no longer online. What is the status of flow? Anyone used it for (demo) projects? Anyone interested in working on this in the future? Cheers, Erik -- View this message in context: http://forum.world.st/What-is-the-current-status-of-flow-flow-stack-tp48696… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 6, 2016

Re: [Pharo-dev] [Vm-dev] How to compile Spur VM in Windows?

by Esteban Lorenzano

btw you might be able to build SpurVM using an old non-spur Pharo 5.0 imageâ¦ not sure, but I do not see a reason why you couldnât :) Esteban > On 06 Jan 2016, at 20:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > https://github.com/estebanlm/pharo-vm/tree/spur64 <https://github.com/estebanlm/pharo-vm/tree/spur64> > > because I still do not merge with master > instructions should work, but right now you WILL NOT be able to build a VM, because there is a bug in OpalCompiler who prevents building the VM in spur imagesâ¦ and probably there are other issues, I couldnât test further. > > So I would say you need to wait until I can restore the builds here: https://ci.inria.fr/pharo/view/5.0-VM-Spur/job/PharoVM-spur32/ <https://ci.inria.fr/pharo/view/5.0-VM-Spur/job/PharoVM-spur32/> > > (itâs been almost one month since I cannot build :( ) > > Esteban > > >> On 06 Jan 2016, at 19:33, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>> wrote: >> >> 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… <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

Re: [Pharo-dev] [Vm-dev] How to compile Spur VM in Windows?

by Esteban Lorenzano

https://github.com/estebanlm/pharo-vm/tree/spur64 <https://github.com/estebanlm/pharo-vm/tree/spur64> because I still do not merge with master instructions should work, but right now you WILL NOT be able to build a VM, because there is a bug in OpalCompiler who prevents building the VM in spur imagesâ¦ and probably there are other issues, I couldnât test further. So I would say you need to wait until I can restore the builds here: https://ci.inria.fr/pharo/view/5.0-VM-Spur/job/PharoVM-spur32/ <https://ci.inria.fr/pharo/view/5.0-VM-Spur/job/PharoVM-spur32/> (itâs been almost one month since I cannot build :( ) Esteban > On 06 Jan 2016, at 19:33, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > 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… <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

[pharo-project/pharo-core] 8b9961: 50514

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 8b99613760ca021c77583a66cc1e3c6ca8b0d064 https://github.com/pharo-project/pharo-core/commit/8b99613760ca021c77583a66… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-06 (Wed, 06 Jan 2016) Changed paths: M ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/instance/symbolic versions/development_.st M ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/instance/symbolic versions/stable_.st A ConfigurationOfFFINB.package/ConfigurationOfFFINB.class/instance/versions/version093_.st M FFI-NB.package/FFICallout.class/instance/accessing/sender_.st M FFI-NB.package/FFICallout.class/instance/argument loaders/indirectLoader_byIndex_.st M FFI-NB.package/FFIExternalStructure.class/class/accessing/structureSize.st A FFI-NB.package/extension/CompiledMethod/instance/ffiArgumentNames.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50513.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50514.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50513.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50514.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50514 FFI-NB http://files.pharo.org/image/50/50514.zip

Jan. 6, 2016

[pharo-project/pharo-core]

by GitHub

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

Jan. 6, 2016

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

by Tudor Girba

Hi, I updated: ConfigurationOfMoose ConfigurationOfMooseAlgos ConfigurationOfPetitParser and I will continue with the rest of the configurations from Moose. Thank you for pushing us, Esteban! Doru > On Jan 6, 2016, at 3:58 PM, Pierce Ng <pierce(a)samadhiweb.com> wrote: > > 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 >> > -- www.tudorgirba.com www.feenk.com "Be rather willing to give than demanding to get."

Jan. 6, 2016