- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ConfigurationOfXXX package is not visible in nautilus...

by Dimitris Chloupis

great design if you ask me :) On Thu, Jan 7, 2016 at 12:30 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > is in Configurations group :) > thatâs by design, I think > > > On 07 Jan 2016, at 11:14, Blondeau Vincent <vincent.blondeau(a)worldline.com> > wrote: > > Hi, > > Happy new year ! > > It seems that any configuration loaded by Jenkins is not visible in > Nautilus (at package level) but are accessible via the Spotter (at class > level). Does someone know why? > > I opened a bug: > https://pharo.fogbugz.com/f/cases/17342/Configuration-OfXXX-packages-are-no… > > > Thanks in advance, > > Vincent > > > ------------------------------ > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. > > >

Jan. 7, 2016

Re: [Pharo-dev] ConfigurationOfXXX package is not visible in nautilus...

by Esteban Lorenzano

is in Configurations group :) thatâs by design, I think > On 07 Jan 2016, at 11:14, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > > Hi, > > Happy new year ! > > It seems that any configuration loaded by Jenkins is not visible in Nautilus (at package level) but are accessible via the Spotter (at class level). Does someone know why? > > I opened a bug: https://pharo.fogbugz.com/f/cases/17342/Configuration-OfXXX-packages-are-no… <https://pharo.fogbugz.com/f/cases/17342/Configuration-OfXXX-packages-are-no…> > > Thanks in advance, > > Vincent > > > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

Jan. 7, 2016

ConfigurationOfXXX package is not visible in nautilus...

by Blondeau Vincent

Hi, Happy new year ! It seems that any configuration loaded by Jenkins is not visible in Nautilus (at package level) but are accessible via the Spotter (at class level). Does someone know why? I opened a bug: https://pharo.fogbugz.com/f/cases/17342/Configuration-OfXXX-packages-are-no… Thanks in advance, Vincent ________________________________ Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

Jan. 7, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Denis Kudriashov

Ok. slice 17340 <https://pharo.fogbugz.com/f/cases/17340/Semaphore-critical-should-handle-in…> in inbox. It is only touches current #critical: implementation. It is not about deprecation wrong semaphore usage 2016-01-07 9:55 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-01-07 0:15 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >> >> 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. > > > To me it is better too. But it requires changes in VM primitive which I'm > can't provide. > So I will implement my idea. Do you ok with the name #waitIfInterrupted? >

Jan. 7, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Denis Kudriashov

2016-01-07 0:15 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > 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. To me it is better too. But it requires changes in VM primitive which I'm can't provide. So I will implement my idea. Do you ok with the name #waitIfInterrupted?

Jan. 7, 2016

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