- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] threading in Pharo

by Igor Stasenko

On 24 March 2014 22:54, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > On Mon, Mar 24, 2014 at 8:23 PM, Alexandre Bergel <alexandre.bergel(a)me.com > > wrote: > >> >> I am working on a memory model for expandable collection in Pharo. >> Currently, OrderedCollection, Dictionary and other expandable collections >> use a internal array to store their data. My new collection library recycle >> these array instead of letting the garbage collector dispose them. I simply >> insert the arrays in an ordered collection when an array is not necessary >> anymore. And I remove one when I need one. >> > >> > Hm, is that really going to be worth the trouble? >> >> This technique reduces the consumption of about 15% of memory. >> >> >> At the end, #add: and #remove: are performed on these polls of >> arrays. I havenât been able to spot any problem regarding concurrency and I >> made no effort in preventing them. I have a simple global collection and >> each call site of "OrderedCollection newâ can pick an element of my global >> collection. >> >> >> >> I have the impression that I simply need to guard the access to the >> global poll, which is basically guarding #add: #remove: and #includes: >> > >> > One of the AtomicCollections might be the right things for you? >> >> I will have a look at it. >> >> >> What is funny, is that I did not care at all about multi-threading and >> concurrency, and I have not spotted any problem so far. >> > >> > There isnât any âmulti-threadingâ like in Java, you got a much more >> control version: cooperative on the same priority, preemptive between >> priorities. >> > So, I am not surprised. And well, these operations are likely not to be >> problematic when they are racy, except when the underling data structure >> could get into an inconsistent state itself. The overall operations >> (adding/removing/searing) are racy on the application level anyway. >> > >> > However, much more interesting would be to know what kind of benefit do >> you see for such reuse? >> > And especially, with Spur around the corner, will it still pay off >> then? Or is it an application-specific optimization? >> >> I am exploring a new design of the collection library of Pharo. Not all >> the (academic) ideas will be worth porting into the mainstream of Pharo. >> But some of them yes. >> >> Thanks for all your help guys! Youâre great! >> >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > An interesting method I stumbled upon which may help in understanding how > these things do work. > > BlockClosure>>valueUnpreemptively > "Evaluate the receiver (block), without the possibility of preemption by > higher priority processes. Use this facility VERY sparingly!" > "Think about using Block>>valueUninterruptably first, and think about > using Semaphore>>critical: before that, and think about redesigning your > application even before that! > After you've done all that thinking, go right ahead and use it..." > | activeProcess oldPriority result semaphore | > activeProcess := Processor activeProcess. > oldPriority := activeProcess priority. > activeProcess priority: Processor highestPriority. > result := self ensure: [activeProcess priority: oldPriority]. > > I would not recommend you to use this method for anything. This method heavily relies on how process scheduler works, and in case of any changes, it may break everything. For the sake of programming, one shall never assume there is a way to "stop the world while i busy doing something". -- Best regards, Igor Stasenko.

March 25, 2014

Re: [Pharo-dev] Font problem is still there

by Igor Stasenko

On 22 March 2014 15:11, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > Just for the record, do you realise that this is between two C libraries > (easy to debug)? > > I didn't tried to debug it, i can't bet it would be easy (need to build a debug version of cairo first) but it worth trying. Meanwhile i will put workaround back. > > Hi! > > > >> there's some kind of caching interference either in cairo or between > cairo and freetype, > >> when using identity transformation matrix and integral (integer) font > sizes. > >> and there is a simple workaround: > >> > >> canvas pathTransform restoreAfter: [ > >> canvas pathTransform scaleBy: 1.00001. > >> "draw text here" > >> > >> ] > >> > >> this workaround was in font-rendering code, but then i removed it, > because i thought problem was solved. > > > > Can we add this back please? > > This font problem is quite serious. It makes people laugh at Pharo... > > -- Best regards, Igor Stasenko.

March 25, 2014

