February 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Contributing to Pharo

by Thierry Goubier

Le 02/02/2016 21:56, Eliot Miranda a Ã©crit : > > > On Tue, Feb 2, 2016 at 11:38 AM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > > > 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 > <mailto:dale.henrichs@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 ... > > > Please tell me this isn't about line endings? Why can't the version > history be written with lf line endings? That's hardly a bone of > contention is it? No, it's a lot more complex than that. It's simply hard to do a merge-able text log format. Git also makes a mess of json / ston files, simply because they are structured data in what appears to be text files, git treat them as text files, and three-way line by line merging does not work. The only hope you can have is to make a format which is easier for a human to correct when git creates a conflict when merging ... in short, something which would only make it easier as long as the history is limited to 50 versions and a single developper :( Now, given how much cleaner, safer and sound is extracting that data from the dvcs log, I'll never bother with that sort of things again. Thierry

Feb. 2, 2016

Re: [Pharo-dev] Contributing to Pharo

by Eliot Miranda

On Tue, Feb 2, 2016 at 11:38 AM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > > > 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 ... Please tell me this isn't about line endings? Why can't the version history be written with lf line endings? That's hardly a bone of contention is it? _,,,^..^,,,_ best, Eliot

Feb. 2, 2016

Re: [Pharo-dev] Contributing to Pharo

by Eliot Miranda

Hi Dale, On Tue, Feb 2, 2016 at 11:35 AM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > > > 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 .... > No it's /not/ the end of the story. The essential part of the story is how Monticello remains compatible and interoperable between dialects. I haven't seen you account for how you maintain that compatibility. As far as I can tell, you propose replacing the Monticello metadata with that from git. How do I, as a Squeak user with Monticello, ever get to look at your package again? As I understand it, moving the metadata from Monticello commit time to git means that the metadata is in a format that git determines, not Monticello. So I don't understand how on the one hand you can say "The Monticello metadata in a git repository is redundant and leads to unnecessary commit conflicts -- end of story ....", which implies you want to eliminate the Monticello metadata, and on the other hand you say you're keeping the Monticello metadata. I'm hopelessly confused. How does the Monticello metadata get reconstituted if it's been thrown away? What happens to the metadata in the following workflow? load package P from Monticello repository R into an image change P, commit via git to local git repository G load P from G into an image store P to R via Monticello 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 ... > Then forgive me. I couldn't see the wood for the trees. When I read your talk of eliminating the conflicts from git commits due to the Monticello metadata I infer that you're eliminating the Monticello metadata. I'm not sure I understand the implications of this, but it seems to me that a natural consequence is that the Montivcello metadata is lost and at that point merges and the like become problematic. What am I missing? > > 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? > Yes. > > 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 ... > But what does this imply to some package that starts off in a Monticello repository and then spends some time in gitland? Can I merge again? If I can I'm happy. If I can't, I feel sabotaged. > 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:) Fine. Except merging is, IIUC, about method time stamps and ancestry. If that gets preserved then I'm happy. But for the life of me I haven't read an explanation that reassures me that these are being preserved. Do you see the roots of my fear? Dale > _,,,^..^,,,_ confused, Eliot

Feb. 2, 2016

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