- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Operating Smalltalkhub from Pharo

by Damien Cassou

https://ci.inria.fr/pharo-contribution/job/SmalltalkHub/? There is an undocumented REST API that the Amber client uses. On Sun, Jul 27, 2014 at 2:23 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > I wonder if there is a way to operate smalltalkhub from pharo. What would > interest me is to browser smalltalkhub from pharo and do anything I can do > from the website with pharo. > > I am new with these things so I assume Zinc would be useful here , no ? > > is there any docs for smalltalkhub api ? > > Anyone tried something similar before ? > > I tried to load Smalltalkub configuration but it looks like that the config > does not define neither a stable or a developement version . -- 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

Re: [Pharo-dev] Dali and Voyage

by Norbert Hartl

Am 28.07.2014 um 11:51 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > But it _is_ more work than having it as a local subpart of some larger project. Slightly ;) Who does not properly package and document his own stuff? Wait â¦. the original author seems to be a Kent Beck. Anyone knows him? :) Norbert

July 28, 2014

Re: [Pharo-dev] Configuration readonly archives

by Stephan Eggermont

Stef wrote >I agree. This is why I also think that released should point to version >and not symbolic version. I strongly disagree. A configuration should only change when there is a meaningful change. Changes in dependencies that do not change relevant behavior should not propagate. We achieve that by using #'releasex.x' style versioning. Changes that are not supposed to change observable behavior and bug fixes get new numbered versions within the release. #development versions are updated in place. In Moose we did not encounter a situation where a month-old numbered version configuration was still loadable in the latest Pharo. There is a use case for snapshots of exact versions. They don't belong in configurations. Focussing improvements in Versioner on releasing more often numbered versions is counter productive. It just generates more work to keep configurations working. I have been fixing lots of configurations on ci, and nearly all problems have to do with not using #'releasex.x' style symbolic versioning. There are two problems: - Configurations using numbered versions. They break as soon as a dependent project changes functionality or does a bug fix, often as a result of underlying code in Pharo changing. - Configurations using #stable, where the dependent project does a new release. Now Seaside, Grease and Magritte have switched to this style of versioning, the number of problems has reduced drastically. Stephan

July 28, 2014

Re: [Pharo-dev] Dali and Voyage

by Sven Van Caekenberghe

On 28 Jul 2014, at 11:45, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 28.07.2014 um 11:41 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> >> 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. >> The same goes for the BSON implementation hidden in StHub. >> > The BSON code should be loadable without MongoTalk. It is separate packages. Or do you mean a separate repository would be better? With separate I mean: being managed, documented, advertised, tested and used as such, it is more a mindset than how this is exactly done. Someone needs it for something new, point them to the right place and they are off. Protocols are (should be) ideal building blocks. But it _is_ more work than having it as a local subpart of some larger project. > IMHO it would be sufficient to find it but smalltalkhub isn't helpful in this respect. > > Norbert > >>>> 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 >>> >>>> >>>> Cheers, >>>> Henry

July 28, 2014

Re: [Pharo-dev] Dali and Voyage

by Norbert Hartl

Am 28.07.2014 um 11:41 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > 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. > The same goes for the BSON implementation hidden in StHub. > The BSON code should be loadable without MongoTalk. It is separate packages. Or do you mean a separate repository would be better? IMHO it would be sufficient to find it but smalltalkhub isn't helpful in this respect. Norbert >>> 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 >> >>> >>> Cheers, >>> Henry

July 28, 2014