[pharo-project/pharo-core] 906370: 30800

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 906370dc243cd777ab55c0c542de1dcf7bed7fda https://github.com/pharo-project/pharo-core/commit/906370dc243cd777ab55c0c5… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-03-25 (Tue, 25 Mar 2014) Changed paths: M Morphic-Base.package/MorphTreeListManager.class/instance/keyboard managing/arrowEvent_key_.st M NECompletion.package/NECContext.class/instance/private-type-guessing/guessArgument_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script453.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30800.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Versionner-Core-Commands.package/VSConfigurationValidationIssuesDisplayCommand.class/README.md A Versionner-Core-Commands.package/VSConfigurationValidationIssuesDisplayCommand.class/definition.st A Versionner-Core-Commands.package/VSConfigurationValidationIssuesDisplayCommand.class/instance/execute/execute.st A Versionner-Core-Commands.package/VSDevCycleCommand.class/instance/checking/ensureDevelopmentVersionExists.st A Versionner-Core-Commands.package/VSDevCycleCommand.class/instance/checking/ensureDevelopmentVersionIsBaseline.st A Versionner-Core-Commands.package/VSReleaseDevelopmentVersionCommand.class/instance/actions/baselineFor_.st A Versionner-Core-Commands.package/VSReleaseDevelopmentVersionCommand.class/instance/actions/mcVersionFor_.st A Versionner-Core-Commands.package/VSReleaseDevelopmentVersionCommand.class/instance/actions/projectReference_configurationFrom_.st A Versionner-Core-Commands.package/VSReleaseDevelopmentVersionCommand.class/instance/actions/release_andSolveSymbolic_.st A Versionner-Core-Commands.package/VSReleaseDevelopmentVersionCommand.class/instance/actions/resolveSymbolicVersionsIn_.st M Versionner-Core-Commands.package/VSReleaseDevelopmentVersionCommand.class/instance/execute/execute.st R Versionner-Core-Commands.package/VSUpdateDevelopmentVersionCommand.class/instance/checking/ensureDevelopmentVersionExists.st R Versionner-Core-Commands.package/VSUpdateDevelopmentVersionCommand.class/instance/checking/ensureDevelopmentVersionIsBaseline.st M Versionner-Core-DependenciesModel.package/MTDevelopmentWorkfow.class/instance/protocol/releaseDevelopment_.st M Versionner-Core-DependenciesModel.package/MTDevelopmentWorkfow.class/instance/protocol/updateDevelopment.st M Versionner-Core-DependenciesModel.package/MTModelComparator.class/instance/comparing/is_equalsTo_.st R Versionner-Core-DependenciesModel.package/VersionnerToolBox.class/instance/spec creation/createProjectReferenceSpec_.st M Versionner-Core-DependenciesModel.package/VersionnerToolBox.class/instance/spec creation/projectSpecFromRequiredProject_.st M Versionner-Spec-Browser.package/VersionListModel.class/README.md M Versionner-Spec-Browser.package/VersionListModel.class/definition.st A Versionner-Spec-Browser.package/VersionListModel.class/instance/as yet unclassified/updateSelection.st A Versionner-Spec-Browser.package/VersionListModel.class/instance/as yet unclassified/updateSelectionVersionString.st M Versionner-Spec-Browser.package/VersionListModel.class/instance/initialization/initialize.st A Versionner-Spec-Browser.package/VersionListModel.class/instance/protocol/items_.st R Versionner-Spec-Browser.package/VersionnerProjectPackagesPanel.class/instance/accessing/packageChangesButton.st R Versionner-Spec-Browser.package/VersionnerProjectPackagesPanel.class/instance/accessing/packageChangesButton_.st M Versionner-Spec-Browser.package/VersionnerProjectPanel.class/class/spec/defaultSpec.st A Versionner-Spec-Browser.package/VersionnerReleasePanel.class/README.md A Versionner-Spec-Browser.package/VersionnerReleasePanel.class/class/instance creation/openForVersion_.st A Versionner-Spec-Browser.package/VersionnerReleasePanel.class/class/spec/defaultSpec.st A Versionner-Spec-Browser.package/VersionnerReleasePanel.class/definition.st A Versionner-Spec-Browser.package/VersionnerReleasePanel.class/instance/accessing/developmentVersion_.st A Versionner-Spec-Browser.package/VersionnerReleasePanel.class/instance/accessing/releaseNumber.st A Versionner-Spec-Browser.package/VersionnerReleasePanel.class/instance/accessing/releaseNumberLabel.st A Versionner-Spec-Browser.package/VersionnerReleasePanel.class/instance/accessing/releaseNumberText.st A Versionner-Spec-Browser.package/VersionnerReleasePanel.class/instance/accessing/symbolicVersionResolutionCheckBox.st A Versionner-Spec-Browser.package/VersionnerReleasePanel.class/instance/confirmation/confirmSymbolicVersionResolutionDesactivation.st A Versionner-Spec-Browser.package/VersionnerReleasePanel.class/instance/initialization/initialExtent.st A Versionner-Spec-Browser.package/VersionnerReleasePanel.class/instance/initialization/initializeWidgets.st A Versionner-Spec-Browser.package/VersionnerReleasePanel.class/instance/initialization/title.st A Versionner-Spec-Browser.package/VersionnerReleasePanel.class/instance/private/latestVersionString.st A Versionner-Spec-Browser.package/VersionnerReleasePanel.class/instance/protocol/initialVersion_.st A Versionner-Spec-Browser.package/VersionnerReleasePanel.class/instance/protocol/isSymbolicVersionResolutionChecked.st A Versionner-Tests-Core-Commands.package/VSReleaseDevelopmentVersionCommandTest.class/README.md A Versionner-Tests-Core-Commands.package/VSReleaseDevelopmentVersionCommandTest.class/definition.st A Versionner-Tests-Core-Commands.package/VSReleaseDevelopmentVersionCommandTest.class/instance/expected results/expectedTestResolveSymbolicVersionInResult.st A Versionner-Tests-Core-Commands.package/VSReleaseDevelopmentVersionCommandTest.class/instance/running/setUp.st A Versionner-Tests-Core-Commands.package/VSReleaseDevelopmentVersionCommandTest.class/instance/running/tearDown.st A Versionner-Tests-Core-Commands.package/VSReleaseDevelopmentVersionCommandTest.class/instance/test data/generateTestVersion.st A Versionner-Tests-Core-Commands.package/VSReleaseDevelopmentVersionCommandTest.class/instance/tests/testProjectReferenceConfigurationFrom.st A Versionner-Tests-Core-Commands.package/VSReleaseDevelopmentVersionCommandTest.class/instance/tests/testResolveSymbolicVersionsIn.st A Versionner-Tests-Core-DependenciesModel.package/MTDevelopmentWorkfowTestWithXMLParser.class/instance/tests/testIsDevelopmentUsedInRelease.st A Versionner-Tests-Core-DependenciesModel.package/MTDevelopmentWorkfowTestWithXMLParser.class/instance/utility/setDevelopment_.st M Versionner-Tests-Core-DependenciesModel.package/MTModelComparatorTest.class/instance/tests/testIsEqualsTo.st A Versionner-Tests-Core-DependenciesModel.package/MTProjectExampleBuilder.class/class/building projects/projectC.st M Versionner-Tests-Core-DependenciesModel.package/VersionnerToolBoxTest.class/definition.st Log Message: ----------- 30800 13063 NECContext guessing wrong with Seaside 3.1 https://pharo.fogbugz.com/f/cases/13063 13105 ctrl-cmd-arrow behavior https://pharo.fogbugz.com/f/cases/13105 13061 Integrate Versionner 2.6 https://pharo.fogbugz.com/f/cases/13061 http://files.pharo.org/image/30/30800.zip

