- Pharo-dev - lists.pharo.org

ReÂ : Re: SessionManager (aka new startup / shutdown list manager) needs testers

by Christophe Demarey

We do that because at startup, it is the startup ui manager that is used and we need to restore a usable one. You could use a deferred startup action to set up a bloc ui manager. How do you set the bloc ui manager for now? ----- Aliaksei Syrel <alex.syrel(a)gmail.com> a Ã©critÂ : > UIManagerSessionHandler>>#startup: isImageStarting > "Install the right UIManager" > UIManager default: UIManager forCurrentSystemConfiguration. > > Setting (overring current one) default UIManager each time image is > saved/started up prevents us from having custom UIManagers, for example > Bloc UI manager > > On Tue, Feb 2, 2016 at 7:04 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > > When deleting a class I get deprecation in #50561 in > > SystemDictionary>>#forgetClass: aClass logged: aBool because > > of removeFromStartUpList: > > > > > > Cheers, > > Alex > > > > On Sat, Dec 5, 2015 at 2:39 PM, Christophe Demarey < > > christophe.demarey(a)inria.fr> wrote: > > > >> > >> > >> ------------------------------ > >> > >> *De: *"Nicolai Hess" <nicolaihess(a)gmail.com> > >> *Ã: *"Pharo Development List" <pharo-dev(a)lists.pharo.org> > >> *EnvoyÃ©: *Vendredi 4 DÃ©cembre 2015 22:05:26 > >> *Objet: *Re: [Pharo-dev] SessionManager (aka new startup / shutdown list > >> manager) needs testers > >> > >> > >> Looks good. What are the main critical startup/shutdown users( classes) > >> that should be tested? > >> > >> Classes using startup or/and shutdown are > >> > >> #SmallInteger > >> #Delay atPriority > >> #ProcessorScheduler > >> #InputEventFetche > >> #InputEventFetcher > >> #OSPlatfor > >> #Stdio > >> #LanguageEnvironment > >> #ShortIntegerArray > >> #DiskStore > >> #SmalltalkImage > >> #WeakFinalizationList > >> #Clipboard > >> #MCMethodDefinition > >> #Symbol > >> #Locale > >> #MultiByteFileStream > >> #WeakArray > >> #FileStream > >> #FileLocator > >> #BasicCommandLineHandler > >> #NonInteractiveTranscript > >> #ASTCache > >> #OSEnvironment > >> #EndianDetector > >> #InternetConfiguration > >> #ZnServer > >> #MCGitHubRepository > >> #ZnLogEvent > >> #DisplayScreen > >> #InputEventSensor > >> #Cursor > >> #Form > >> #StrikeFont > >> #Color > >> #FreeTypeCache > >> #LogicalFont > >> #FT2Handle > >> #FreeTypeSettings > >> #WorldMorph > >> #CPUWatcher > >> #NOCCompletionTable > >> #Nautilus > >> #PharoCommonTools > >> #GTPlayBook > >> > >> Also sensitive code could be the one using the session (Smalltalk > >> session) to check if they need to free or reset some resources. > >> > >> Thanks to have a look at it, > >> Christophe > >> > >> > >> I did some tests with AthensSceneView (uses NB and calls Smalltalk > >> session for reinit external resources) and Roassal. > >> I got one image startup failure, but I couldn't reproduce it yet. Maybe I > >> did image save and image save and quit, too quick. > >> > >> > >

Feb. 2, 2016

ReÂ : Re: SessionManager (aka new startup / shutdown list manager) needs testers

by Christophe Demarey

Hi, Indeed, I missed to update this one. Ã slice is in preparation. Thanks

Feb. 2, 2016

Re: [Pharo-dev] Contributing to Pharo

by Dale Henrichs

