August 2015 - Pharo-dev - lists.pharo.org

Working Directory and FileSystem

by Guillermo Polito

(I cc the VM dev as this topic touches a bit the VM) Hi, chasing a bug I found that FileSystem does not handle well the working directory of the system. The working directory of a process is the directory from where we started the process. That is, the directory from where we launched the VM with the image. However, FileSystem has two problems with this: 1) it believes that the workingDirectory is where the image *is* and not where it was open. (Check: FileSystem workingDirectory). 2) if you try to use a relative file name FileSystem will use the working directory he believes instead of letting the primitive do his job. (Just open your image from another directory and do 'asd.txt' asFileReference fullName). This problem becomes apparent when you use the launcher, or when you launch your image from other directory. Now, I was checking with Santi how to obtain the working directory of the process and we saw that there are two primitives """"included""" in the VM as part of the OSProcess plugins to do it (Included as they are in the PharoVM build). <primitive: 'primitiveGetCurrentWorkingDirectory' module: 'Win32OSProcessPlugin' > AND <primitive: 'primitiveGetCurrentWorkingDirectory' module: 'UnixOSProcessPlugin' > So I'd like to propose: - include those primitives in the default VM (as we already have the ones to get the image file path and the vm file path). - Add methods calling those primitives in OSPlatform and subclasses - Change FileSystem to have the working directory work as expected. What do you think? Guille

Aug. 26, 2015

Re: [Pharo-dev] Strange Validation with issue 15820

by Guillermo Polito

Ok, so we found the bug: The working directory of a process is the directory from where we started the process. That is, the directory from where we launched the VM with the image. Then, when we create a file without specifying a directory (that is, in a relative way), that file will be created in the working directory. However, FileSystem has two problems 1) it believes that the workingDirectory is where the image *is* and not where it was open. (Check FileSystem workingDirectory). 2) if you try to use a relative file name FileSystem will for you the working directory he believes instead of letting the primitive do his job. (Just open your image from another directory and do 'asd.txt' asFileReference fullName). So the fix to the test was: do not mix FileSystem with the low level File API. I'll open a new thread discussing about the working directory. Guille El mar., 25 de ago. de 2015 a la(s) 7:22 p. m., Ben Coman < btc(a)openinworld.com> escribiÃ³: > On Tue, Aug 25, 2015 at 11:30 PM, Guillermo Polito > <guillermopolito(a)gmail.com> wrote: > > Hi, > > > > We have an issue that is platform dependent (file-related): > > > > https://pharo.fogbugz.com/f/cases/15820/Better-File-API > > > > Now, we tested with Nicolai in Windows, Mac and Linux and we had all > tests > > green. However, the monkey does not seem to want to be green. > > > > - Would anyone have an idea of what should be disturbing the monkey? > > No ideas, except if you can't isolate it, maybe its possible to SSH > into the CI server, map VNC ports back to your local machine and debug > the image on the CI server. > > cheers -ben > > > - Can people in different linuxes/unixes test the slice just to make > sure we > > are on the right path? (that is, load the slice and run the tests in the > > File package). > > > > Thanks a lot, > > Guille > >

Aug. 26, 2015

Re: [Pharo-dev] [ann] brick on top of bloc - preview

by stepharo