March 25, 2014

[pharo-project/pharo-core]

by GitHub

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

March 25, 2014

Re: [Pharo-dev] Crazy Smalltalk code snippets

by phil＠highoctane.be

On Tue, Mar 25, 2014 at 12:05 PM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > On 24 March 2014 23:33, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > > On Tue, Mar 25, 2014 at 12:11 AM, Eliot Miranda <eliot.miranda(a)gmail.com > > > > wrote: > >> > >> > >> > >> > >> On Mon, Mar 24, 2014 at 4:02 PM, phil(a)highoctane.be <phil(a)highoctane.be > > > >> wrote: > >>> > >>> I am curious. > >>> > >>> Maybe on the first one, substitute something when a DNU is encountered. > >>> Like logging undefined receivers. > >>> > >>> I wonder how the next one behaves on JITted methods. I fear that offset > >>> errors may lead to weird errors. > >> > >> > >> It *should* "just work" :-) (provided the jump distance of -12 is > >> correct). The VM traps assignments to variables of contexts, and > converts > >> them to vanilla contexts. Therefore the jump doesn't occur in JITTED > code > >> but back in normal interpreted bytecode. > >> > > > > How magical! > > > >>> > >>> On Mon, Mar 24, 2014 at 11:51 PM, Pavel Krivanek > >>> <pavel.krivanek(a)gmail.com> wrote: > >>>> > >>>> Who can find the most useful usage of this? > >>>> > >>>> thisContext instVarNamed: #receiver put: 42. > >>>> self factorial > >>>> > >>>> GOTO statement in Pharo: > >>>> > >>>> FileStream stdout nextPutAll: 'Hello world'; lf. > >>>> thisContext jump: -12. > >>>> Let's collect the next ones :-) > >> > >> > >> this is my favourite, and would lock-up a strict blue book VM. (I once > >> locked up Allen Wirfs-Brock's 4404 with this and he wasn't best pleased > >> [forgive me Allen]) > >> > >> > >> | a | > >> a := Array with: #perform:withArguments: with: nil. > >> a at: 2 put: a. > >> a perform: a first withArguments: a > >> > >> ;-) > >> > > > > > > The infinite is near. > > > > Not as blocking, but still... (Alt-. interrupts this one) > > > > Crazy>>run > > Continuation currentDo: [ :cc | here := cc ]. > > here value: true. > > > > Crazy new run > > > > BTW, is there any support for partial continuations in Pharo? > Continuations > > like this one look like full continuations and that's *huge*. > > Yes: http://ss3.gemstone.com/ss/Control.html > > Last time I checked I did need to add a shim (see the ControlPharo > package), but it did load cleanly and pass all its own tests. > I have now loaded the SS3 version. All tests do pass. I loaded the one from SqueakSource before. > > Control not only provides a convenient way of making partial > continuations (of the shift/reset sort, if you're familiar with the > literature), Nice article of yours. Now, I have something to chew on :-) > but also _delimited_ dynamic variables. As soon as you > start stack-slicing with partial continuations, you quickly find that > standard implementations of dynamic variables fail in all sorts of > nasty ways. Fundamentally, "normal" dynamic variables _cannot_ work > cleanly with partial continuations because they either close over too > much of the dynamic environment, or too little. > > Here's some reading on the topic: > > [1] http://okmij.org/ftp/Computation/dynamic-binding.html > [2] http://www.cs.rutgers.edu/~ccshan/dynscope/DDBinding.pdf > [3] > http://www.lshift.net/blog/2012/06/27/resumable-exceptions-can-macro-expres… Ah, more head banging against the desk, sweet. Phil > > > frank > > >>>> Cheers, > >>>> -- Pavel > >>> > >>> > >> > >> > >> > >> -- > >> best, > >> Eliot > > > > > >