On 01/30/2016 08:27 PM, Ben Coman wrote: > On Sun, Jan 31, 2016 at 3:38 AM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com> wrote: >> >> On 1/30/16 1:54 AM, Bernhard Pieber wrote: >>> Dale, >>> >>> Thanks for your thorough answer. I really appreciate how you include links >>> to helpful articles. >>> >>> I find the description of the workflow you actually use very enlightening. >>> However, one thing still remains unclear. In the last step, when merging the >>> pull request. How is the unchanged metadata reconciled with the code >>> changes? I just realized that I just donât know what information is in the >>> Monticello metadata, which is not in the code? >>> >> Monticello metadata is basically the entire Monticello version history of >> the package, it includes direct ancestors, commit comments, the GUID, etc. >> For a FileTree repo, the meta data is stashed a separate file ... The form >> of the data is actually serialized Smalltalk object graph - a deeply nested >> set of Arrays - all written on a single line, so git has very little chance >> of being able to merge two files > What would it take to have the meta data spread out over multiple > lines (if that would work better with git?) Hmmm I suppose that if the meta data were represented in STON (using pretty print) the changes might be more mergable, but I think that Thierry's algorithm might be still to a proper merge, since it takes "object surgery" to get things right .... STON might make it possible for a human to do the necessary edits though ... Dale

Feb. 2, 2016

Re: [Pharo-dev] Contributing to Pharo

by Dale Henrichs

On 01/29/2016 05:17 PM, Eliot Miranda wrote: > Hi David, > >> On Jan 29, 2016, at 2:45 PM, David Allouche <david(a)allouche.net> wrote: >> >> Thanks Dale for all the explanations. >> >> How Monticello and version control relate in the big picture is starting to make sense for me. >> >> Now, I better understand why filetree ended up uses a file-per-method format, even though that is relatively hostile to git user interfaces optimised for other languages. There is really a need for a file-per-class exchange format, because that would works a lot better with the existing VCS ecosystem. > I agree so strongly. Class file outs which are eg sorted by selector make much more sense. They won't hit the file name length limit. They make it trivial to maintain method and class comment time stamps. They're easier to construct into snapshots because it's easier to decode the file name. > > And then it's easy to add files for package load/unload scripts and for the history. And then one is much more decoupled from the specific back end. It could be mercurial just as easily as git. > >> I think more package-based user interfaces would indeed be a very good idea, for browsing and for source code management. >> >> Stef, I have the impression you think that git is popular because it is a new shiny toy. I disagree with this idea. Git is a typical worse-is-better tool. It's good enough for most people, but it still has many shortcomings. It is popular in spite of its shortcomings. It became popular as destination for projects shifting from CVS and Subversion. So it is unlikely to be displaced by a newer, incrementally shinier tools. Anything that will displace it will have to provide an improvement of a similar magnitude as the jump between centralised and distributed version control. > This is a good analysis. What's valuable to the Pharo community is not displacing an already functional dvcs (Monticello) with an ill-suited one (git), but in being able to function in ecosystems like github where people can display their identity and where infrastructure for bug reports etc exist. > >> Still, I think it's a good idea not to restrict high level models to what git provides if that's a less than ideal fit to the image model. > Absolutely. Dale's talk of ditching Monticello metadata fills me with repulsion and makes me want to ask is he trying to sabotage or what? Eliot, you can't be serious - accusing me of sabotage? Ah, well.... how about you assume that I'm doing "or what":) The Monticello metadata in a git repository is redundant and leads to unnecessary commit conflicts -- end of story .... Despite the fact that the Monticello metadata is redundant, I have made sure that the Monticello metadata was included in FileTree from the very beginning for the very reason that I wanted developers to be able to try out FileTree, git and github without having to burn any Monticello bridges .... if they didn't like FileTree, git and github, then they would be able to back out of their use of git without losing data ... > It seems entirely destructive. It is not destructive ... > We have a functional package manager which currently supports interchange between Pharo, Squeak and Cuis, and GemStone? I assume that you are talking about Monticello packages and Monticello repositories ... or what? I am really not trying to do anything but "invent the future" --- I am not trying to destroy, I am trying to improve ... If you are not able to see the shortcomings of Monticello repositories (Note that I am distinguishing between Monticello packages and Monticello repositories --- FileTree uses Monticello packages and replaces Monticello repositories with git) and where git has advantages over Monticello repositories, then you should continue to use Monticello repositories ... Personally I don't see Monticello repositories going away anytime soon and expect to support Monticello repositories in GsDevKit_home, tODE, and Metacello for the rest of my life:) Dale