Excellent Two questions: Doru recently we (franck on a keyboard) played with the data source model of (mac) of FastTable. We are building a list with a search that displays only the matching element. This is interesting to see that we just have to provide a different (more elaborate datasource). We can show you a bit what we did. I was again rethinking how to compose/reuse logic (basically rethinking Spec ideas). The tension is that when we use composable models we by construction limit the functionality that can be composed. For example, it is difficult to expose all the behavior of rubric without explosing the API of Text. Now if we use directly widgets then how can we reuse the logic of the composition Alain started to brainstorm about it in calypso and I would like to discuss deeper this point. Stef I did not see email in the bloc mailing-list. Are you using it? I would be interested to see some discussions because I have a lot of little details that I came accross building "simple" UI and I would love to see how Brick handle them. > Hi, > > We are happy to announce the first preview version of Brick, a new > widget set created from scratch on top of Bloc. > > Brick is being developed primarily by Alex Syrel (together with Alain > Plantec, Andrei Chis and myself), and the work is sponsored by ESUG. > Brick is part of the Glamorous Toolkit effort and will provide the > basis for the new versions of the development tools. > > Brick's goal is to provide a beautiful looking widget set, and the > default look is based on material design. The widgets are theme-able. > > Right now, there exists: > - Label > - Simple button > - Toggle button > - Checkbox > - Radio button > - Window with or without an active title bar that can include various > visual actions and info > - Menu > - Beautiful scrollbars that are thin by default and enlarge when the > mouse hovers over it > - Scalable list for huge amounts of items with various heights > (The list also allows one for embedding text widgets with in place > editing) > > The next immediate target is the creation of a new Pager widget (the > widget that is behind the current GTInspector). > > You can see some screenshots on the official site: > http://gt.moosetechnology.org/brick > > To play with it, you can download a ready-made image: > https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/gtoolk… > > and, in a Bloc space, you can browse the examples: > BrExampleBrowser exampleOpen > > We would be happy to hear your feedback. > > Cheers, > Doru > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Aug. 26, 2015

Re: [Pharo-dev] [Pharo-users] [ann] brick on top of bloc - preview

by Marcus Denker

> On 26 Aug 2015, at 10:58, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > > Loading traits only is working, there are traits in Moose and it is well working... > E.g.: > Trait named: #TOODependencyQueries > uses: TDependencyQueries > category: 'Famix-Coreâ > Yes, but there it might not fall back on loading the .st file but instead de-seriaize the MC model. > Vincent > > -----Message d'origine----- > De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part de Marcus Denker > EnvoyÃ© : mercredi 26 aoÃ»t 2015 10:52 > Ã : Any question about pharo is welcome > Cc : Pharo Development List > Objet : Re: [Pharo-users] [ann] brick on top of bloc - preview > > >> On 26 Aug 2015, at 10:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Aha. Thanks for the help, Vincent. >> >> Now, the next problem: Does anyone know why the "Unrecognized class definition" problem occurs? :) >> > > It seems that > > 1) MC model loading of the serialised package fails > 2) it falls back on using MCStReader > 3) which fails to load the .st file for the definition of TBlLayoutPropertiesOwner > > Maybe loading trait definitions does not work in general with MCStReader? > > Marcus > > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. >

Aug. 26, 2015

Re: [Pharo-dev] [Pharo-users] [ann] brick on top of bloc - preview

by Blondeau Vincent

Loading traits only is working, there are traits in Moose and it is well working... E.g.: Trait named: #TOODependencyQueries uses: TDependencyQueries category: 'Famix-Core' Vincent -----Message d'origine----- De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part de Marcus Denker EnvoyÃ© : mercredi 26 aoÃ»t 2015 10:52 Ã : Any question about pharo is welcome Cc : Pharo Development List Objet : Re: [Pharo-users] [ann] brick on top of bloc - preview > On 26 Aug 2015, at 10:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Aha. Thanks for the help, Vincent. > > Now, the next problem: Does anyone know why the "Unrecognized class definition" problem occurs? :) > It seems that 1) MC model loading of the serialised package fails 2) it falls back on using MCStReader 3) which fails to load the .st file for the definition of TBlLayoutPropertiesOwner Maybe loading trait definitions does not work in general with MCStReader? Marcus Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

Aug. 26, 2015

Re: [Pharo-dev] [Pharo-users] [ann] brick on top of bloc - preview

by Marcus Denker

> On 26 Aug 2015, at 10:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Aha. Thanks for the help, Vincent. > > Now, the next problem: Does anyone know why the "Unrecognized class definition" problem occurs? :) > It seems that 1) MC model loading of the serialised package fails 2) it falls back on using MCStReader 3) which fails to load the .st file for the definition of TBlLayoutPropertiesOwner Maybe loading trait definitions does not work in general with MCStReader? Marcus

Aug. 26, 2015

Re: [Pharo-dev] [Pharo-users] [ann] brick on top of bloc - preview

by Tudor Girba