March 25, 2014

Re: [Pharo-dev] Crazy Smalltalk code snippets

by Frank Shearar

On 24 March 2014 23:33, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > On Tue, Mar 25, 2014 at 12:11 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: >> >> >> >> >> On Mon, Mar 24, 2014 at 4:02 PM, phil(a)highoctane.be <phil(a)highoctane.be> >> wrote: >>> >>> I am curious. >>> >>> Maybe on the first one, substitute something when a DNU is encountered. >>> Like logging undefined receivers. >>> >>> I wonder how the next one behaves on JITted methods. I fear that offset >>> errors may lead to weird errors. >> >> >> It *should* "just work" :-) (provided the jump distance of -12 is >> correct). The VM traps assignments to variables of contexts, and converts >> them to vanilla contexts. Therefore the jump doesn't occur in JITTED code >> but back in normal interpreted bytecode. >> > > How magical! > >>> >>> On Mon, Mar 24, 2014 at 11:51 PM, Pavel Krivanek >>> <pavel.krivanek(a)gmail.com> wrote: >>>> >>>> Who can find the most useful usage of this? >>>> >>>> thisContext instVarNamed: #receiver put: 42. >>>> self factorial >>>> >>>> GOTO statement in Pharo: >>>> >>>> FileStream stdout nextPutAll: 'Hello world'; lf. >>>> thisContext jump: -12. >>>> Let's collect the next ones :-) >> >> >> this is my favourite, and would lock-up a strict blue book VM. (I once >> locked up Allen Wirfs-Brock's 4404 with this and he wasn't best pleased >> [forgive me Allen]) >> >> >> | a | >> a := Array with: #perform:withArguments: with: nil. >> a at: 2 put: a. >> a perform: a first withArguments: a >> >> ;-) >> > > > The infinite is near. > > Not as blocking, but still... (Alt-. interrupts this one) > > Crazy>>run > Continuation currentDo: [ :cc | here := cc ]. > here value: true. > > Crazy new run > > BTW, is there any support for partial continuations in Pharo? Continuations > like this one look like full continuations and that's *huge*. Yes: http://ss3.gemstone.com/ss/Control.html Last time I checked I did need to add a shim (see the ControlPharo package), but it did load cleanly and pass all its own tests. Control not only provides a convenient way of making partial continuations (of the shift/reset sort, if you're familiar with the literature), but also _delimited_ dynamic variables. As soon as you start stack-slicing with partial continuations, you quickly find that standard implementations of dynamic variables fail in all sorts of nasty ways. Fundamentally, "normal" dynamic variables _cannot_ work cleanly with partial continuations because they either close over too much of the dynamic environment, or too little. Here's some reading on the topic: [1] http://okmij.org/ftp/Computation/dynamic-binding.html [2] http://www.cs.rutgers.edu/~ccshan/dynscope/DDBinding.pdf [3] http://www.lshift.net/blog/2012/06/27/resumable-exceptions-can-macro-expres… frank >>>> Cheers, >>>> -- Pavel >>> >>> >> >> >> >> -- >> best, >> Eliot > >