Feb. 2, 2016

Re: [Pharo-dev] [Vm-dev] Simple versus Recursive Mutexes

by Eliot Miranda

Hi Ben, On Tue, Feb 2, 2016 at 9:54 AM, Ben Coman <btc(a)openinworld.com> wrote: > > While we are in the process of revising the Mutex infrastructure [1] > to use dedicated primitives rather than rely on counting via a > semaphore, I want to raise the question of simple versus recursive > mutexes. > > This isn't something I know much about, except that some people > strongly believe recursive mutexes are evil, including David Butenhof > who apparently was the guy who added recursive mutexes to POSIX "on a > dare [...] but nobody was supposed to use recursive mutexes." [1]. > > There are two interesting discussion on stockoverflow [2][3]. But btw > I disagree with Tall Jeff [3] says "The difference between a recursive > and non-recursive mutex has to do with ownership. " I think he > confuses a simple-mutex and binary-semaphore, as do a some commenters. > > "Prefer Simple Mutex Over Recursive Mutex" [4] demonstrates some > performance considerations and advises "a recursive mutex is dangerous > because you lose sense of locking scope. It costs more than a simple > mutex." > > "Recursive Locks Will Kill You!" [5] provides some thread safety > guidelines. > > Finally, there is a paper "Ad Hoc Synchronization Considered harmful" > [6], which I haven't read yet since I wanted to get this post out > before heading to bed, but I hope to tomorrow. > > > [1] http://www.zaval.org/resources/library/butenhof1.html > [2] http://stackoverflow.com/questions/2415082/when-to-use-recursive-mutex > [3] > http://stackoverflow.com/questions/187761/recursive-lock-mutex-vs-non-recur… > [4] > http://askldjd.com/2009/10/26/prefer-simple-mutex-over-recursive-mutex/ > [5] > http://www.fieryrobot.com/blog/2008/10/14/recursive-locks-will-kill-you/ > [6] https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Xiong.pdf > > > So our existing Mutex implementation happens to be recursive, and I'm > not suggesting we change that. However if we should consider *not* > baking the *assumption* of recursion into the primitives, so the same > primitives could *also* be used for a SimpleMutex class. The logic to > provide recursion for Mutex is only [ owner = activeProcess ] which is > easily done in-image. > > So I propose introducing aquire/release primitives based off the > existing critical section primitives with the recursion removed. > We have two sets of primitives, the queueing semaphore ones, signal and wait, #85 & #86, which are not recursive, and new ones, #185, #186 & #187 that support ownership, and hence support recursion. It makes no sense to remove the recursion support. That's what the primitives are for, to provide ownership support as efficiently as possible. Please don't be led by the problems others may have in other systems, and instead be led by how we're doing. Squeak and Pharo (and Smalltalk) have had recursive owned critical sections for decades and no one (e.g. from demanding industrial control applications) has complained that these recursive critical sections are problematic. Remember we have closures and hence ensure: and good unwinding support. The new primitives give us a streamlined and hack-free implementation which doesn't depend on the niceties of what are suspension points as do the pre-primitive implementations. So I see no rationale for gelding these primitives. Show me a paper on a Smalltalk app that says "recursive locks will kill you" and I'll reconsider, but in thirty years I've not seen a complaint. The complaints I have seen are - queueing Semaphores should or should not be priority queues, depending on requirements. In VW #85 & #86 were changed so that Semaphore is a priority queue. This has been good for some folks but bad for others. One should have the choice, but the current Squeak/Pharo/Smalltalk-80 default that they are /not/ priority queues is the right default - we suffer from deadlock due to priority inversion. A high-priority process spinning trying to gain access to a lock held by a low-priority process can shut out the low-priority process from releasing its lock. This is minimised by the new recursive lock primitives, but may still be a possibility. We should work on creating test cases. Positively the test cases that Andreas developed for me at Qwaq when I developed the recursive locking primitives no longer fail. I've not had time to investigate. - preempting a lower-priority process by a higher-priority process causes the preempted process to yield to others at the same priority. This is a bug which has been fixed in VW and in Cog. It is an option in Cog but it should be enabled. See SmalltalkImage>>processPreemptionYields. Smalltalk processPreemptionYields should answer false. cheers -ben > HTH _,,,^..^,,,_ best, Eliot

