July 2014 - Pharo-dev - lists.pharo.org

why double click does not work in rubric sometimes

by Tudor Girba

Hi, A while ago, Stef reported that he could not select text anymore in the new Rubric-based interfaces (inspector, playground). I noticed this as well but only occasionally. Here is what I found. TextMorph uses a kind of a simulation to support smart selection. As a result, you basically can do: - click once at the beginning of a parenthesis - wait a couple of seconds - click again ==> and the text is selected Instead of this mechanism, Rubric relies on real double click events. So, in order to select something you have to click-click quickly. Now, the issue is that every once in a while, somehow the image seems to stop receiving double clicks. I experienced this both on Windows and on Mac. As a consequence, it appears that you cannot select anymore with double click. To double check that this happens, you can try double clicking on the window title and you will see that it does not maximize anymore. If you close the image and open it again, the problem gets fixed. This makes it difficult to reproduce and debug. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

July 28, 2014

Re: [Pharo-dev] Future

by Max Leske

IIRC TaskIT supports fututes: http://smalltalkhub.com/#!/~sbragagnolo/TaskIT (there was a thread on the list recently). On 28.07.2014, at 15:36, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi All, > > I saw that Squeak has an implementation for futures. I saw another one, implemented with blocks [1]. There is nothing of the sort in Pharo at the moment? > > [1] http://onsmalltalk.com/smalltalk-concurrency-playing-with-futures > > Thanks, > > Thierry >

July 28, 2014

Re: [Pharo-dev] Dali and Voyage

by Henrik Johansen

On 28 Jul 2014, at 11:41 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 28 Jul 2014, at 11:36, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> On 28 Jul 2014, at 11:15, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >>> >>> On 21 Jul 2014, at 3:34 , Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>>> >>>> On 21 Jul 2014, at 09:44, stepharo <stepharo(a)free.fr> wrote: >>>> >>>>> >>>>> On 21/7/14 08:46, Torsten Bergmann wrote: >>>>>> DALI >>>>>> http://ss3.gemstone.com/ss/DALi.html >>>>>> >>>>>> VOYAGE >>>>>> http://smalltalkhub.com/#!/~estebanlm/Voyage >>>>> >>>>> I do not know if there are back ends for something else than mongo in Voyage. >>>> >>>> certainly not for GOODS :) >>>> actually we have just âin memoryâ and âmongoâ (in memory works fine when deploying on gemstone, for example) >>>> I always want to add more backends but wellâ¦ time, time, timeâ¦ >>>> >>>> Esteban >>> >>> Iâm intending to add one for Riak, in an unspecified amount of time, depending on my other workloadâ¦ >>> Iâd like it performant, and use a client up to date with the latest Riak API, which (afaict) means using the ProtoBuffer protocol, which means having to implementing PB first. > > It would be good to have a ProtoBuffers implementation that is separate. I agree, keeping the building blocks separate is nice :) Cheers. Henry

July 28, 2014

Re: [Pharo-dev] Dali and Voyage

by Henrik Johansen

On 28 Jul 2014, at 11:36 , Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 28 Jul 2014, at 11:15, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >> >> On 21 Jul 2014, at 3:34 , Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> >>> On 21 Jul 2014, at 09:44, stepharo <stepharo(a)free.fr> wrote: >>> >>>> >>>> On 21/7/14 08:46, Torsten Bergmann wrote: >>>>> DALI >>>>> http://ss3.gemstone.com/ss/DALi.html >>>>> >>>>> VOYAGE >>>>> http://smalltalkhub.com/#!/~estebanlm/Voyage >>>> >>>> I do not know if there are back ends for something else than mongo in Voyage. >>> >>> certainly not for GOODS :) >>> actually we have just âin memoryâ and âmongoâ (in memory works fine when deploying on gemstone, for example) >>> I always want to add more backends but wellâ¦ time, time, timeâ¦ >>> >>> Esteban >> >> Iâm intending to add one for Riak, in an unspecified amount of time, depending on my other workloadâ¦ >> Iâd like it performant, and use a client up to date with the latest Riak API, which (afaict) means using the ProtoBuffer protocol, which means having to implementing PB first. >> The progress so far is I got the PB serializer almost done (sidetracked by wanting an NB-based UTF8 converter to make it more performant), but I havenât started the PB message parser yet, nor the actual Riak backend. > > I was intending to add Riak support too :) > Do you want access to the repo, so we keep all together? (and then I can check and maybe collaborate) > and btw, are you using/checking Phriak? > > Esteban Sure, as you might have inferred from my mail, itâll probably be a bit before I start on the actual riak client, though itâs in my plans. First, Iâll need to finish up and release NBConverters (of which UTF8 conversion I want to use in PB implementation is a part), then Protobuffer implementation (data type serialization + message spec parsing), then parse in the Riak PB messages and build a client on top of that. And yes, Iâve checked Phriak, building a client on top of that would probably be much faster than what I intend. But, seeing as how thereâs 2.0 functionality exclusively implemented in the PB API, I thought itâd be nice to go the long route while Iâm at it. AFAICT, 2.0 mostly adds functionality, so it seems to me if someone wrote a backend using Phriak, a new client would be able to operate as a drop-in replacement if it is indeed more performant. (not to mention a nice starting point for a 2.0 backend which can utilize new functionality) Cheers, Henry

July 28, 2014

Future

by Thierry Goubier

Hi All, I saw that Squeak has an implementation for futures. I saw another one, implemented with blocks [1]. There is nothing of the sort in Pharo at the moment? [1] http://onsmalltalk.com/smalltalk-concurrency-playing-with-futures Thanks, Thierry

July 28, 2014

Updated XMLPullParser for SIXX?

by Mariano Martinez Peck