March 25, 2014

Re: [Pharo-dev] Using Spec based UI in Nautilus Plugins

by Benjamin

MethodToolbar new buildWithSpec Ben On 25 Mar 2014, at 10:09, phil(a)highoctane.be wrote: > This doesn't work for building the MathodToolbar widget. > > MethodToolbar defaultSpec buildWithSpec > > #DNU SpecLayout>>buildWithSpec > > MethodToolbar class>>defaultSpec > <spec> > ^ SpecLayout composed > newRow: [ :row | > row > add: #(model browseModel); > add: #(model sendersModel); > add: #(model implementorsModel); > add: #(model versionModel); > add: #(model dropListModel) ]; > yourself > > > > What to do? > > Phil > > On Tue, Mar 25, 2014 at 9:51 AM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > You create your own subclass of AbstractNautilusPlugin in where the display method will look like > > display > ^ mySpec buildWithSpec > > This should do the trick > > Ben > > On 25 Mar 2014, at 08:41, phil(a)highoctane.be wrote: > >> I wanted to use a MethodToolbar as part of a Nautilus plugin. >> >> Ok, I can use the widget in with an openWithSpec but how can I put this into a widget that Nautilus will accept as a plugin? >> >> >> | b | >> b := MethodToolbar new. >> b openWithSpec. >> b method: <method from plugin...> >> >> >> Phil >> > >