Aha. Thanks for the help, Vincent. Now, the next problem: Does anyone know why the "Unrecognized class definition" problem occurs? :) Cheers, Doru On Wed, Aug 26, 2015 at 9:14 AM, Vincent BLONDEAU < vincent.blondeau(a)polytech-lille.net> wrote: > Now that the Moose 6.0 job is working, the last build of Pharo is used and > the problem appears in the CI... > > Vincent > > -----Message d'origine----- > De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part > de Alexandre Bergel > EnvoyÃ© : mercredi 26 aoÃ»t 2015 01:02 > Ã : Any question about pharo is welcome > Objet : Re: [Pharo-users] [ann] brick on top of bloc - preview > > Wowâ¦ > > Alexandre > > > > On Aug 25, 2015, at 6:41 PM, Vincent BLONDEAU < > vincent.blondeau(a)polytech-lille.net> wrote: > > > > That is because GToolkit is based on last successful Moose 6.0 build > where everything works fine (it is Pharo50248). > > But less than a week ago, a featured bug was integrated in Pharo and it > is not possible to load Moose anymoreâ¦ That is due to some encoding > problems during Monticello loading between 50256 and 50257 Pharo versions > (integration of Slice 16283). > > > > As I canât load brick on the 50256 pharo image, I think that the bug you > encounter has been introduced before, i.e. between 50248 and 50256. So it > is not related to the Moose one. > > Bernardoâs bug is related to traits loading, I have the same bug for one > of my project but I didnât investigate it yet. > > > > Cheers, > > Vincent > > > > De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la > > part de Tudor Girba EnvoyÃ© : mardi 25 aoÃ»t 2015 23:08 Ã : Any question > > about pharo is welcome Objet : Re: [Pharo-users] [ann] brick on top of > > bloc - preview > > > > Hmm. Thanks for the report. Indeed, I get the same, but the CI job works > well. We will have to investigate this. > > > > In the meantime, you can use the image from: > > https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/g > > toolkit5.zip > > > > Cheers, > > Doru > > > > > > > > On Tue, Aug 25, 2015 at 10:51 PM, Bernardo Ezequiel Contreras < > vonbecmann(a)gmail.com> wrote: > >> i forgot to mention that it was while > >> > >> Loading Bloc-Core-AliakseiSyrel.636 > >> > >> thanks > >> > >> > >> > >> On Tue, Aug 25, 2015 at 5:43 PM, Bernardo Ezequiel Contreras < > vonbecmann(a)gmail.com> wrote: > >>> Sorry, but after evaluating > >>> > >>> Gofer new > >>> smalltalkhubUser: 'Pharo' project: 'Brick'; configuration; > >>> loadDevelopment > >>> > >>> in Pharo5.0#50270, i got an Error: Unrecognized class definition > >>> > >>> The screenshots look really cool. > >>> > >>> thanks > >>> > >>> > >>> On Tue, Aug 25, 2015 at 5:13 PM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >>>> Hi, > >>>> > >>>> We are happy to announce the first preview version of Brick, a new > widget set created from scratch on top of Bloc. > >>>> > >>>> Brick is being developed primarily by Alex Syrel (together with Alain > Plantec, Andrei Chis and myself), and the work is sponsored by ESUG. Brick > is part of the Glamorous Toolkit effort and will provide the basis for the > new versions of the development tools. > >>>> > >>>> Brick's goal is to provide a beautiful looking widget set, and the > default look is based on material design. The widgets are theme-able. > >>>> > >>>> Right now, there exists: > >>>> - Label > >>>> - Simple button > >>>> - Toggle button > >>>> - Checkbox > >>>> - Radio button > >>>> - Window with or without an active title bar that can include > >>>> various visual actions and info > >>>> - Menu > >>>> - Beautiful scrollbars that are thin by default and enlarge when > >>>> the mouse hovers over it > >>>> - Scalable list for huge amounts of items with various heights (The > >>>> list also allows one for embedding text widgets with in place > >>>> editing) > >>>> > >>>> The next immediate target is the creation of a new Pager widget (the > widget that is behind the current GTInspector). > >>>> > >>>> You can see some screenshots on the official site: > >>>> http://gt.moosetechnology.org/brick > >>>> > >>>> To play with it, you can download a ready-made image: > >>>> https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifac > >>>> t/gtoolkit5.zip > >>>> > >>>> and, in a Bloc space, you can browse the examples: > >>>> BrExampleBrowser exampleOpen > >>>> > >>>> We would be happy to hear your feedback. > >>>> > >>>> Cheers, > >>>> Doru > >>>> > >>>> -- > >>>> www.tudorgirba.com > >>>> > >>>> "Every thing has its own flow" > >>> > >>> > >>> > >>> -- > >>> Bernardo E.C. > >>> > >>> Sent from a cheap desktop computer in South America. > >> > >> > >> > >> -- > >> Bernardo E.C. > >> > >> Sent from a cheap desktop computer in South America. > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 26, 2015