Feb. 2, 2016

Re: [Pharo-dev] SessionManager (aka new startup / shutdown list manager) needs testers

by Aliaksei Syrel

UIManagerSessionHandler>>#startup: isImageStarting "Install the right UIManager" UIManager default: UIManager forCurrentSystemConfiguration. Setting (overring current one) default UIManager each time image is saved/started up prevents us from having custom UIManagers, for example Bloc UI manager On Tue, Feb 2, 2016 at 7:04 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > When deleting a class I get deprecation in #50561 in > SystemDictionary>>#forgetClass: aClass logged: aBool because > of removeFromStartUpList: > > > Cheers, > Alex > > On Sat, Dec 5, 2015 at 2:39 PM, Christophe Demarey < > christophe.demarey(a)inria.fr> wrote: > >> >> >> ------------------------------ >> >> *De: *"Nicolai Hess" <nicolaihess(a)gmail.com> >> *Ã: *"Pharo Development List" <pharo-dev(a)lists.pharo.org> >> *EnvoyÃ©: *Vendredi 4 DÃ©cembre 2015 22:05:26 >> *Objet: *Re: [Pharo-dev] SessionManager (aka new startup / shutdown list >> manager) needs testers >> >> >> Looks good. What are the main critical startup/shutdown users( classes) >> that should be tested? >> >> Classes using startup or/and shutdown are >> >> #SmallInteger >> #Delay atPriority >> #ProcessorScheduler >> #InputEventFetche >> #InputEventFetcher >> #OSPlatfor >> #Stdio >> #LanguageEnvironment >> #ShortIntegerArray >> #DiskStore >> #SmalltalkImage >> #WeakFinalizationList >> #Clipboard >> #MCMethodDefinition >> #Symbol >> #Locale >> #MultiByteFileStream >> #WeakArray >> #FileStream >> #FileLocator >> #BasicCommandLineHandler >> #NonInteractiveTranscript >> #ASTCache >> #OSEnvironment >> #EndianDetector >> #InternetConfiguration >> #ZnServer >> #MCGitHubRepository >> #ZnLogEvent >> #DisplayScreen >> #InputEventSensor >> #Cursor >> #Form >> #StrikeFont >> #Color >> #FreeTypeCache >> #LogicalFont >> #FT2Handle >> #FreeTypeSettings >> #WorldMorph >> #CPUWatcher >> #NOCCompletionTable >> #Nautilus >> #PharoCommonTools >> #GTPlayBook >> >> Also sensitive code could be the one using the session (Smalltalk >> session) to check if they need to free or reset some resources. >> >> Thanks to have a look at it, >> Christophe >> >> >> I did some tests with AthensSceneView (uses NB and calls Smalltalk >> session for reinit external resources) and Roassal. >> I got one image startup failure, but I couldn't reproduce it yet. Maybe I >> did image save and image save and quit, too quick. >> >> >

Feb. 2, 2016

Re: [Pharo-dev] SessionManager (aka new startup / shutdown list manager) needs testers

by Aliaksei Syrel