Hi guys, I was reading this post: http://kentreis.wordpress.com/2009/06/01/deep-sixx-with-xml-pull-parser/ about using a XMLPullParser with SIXX. This is from 2009 and I guess I guess SIXX and XML parsers have been changing in the last years. So...does somebody know if there is an updated version of a XML Pull Parser? And second question, any integration with SIXX? Thanks in advance, -- Mariano http://marianopeck.wordpress.com

July 28, 2014

Re: [Pharo-dev] [Vm-dev] Delay machinery (was Re: Suspending a Process)

by J. Vuletich (mail lists)

Hi Ben, Your fix works great in Cuis too, thank you! (Cuis also had this annoying problem). I spent a few hours at this, and I couldn't really understand the problem with the old code. But yours makes perfect sense to me, and indeed it fixes the problem. One problem that remains is the use of AccessProtect variable. The other users of this "mutex semaphore" assume it gives them exclusive access to the state. This is no longer the case! It is best to completly remove the AccessProtect variable, and avoid any risk of deadlock. To do this, in Cuis, I made #shutDown and #startUp to call #stopTimerEventLoop and #startTimerEventLoop. I also removed DelaySuspended. It seems to work ok, and I suggest doing the same for Pharo (and Squeak). Cheers, Juan Vuletich Quoting Ben Coman <btc(a)openinworld.com>: > ... Anyway, the delay scheduling code seemed more like a > producer/consumer signaling problem than a shared resource mutal > exclusion problem, so I rewrote it like the former and fixes the problem > without causing any *obvious* problems.Â However I lack experience here > and it could definitely use some review.Â Can you take the attached zip > file and... > > 1. File in "Delay class-new delay code part 1.st" > Â Â Â Defines #enableNewDelayCode and #enableNewDelayCode: > Â Â Â Manually define the referenced class variables > > 2. File in "Delay class-new delay code part 2.st" > Â Â Â Â Modifies #handleTimerEvent, guarded by enableNewDelayCode > > 3. File in "Delay-new delay code part 3.st" > Â Â Â Modifies #schedule and #unschedule, guarded by enableNewDelayCode > > 4. File in "BackgroundWorkDisplayMorph.st" > > 5. Save checkpoint Image to return to between trials. > > 6. Open System Browser on BackgroundWorkDisplayMorph>>initialize > Â Â Â > Trial 1. > BackgroundWorkDisplayMorph new openInWorld. > > Trial 2. > Delay enableNewDelayCode: true. > BackgroundWorkDisplayMorph new openInWorld. > > If if its deemed worthwhile, I'll open a ticket to track this more > formally.Â One thing needed is to considered performance impact, I > haven't so far. > > cheers -ben > > [1] http://www.barrgroup.com/Embedded-Systems/How-To/RTOS-Mutex-Semaphore > [2] http://nerdfortress.com/2011/02/18/you-say-semaphore-i-say-mutex/

July 28, 2014

[pharo-project/pharo-core]

by GitHub

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

July 28, 2014

[pharo-project/pharo-core] b3aef1: 40131

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: b3aef1b51db8fa9946be6a739c8b03e54420954f https://github.com/pharo-project/pharo-core/commit/b3aef1b51db8fa9946be6a73… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-07-28 (Mon, 28 Jul 2014) Changed paths: R Compiler.package/ReparseAfterSourceEditing.class/README.md R Compiler.package/ReparseAfterSourceEditing.class/class/signaling/signalWithNewSource_.st R Compiler.package/ReparseAfterSourceEditing.class/definition.st R Compiler.package/ReparseAfterSourceEditing.class/instance/accessing/newSource.st R Compiler.package/ReparseAfterSourceEditing.class/instance/accessing/newSource_.st M Kernel.package/Message.class/class/instance creation/selector_argument_.st R Kernel.package/Object.class/instance/macpal/contentsChanged.st R NECompletion.package/extension/CodeHolder/instance/contentsChanged.st M NewValueHolder.package/ValueHolder.class/instance/accessing/contents_.st A OpalCompiler-Core.package/ReparseAfterSourceEditing.class/README.md A OpalCompiler-Core.package/ReparseAfterSourceEditing.class/class/signaling/signalWithNewSource_.st A OpalCompiler-Core.package/ReparseAfterSourceEditing.class/definition.st A OpalCompiler-Core.package/ReparseAfterSourceEditing.class/instance/accessing/newSource.st A OpalCompiler-Core.package/ReparseAfterSourceEditing.class/instance/accessing/newSource_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script131.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40131.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Tool-Browser-Old.package/CodeHolder.class/instance/self-updating/contentsChanged.st M Tool-Finder.package/MethodFinder.class/instance/initialize/initialize.st Log Message: ----------- 40131 13659 ReparseAfterSourceEditing needs to be moved to Opal https://pharo.fogbugz.com/f/cases/13659 13706 #contentsChanged not needed on Object https://pharo.fogbugz.com/f/cases/13706 http://files.pharo.org/image/40/40131.zip

July 28, 2014

Re: [Pharo-dev] [Pharo-users] [Tip] Image init scripts when working with PharoLauncher

by Damien Cassou

On Fri, Jul 25, 2014 at 1:54 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > I've found the following script very useful: here is what I do for MC credentials: credentials := Dictionary new. MCRepository classVarNamed: 'Settings' put: credentials. credentials at: 'account smalltalkhub' put: '*smalltalkhub.com* DamienCassou:mypassword'. credentials at: 'account squeaksource' put: '*squeaksource.com* dc:mypassword'. credentials at: 'account ss3' put: '*ss3.gemstone.com* dc:mypassword'. credentials at: 'account source.squeak' put: '*source.squeak.org* DamienCassou:mypassword'. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 28, 2014