[review needed] speed up RBClassNotReferencedRule

by Marcus Denker

Hi, Review needed for https://pharo.fogbugz.com/f/cases/16074/Is-RBClassNotReferencedRule-200x-sl… Speedup can be checked with: rule:=RBClassNotReferencedRule new. environment:=RBBrowserEnvironment new forPackageNames: #('Fuel'). [RBSmalllintChecker runRule: rule onEnvironment: environment] timeToRun Pharo5: "0:00:00:13.526" Pharo5 with fix: "0:00:00:00.761" Pharo3: 0:00:00:00.547 Checking all classes for usage: [Smalltalk allClassesAndTraits select: [ : each | each isUsed not]] timeToRun still takes 1:40 to find 600 unused classes. This shows that adding a cache for âreferenced classesâ per environment would speed this up further. But it should be general, not just for RB or even RB Code Critique. The nice things is that code environments only change when you add classes or methods, so adding a very general cache should be quite possible. Another thing we should add is a way for classes to define âI am usedâ. E.g this now finds all Configurations, all the Manifests and all cases like the RB Rules themselves. All these should know that they are not useless even though there are no references. Marcus

Aug. 26, 2015

Re: [Pharo-dev] [Pharo-users] [ann] brick on top of bloc - preview

by Vincent BLONDEAU

Now that the Moose 6.0 job is working, the last build of Pharo is used and the problem appears in the CI... Vincent -----Message d'origine----- De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part de Alexandre Bergel EnvoyÃ© : mercredi 26 aoÃ»t 2015 01:02 Ã : Any question about pharo is welcome Objet : Re: [Pharo-users] [ann] brick on top of bloc - preview Wowâ¦ Alexandre > On Aug 25, 2015, at 6:41 PM, Vincent BLONDEAU <vincent.blondeau(a)polytech-lille.net> wrote: > > That is because GToolkit is based on last successful Moose 6.0 build where everything works fine (it is Pharo50248). > But less than a week ago, a featured bug was integrated in Pharo and it is not possible to load Moose anymoreâ¦ That is due to some encoding problems during Monticello loading between 50256 and 50257 Pharo versions (integration of Slice 16283). > > As I canât load brick on the 50256 pharo image, I think that the bug you encounter has been introduced before, i.e. between 50248 and 50256. So it is not related to the Moose one. > Bernardoâs bug is related to traits loading, I have the same bug for one of my project but I didnât investigate it yet. > > Cheers, > Vincent > > De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la > part de Tudor Girba EnvoyÃ© : mardi 25 aoÃ»t 2015 23:08 Ã : Any question > about pharo is welcome Objet : Re: [Pharo-users] [ann] brick on top of > bloc - preview > > Hmm. Thanks for the report. Indeed, I get the same, but the CI job works well. We will have to investigate this. > > In the meantime, you can use the image from: > https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/g > toolkit5.zip > > Cheers, > Doru > > > > On Tue, Aug 25, 2015 at 10:51 PM, Bernardo Ezequiel Contreras <vonbecmann(a)gmail.com> wrote: >> i forgot to mention that it was while >> >> Loading Bloc-Core-AliakseiSyrel.636 >> >> thanks >> >> >> >> On Tue, Aug 25, 2015 at 5:43 PM, Bernardo Ezequiel Contreras <vonbecmann(a)gmail.com> wrote: >>> Sorry, but after evaluating >>> >>> Gofer new >>> smalltalkhubUser: 'Pharo' project: 'Brick'; configuration; >>> loadDevelopment >>> >>> in Pharo5.0#50270, i got an Error: Unrecognized class definition >>> >>> The screenshots look really cool. >>> >>> thanks >>> >>> >>> On Tue, Aug 25, 2015 at 5:13 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> Hi, >>>> >>>> We are happy to announce the first preview version of Brick, a new widget set created from scratch on top of Bloc. >>>> >>>> Brick is being developed primarily by Alex Syrel (together with Alain Plantec, Andrei Chis and myself), and the work is sponsored by ESUG. Brick is part of the Glamorous Toolkit effort and will provide the basis for the new versions of the development tools. >>>> >>>> Brick's goal is to provide a beautiful looking widget set, and the default look is based on material design. The widgets are theme-able. >>>> >>>> Right now, there exists: >>>> - Label >>>> - Simple button >>>> - Toggle button >>>> - Checkbox >>>> - Radio button >>>> - Window with or without an active title bar that can include >>>> various visual actions and info >>>> - Menu >>>> - Beautiful scrollbars that are thin by default and enlarge when >>>> the mouse hovers over it >>>> - Scalable list for huge amounts of items with various heights (The >>>> list also allows one for embedding text widgets with in place >>>> editing) >>>> >>>> The next immediate target is the creation of a new Pager widget (the widget that is behind the current GTInspector). >>>> >>>> You can see some screenshots on the official site: >>>> http://gt.moosetechnology.org/brick >>>> >>>> To play with it, you can download a ready-made image: >>>> https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifac >>>> t/gtoolkit5.zip >>>> >>>> and, in a Bloc space, you can browse the examples: >>>> BrExampleBrowser exampleOpen >>>> >>>> We would be happy to hear your feedback. >>>> >>>> Cheers, >>>> Doru >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>> >>> >>> >>> -- >>> Bernardo E.C. >>> >>> Sent from a cheap desktop computer in South America. >> >> >> >> -- >> Bernardo E.C. >> >> Sent from a cheap desktop computer in South America. > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 26, 2015