When deleting a class I get deprecation in #50561 in SystemDictionary>>#forgetClass: aClass logged: aBool because of removeFromStartUpList: Cheers, Alex On Sat, Dec 5, 2015 at 2:39 PM, Christophe Demarey < christophe.demarey(a)inria.fr> wrote: > > > ------------------------------ > > *De: *"Nicolai Hess" <nicolaihess(a)gmail.com> > *Ã: *"Pharo Development List" <pharo-dev(a)lists.pharo.org> > *EnvoyÃ©: *Vendredi 4 DÃ©cembre 2015 22:05:26 > *Objet: *Re: [Pharo-dev] SessionManager (aka new startup / shutdown list > manager) needs testers > > > Looks good. What are the main critical startup/shutdown users( classes) > that should be tested? > > Classes using startup or/and shutdown are > > #SmallInteger > #Delay atPriority > #ProcessorScheduler > #InputEventFetche > #InputEventFetcher > #OSPlatfor > #Stdio > #LanguageEnvironment > #ShortIntegerArray > #DiskStore > #SmalltalkImage > #WeakFinalizationList > #Clipboard > #MCMethodDefinition > #Symbol > #Locale > #MultiByteFileStream > #WeakArray > #FileStream > #FileLocator > #BasicCommandLineHandler > #NonInteractiveTranscript > #ASTCache > #OSEnvironment > #EndianDetector > #InternetConfiguration > #ZnServer > #MCGitHubRepository > #ZnLogEvent > #DisplayScreen > #InputEventSensor > #Cursor > #Form > #StrikeFont > #Color > #FreeTypeCache > #LogicalFont > #FT2Handle > #FreeTypeSettings > #WorldMorph > #CPUWatcher > #NOCCompletionTable > #Nautilus > #PharoCommonTools > #GTPlayBook > > Also sensitive code could be the one using the session (Smalltalk session) > to check if they need to free or reset some resources. > > Thanks to have a look at it, > Christophe > > > I did some tests with AthensSceneView (uses NB and calls Smalltalk session > for reinit external resources) and Roassal. > I got one image startup failure, but I couldn't reproduce it yet. Maybe I > did image save and image save and quit, too quick. > >

Feb. 2, 2016

Simple versus Recursive Mutexes

by Ben Coman

While we are in the process of revising the Mutex infrastructure [1] to use dedicated primitives rather than rely on counting via a semaphore, I want to raise the question of simple versus recursive mutexes. This isn't something I know much about, except that some people strongly believe recursive mutexes are evil, including David Butenhof who apparently was the guy who added recursive mutexes to POSIX "on a dare [...] but nobody was supposed to use recursive mutexes." [1]. There are two interesting discussion on stockoverflow [2][3]. But btw I disagree with Tall Jeff [3] says "The difference between a recursive and non-recursive mutex has to do with ownership. " I think he confuses a simple-mutex and binary-semaphore, as do a some commenters. "Prefer Simple Mutex Over Recursive Mutex" [4] demonstrates some performance considerations and advises "a recursive mutex is dangerous because you lose sense of locking scope. It costs more than a simple mutex." "Recursive Locks Will Kill You!" [5] provides some thread safety guidelines. Finally, there is a paper "Ad Hoc Synchronization Considered harmful" [6], which I haven't read yet since I wanted to get this post out before heading to bed, but I hope to tomorrow. [1] http://www.zaval.org/resources/library/butenhof1.html [2] http://stackoverflow.com/questions/2415082/when-to-use-recursive-mutex [3] http://stackoverflow.com/questions/187761/recursive-lock-mutex-vs-non-recur… [4] http://askldjd.com/2009/10/26/prefer-simple-mutex-over-recursive-mutex/ [5] http://www.fieryrobot.com/blog/2008/10/14/recursive-locks-will-kill-you/ [6] https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Xiong.pdf So our existing Mutex implementation happens to be recursive, and I'm not suggesting we change that. However if we should consider *not* baking the *assumption* of recursion into the primitives, so the same primitives could *also* be used for a SimpleMutex class. The logic to provide recursion for Mutex is only [ owner = activeProcess ] which is easily done in-image. So I propose introducing aquire/release primitives based off the existing critical section primitives with the recursion removed. cheers -ben

Feb. 2, 2016

[pharo-project/pharo-core] f4f863: 50564

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: f4f863290b523e16e752edd74d9b4e1e133ea9f9 https://github.com/pharo-project/pharo-core/commit/f4f863290b523e16e752edd7… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-02-02 (Tue, 02 Feb 2016) Changed paths: M NautilusRefactoring.package/NautilusRefactoring.class/instance/performing/performRefactorings_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50563.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50564.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50563.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50564.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50564 17366 wrong TempsNamesQCompress method trailer ? https://pharo.fogbugz.com/f/cases/17366 17406 Renaming a class using the class menu "rename" option allows for non-capitalized class name https://pharo.fogbugz.com/f/cases/17406 http://files.pharo.org/image/50/50564.zip

Feb. 2, 2016

[pharo-project/pharo-core]

by GitHub

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

Feb. 2, 2016