March 25, 2014

Re: [Pharo-dev] [Pharo-users] installing gtoolkit

by Tudor Girba

Hi, On Tue, Mar 25, 2014 at 10:02 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > On Tue, Mar 25, 2014 at 8:17 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> If you want to install GToolkit (the project that contains GTInspector, >> GTPlayground and GTDebugger) in your image, you can follow one of the >> options as described here: >> http://www.humane-assessment.com/blog/installing-gtoolkit >> >> If you give it a try, please let us know how it works for you. >> > > Looks *very* nice. Takes a while to get used to. > Happy. > Now, the gtoolkit image I used didn't respected the Pharo3 keybindings > that allow one to open a workspace (Alt-o Alt-w / Cmd-o Cmd-w). > It would be nice to have them so that opening the Playground is done in a > snap. > The global shortcuts are disabled because they conflict with the Cmd+o shortcuts used everywhere in the GTInspector and GTPlayground. We have an issue open on this, but we did not yet come to a conclusion. It would be useful to have more eyeballs looking at it: https://pharo.fogbugz.com/f/cases/13102/Sequences-of-bindings-hide-individu… > Question: if one has opened a Miller column too far, how can we close that > one? It was annoying to have to use to precisely use the scrollbar down > there to get back to where I was. And if the column is not out of view, it > keeps on updating and moves the thing to the right. Kind of ping-pong style. > You cannot :(. The current implementation of the Miller column widget is not at all optimal. I have a new design that does not rely on a scrollbar at all, but to get that to work, we would need a bit more effort involved in building the necessary widgets. It would be great to have more contributions there. If anyone is interested, please let me know. > I'll load it in my current development project and see how it goes (that > superwhite theme of Moose is just an eye killer for me). > Great. Let me know how it works and what quirks you get into. Cheers, Doru > Phil > > >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

March 25, 2014

Re: [Pharo-dev] [Pharo-users] installing gtoolkit

by Sven Van Caekenberghe

On 25 Mar 2014, at 10:02, phil(a)highoctane.be wrote: > Question: if one has opened a Miller column too far, how can we close that one? It was annoying to have to use to precisely use the scrollbar down there to get back to where I was. And if the column is not out of view, it keeps on updating and moves the thing to the right. Kind of ping-pong style. I have had a similar remark in the past: I want to be able to close the extra columns. It all takes so much space and it a distraction once you no longer need them.

March 25, 2014

Re: [Pharo-dev] Using Spec based UI in Nautilus Plugins

by phil＠highoctane.be

This doesn't work for building the MathodToolbar widget. MethodToolbar defaultSpec buildWithSpec #DNU SpecLayout>>buildWithSpec MethodToolbar class>>defaultSpec <spec> ^ SpecLayout composed newRow: [ :row | row add: #(model browseModel); add: #(model sendersModel); add: #(model implementorsModel); add: #(model versionModel); add: #(model dropListModel) ]; yourself What to do? Phil On Tue, Mar 25, 2014 at 9:51 AM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > You create your own subclass of AbstractNautilusPlugin in where the > display method will look like > > display > ^ mySpec buildWithSpec > > This should do the trick > > Ben > > On 25 Mar 2014, at 08:41, phil(a)highoctane.be wrote: > > I wanted to use a MethodToolbar as part of a Nautilus plugin. > > Ok, I can use the widget in with an openWithSpec but how can I put this > into a widget that Nautilus will accept as a plugin? > > > | b | > b := MethodToolbar new. > b openWithSpec. > b method: <method from plugin...> > > > Phil > > >

March 25, 2014