[pharo-project/pharo-core] 3bb420: 50271

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 3bb4203ad985bc9426b19cfe1a4a90ee7ef75064 https://github.com/pharo-project/pharo-core/commit/3bb4203ad985bc9426b19cfe… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-26 (Wed, 26 Aug 2015) Changed paths: M Komitter.package/KomitterUI.class/instance/initialization/initializeLatelyPresenter.st M Komitter.package/KomitterUI.class/instance/initialization/initializeWidgets.st A Komitter.package/KomitterUI.class/instance/private/refreshDiffForItem_.st M Morphic-Base.package/extension/GradientFillStyle/instance/changeColorOf_rampIndex_.st R Nautilus.package/AbstractNautilusUI.class/class/menu/debugMenu_.st M Nautilus.package/AbstractNautilusUI.class/instance/group announcements/aGroupHasBeenAdded_.st M Nautilus.package/AbstractNautilusUI.class/instance/group announcements/aGroupHasBeenRemoved_.st R Nautilus.package/Nautilus.class/class/accessing/historyMaxSize.st R Nautilus.package/Nautilus.class/class/accessing/historyMaxSize_.st R Nautilus.package/Nautilus.class/class/accessing/maxSize.st R Nautilus.package/Nautilus.class/class/accessing/maxSize_.st R Nautilus.package/Nautilus.class/class/accessing/openOnGroups.st R Nautilus.package/Nautilus.class/class/accessing/openOnGroups_.st M Nautilus.package/Nautilus.class/class/accessing/resetGroups.st R Nautilus.package/Nautilus.class/class/accessing/showAnnotationPane_.st M Nautilus.package/Nautilus.class/class/opening/openInEnvironment_.st M Nautilus.package/Nautilus.class/class/opening/openOnClass_inEnvironment_.st M Nautilus.package/Nautilus.class/class/opening/openOnClass_onProtocol_inEnvironment_.st M Nautilus.package/Nautilus.class/class/opening/openOnMethod_inEnvironment_.st R Nautilus.package/Nautilus.class/class/settings/commentPosition.st R Nautilus.package/Nautilus.class/class/settings/commentPosition_.st R Nautilus.package/Nautilus.class/class/settings/commentPositions.st R Nautilus.package/Nautilus.class/class/settings/emptyCommentWarning_.st M Nautilus.package/Nautilus.class/class/settings/nautilusSettingsOn_.st R Nautilus.package/Nautilus.class/class/settings/showDebugMenus.st R Nautilus.package/Nautilus.class/class/settings/showDebugMenus_.st R Nautilus.package/Nautilus.class/class/settings/showGroupsOnTop.st R Nautilus.package/Nautilus.class/class/settings/showGroupsOnTop_.st R Nautilus.package/Nautilus.class/class/settings/switchClassesAndPackages.st R Nautilus.package/Nautilus.class/class/settings/switchClassesAndPackages_.st M Nautilus.package/Nautilus.class/definition.st R Nautilus.package/Nautilus.class/instance/accessing/commentPosition.st R Nautilus.package/Nautilus.class/instance/accessing/switchClassesAndPackages.st R Nautilus.package/Nautilus.class/instance/browser compatibility/openEditString_.st M Nautilus.package/Nautilus.class/instance/browser compatibility/spawnHierarchy.st M Nautilus.package/Nautilus.class/instance/browser compatibility/spawnHierarchyForClass_selector_.st R Nautilus.package/Nautilus.class/instance/history/removeLastHistoryEntry.st R Nautilus.package/Nautilus.class/instance/private/packagesUsedByTheSelectedClass.st R Nautilus.package/Nautilus.class/instance/private/shouldOpenOnGroups.st M Nautilus.package/PackageTreeModel.class/instance/accessing/rootNodes.st R Nautilus.package/PackageTreeNautilusUI.class/instance/accessing/groupsAreVisible.st R NautilusCommon.package/NautilusHistoryEntryWithSourceCode.class/README.md R NautilusCommon.package/NautilusHistoryEntryWithSourceCode.class/class/instance creation/with_sourceCode_.st R NautilusCommon.package/NautilusHistoryEntryWithSourceCode.class/definition.st R NautilusCommon.package/NautilusHistoryEntryWithSourceCode.class/instance/accessing/sourceCode.st R NautilusCommon.package/NautilusHistoryEntryWithSourceCode.class/instance/accessing/sourceCode_.st R NautilusCommon.package/NautilusHistoryEntryWithSourceCode.class/instance/protocol/applyTo_.st R NautilusCommon.package/NautilusHistoryEntryWithSourceCode.class/instance/protocol/asHistoryString.st A Polymorph-Widgets.package/MorphicUIManager.class/instance/accessing/theme.st A Polymorph-Widgets.package/MorphicUIManager.class/instance/ui requests/chooseOrRequestFrom_title_.st A Polymorph-Widgets.package/MorphicUIManager.class/instance/ui requests/enterOrRequestFrom_title_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50270.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50271.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50270.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50271.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Shout.package/SHPreferences.class/class/settings/styleTableRow.st M Tools.package/SyntaxErrorDebugger.class/class/instance creation/buildMorphicViewOn_.st M Tools.package/SyntaxErrorDebugger.class/definition.st A Tools.package/SyntaxErrorDebugger.class/instance/accessing/announcer.st M Tools.package/SyntaxErrorDebugger.class/instance/accessing/codePaneMenu_shifted_.st A Tools.package/SyntaxErrorDebugger.class/instance/accessing/model.st R Tools.package/SyntaxErrorDebugger.class/instance/accessing/shiftedYellowButtonMenu.st R Tools.package/SyntaxErrorDebugger.class/instance/accessing/yellowButtonMenu.st M Tools.package/SyntaxErrorDebugger.class/instance/other/contents_notifying_.st M UIManager.package/ManifestUIManager.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st R UIManager.package/UIManager.class/instance/accessing/theme.st R UIManager.package/UIManager.class/instance/ui requests/chooseOrRequestFrom_title_.st R UIManager.package/UIManager.class/instance/ui requests/enterOrRequestFrom_title_.st Log Message: ----------- 50271 16385 Clean a lot of dead code and unused class variables in Nautilus https://pharo.fogbugz.com/f/cases/16385 16382 Remove PluggableTextMorph reference in SyntaxErrorDebugger https://pharo.fogbugz.com/f/cases/16382 16378 Highlighting code in Komitter https://pharo.fogbugz.com/f/cases/16378 16190 UIManager should not depends on Polymorph-Widgets https://pharo.fogbugz.com/f/cases/16190 http://files.pharo.org/image/50/50271.zip

Aug. 26, 2015