- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Launcher Issues

by Damien Cassou

Sean P. DeNigris <sean(a)clipperadams.com> writes: > For "Issue 16115: Launcher: Update Common Tools for Moose 5.1 Release" > (https://pharo.fogbugz.com/default.asp?16115) the fix has been picked up by > the CI and I verified that it works. What is the process here? Shall I close > the issue with something like "in build #51"? I released 0.2.8 from your code. Thanks. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Aug. 8, 2015

System Windows not closing on using #close

by Jigyasa Grover

Hi I am using *SystemWindow* to open a Morph in my application *searchQuick*. ( https://github.com/jig08/sQuick_new ) On clicking a button, a new screen opens up but the prev window fails to close, though I have tried using #close methods. The code snippets are as: *------------------------------------------------------------------------------------------------------------------* *IndexInterface>>**#initialize* *. . . . . .* * boxWindow := SystemWindow new.* * box position: 150(a)0.* * boxWindow addMorph: box.* * boxWindow extent: World extent.* * boxWindow openInWindowLabeled: 'searchQuick'.* * boxWindow fullscreen.* * boxWindow color: Color black.* *. . . . . . .* browseBtn on: #click send: #value to: [self boxWindow window close. IndexInterface delete. BrowseFiles open]. *-------------------------------------------------------------------------------------------------------------------* *IndexInterface>>#delete* * box isNil ifFalse: [ self boxWindow window close. * * self boxWindow window delete . * * self boxWindow close. * * box window close .* * self boxWindow delete. * * box delete.].* * box := nil.* * self boxWindow window close. * * self boxWindow window delete .* * self boxWindow close. * * self boxWindow delete.* * boxWindow := nil.* *-------------------------------------------------------------------------------------------------------------------* Help appreciated. Regards Jigyasa

Aug. 8, 2015

Re: [Pharo-dev] Is Metacello in Pharo 5.0 up-to-date? and project locking

by Dale Henrichs

On 08/07/2015 01:08 AM, Christophe Demarey wrote: > Le 6 aoÃ»t 2015 Ã 22:49, Dale Henrichs a Ã©crit : > >> For the Metacello tests themselves, the version of Metacello under test is installed on top of the version present in the image, using the "standard Metacello update code" ... failures at this point indicate Metacello upgrade problems ... then the unit tests are run ... > ok, I found hat is missing. > Metacello update through the BaselineOfMetacello works ... but the code used for the bootsrap of Metacello in BuilderCI uses the ConfigurationOfMetacelloPreview and load the stable version that is currently 1.0.0-beta.32.17. The change I made to builderCI[1] involves skipping the bootstrap of Metacello (via ConfigurationOfMetacelloPreview) completely. The Metacello bootstrap was been skipped for Pharo3.0 and Pharo4.0 and we just missed that detail when adding Pharo5.0. [1] https://github.com/dalehenrich/builderCI/commit/0394467e5d13c7e99500fd30175… > I think when there is already a version of Metacello able to load through the baseline, builderCi should use the Baseline to update Metacello. > WDYT? builderCI only ensures that there is a Metacello available, I don't think that it should upgrade Metacello ... I use builderCI to test the upgrade/update of Metacello to a new version so to have builderCI automatically update would defeat the purpose and mask issues. Also if there are issues in the shipped version of Metacello that show up when loading a particular project, then those issues should be revealed, since the standard workflow for loading into an image should not include lading the latest Metacello first... If a project chooses to test with the latest version of Metacello (something I often do for GemStone tests) then the project itself should do the upgrade ... Dale

Aug. 7, 2015

Launcher Issues

by Sean P. DeNigris

For "Issue 16115: Launcher: Update Common Tools for Moose 5.1 Release" (https://pharo.fogbugz.com/default.asp?16115) the fix has been picked up by the CI and I verified that it works. What is the process here? Shall I close the issue with something like "in build #51"? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Launcher-Issues-tp4841491.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 7, 2015

[pharo-project/pharo-core] b4ae22: 50213

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: b4ae22fb9850c70cf7eb0423f68f0e0a8293e738 https://github.com/pharo-project/pharo-core/commit/b4ae22fb9850c70cf7eb0423… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-07 (Fri, 07 Aug 2015) Changed paths: A AST-Core.package/RBNullFormatter.class/README.md A AST-Core.package/RBNullFormatter.class/class/initialize/formatAsYouReadPolicy.st A AST-Core.package/RBNullFormatter.class/class/initialize/formatAsYouReadPolicy_.st A AST-Core.package/RBNullFormatter.class/definition.st A AST-Core.package/RBNullFormatter.class/instance/public interface/containerWidth_.st A AST-Core.package/RBNullFormatter.class/instance/public interface/format_.st M AST-Core.package/RBProgramNode.class/class/accessing/formatterClass.st A AST-Core.package/RBProgramNode.class/class/accessing/resetFormatter.st M Nautilus.package/NautilusAnnotationDisplayer.class/instance/submorphs-accessing/formatAsYouRead.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50212.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50213.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50212.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50213.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50213 16097 introduce RBNullFormatter https://pharo.fogbugz.com/f/cases/16097 http://files.pharo.org/image/50/50213.zip

Aug. 7, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 7, 2015

Re: [Pharo-dev] GTInspector intances are never released and the inspected object is also never relased

by Andrei Chis

In a copy of the image can you try to do an image cleanup (System -> Do image cleanup) and see if those instances still persists afterwards. Also do you have any zombie processes? If yes can you see if killing them releases the inspector instances. Cheers, Andrei On Fri, Aug 7, 2015 at 3:00 PM, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Hi to all, > I'm having a problem using the latest Pharo5 image. > > I can use it normally, but after a time using it. I see the memory usage > has increased. > As I'm working with many objects this usage increase very fast, each test > is creating them and discarding them. > > When I started looking where all my memory usage was, I have checked that > a lot of instances of GTInspector are not released (around 30 in a normal > usage of an hour of programming), also each intance of GTInspector has my > tree of objects, so there are never released. > > I have checked that my objects are not referenced from other places. The > only remaining references they have are the inspectors and the visual > elements in them. > > Any has this problem? Do you have any clue or workaround for releasing > all this instances? > > > Thanks! > > -- > Pablo Tesone. > tesonep(a)gmail.com >

Aug. 7, 2015

Re: [Pharo-dev] GTInspector intances are never released and the inspected object is also never relased

by stepharo

may be related to te memory leak esteban is chasing around rubric Le 7/8/15 15:00, tesonep(a)gmail.com a Ã©crit : > Hi to all, > I'm having a problem using the latest Pharo5 image. > > I can use it normally, but after a time using it. I see the memory > usage has increased. > As I'm working with many objects this usage increase very fast, each > test is creating them and discarding them. > > When I started looking where all my memory usage was, I have checked > that a lot of instances of GTInspector are not released (around 30 in > a normal usage of an hour of programming), also each intance of > GTInspector has my tree of objects, so there are never released. > > I have checked that my objects are not referenced from other places. > The only remaining references they have are the inspectors and the > visual elements in them. > > Any has this problem? Do you have any clue or workaround for > releasing all this instances? > > > Thanks! > > -- > Pablo Tesone. > tesonep(a)gmail.com <mailto:tesonep@gmail.com>

Aug. 7, 2015

Re: [Pharo-dev] GTInspector intances are never released and the inspected object is also never relased

by Tudor Girba

This sounds like a bug. Could you open an issue? Cheers, Doru On Fri, Aug 7, 2015 at 3:00 PM, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Hi to all, > I'm having a problem using the latest Pharo5 image. > > I can use it normally, but after a time using it. I see the memory usage > has increased. > As I'm working with many objects this usage increase very fast, each test > is creating them and discarding them. > > When I started looking where all my memory usage was, I have checked that > a lot of instances of GTInspector are not released (around 30 in a normal > usage of an hour of programming), also each intance of GTInspector has my > tree of objects, so there are never released. > > I have checked that my objects are not referenced from other places. The > only remaining references they have are the inspectors and the visual > elements in them. > > Any has this problem? Do you have any clue or workaround for releasing > all this instances? > > > Thanks! > > -- > Pablo Tesone. > tesonep(a)gmail.com > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 7, 2015

GTInspector intances are never released and the inspected object is also never relased

by tesonep＠gmail.com

Hi to all, I'm having a problem using the latest Pharo5 image. I can use it normally, but after a time using it. I see the memory usage has increased. As I'm working with many objects this usage increase very fast, each test is creating them and discarding them. When I started looking where all my memory usage was, I have checked that a lot of instances of GTInspector are not released (around 30 in a normal usage of an hour of programming), also each intance of GTInspector has my tree of objects, so there are never released. I have checked that my objects are not referenced from other places. The only remaining references they have are the inspectors and the visual elements in them. Any has this problem? Do you have any clue or workaround for releasing all this instances? Thanks! -- Pablo Tesone. tesonep(a)gmail.com

Aug. 7, 2015