- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

by Goubier Thierry

Ok then, a simple profile should do it. I'll have a look. I did profile loading Roassal2 with AltBrowser yesterday evening and updates on the browser take 15% of the execution time... Will optimize that. Thierry Le 27/06/2014 11:58, phil(a)highoctane.be a Ã©crit : > Same story here. > Loading with browsers closed leads to a 10x faster load. > > Phil > > Le 27 juin 2014 10:31, "Johan Brichau" <johan(a)inceptive.be > <mailto:johan@inceptive.be>> a Ã©crit : > > > > I reported it as bug 13422 [1]. > > > > For now, I was only able to do a comparison before/after which > instances are being kept around. > > > > Johan > > > > [1] https://pharo.fogbugz.com/default.asp?13422#104139 > > > > On 26 Jun 2014, at 16:33, Johan Brichau <johan(a)inceptive.be > <mailto:johan@inceptive.be>> wrote: > > > > > Nicolai, > > > > > > It's not a public configuration and it loads quite some packages. > > > I will pick up this issue this evening to get a better reproducible > case. > > > > > > thx > > > Johan > > > > > > On 26 Jun 2014, at 16:03, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > > > > > >> 2014-06-26 15:37 GMT+02:00 Goubier Thierry <thierry.goubier(a)cea.fr > <mailto:thierry.goubier@cea.fr>>: > > >> > > >> > > >> Le 26/06/2014 15:25, Sven Van Caekenberghe a Ã©crit : > > >> > > >> > > >> On 26 Jun 2014, at 15:17, Johan Brichau <johan(a)inceptive.be > <mailto:johan@inceptive.be>> wrote: > > >> > > >> I will do that, but the main problem is not the loading speed. > > >> The real problem is that the image blows up (i.e. crashes) when a > browser is open because it runs out of memory. > > >> > > >> But yes, I will make a ticket and get some more profiling with > that so we can fix it. > > >> Right now, I have to tell my co-workers to close all browsers when > they do a full code load interactively... it works but it's a bit > ridiculous ;-) > > >> > > >> I disagree a bit ;-) > > >> > > >> Like Thierry said before: we all expect open browsers to react to > anything that happens, so when you load a very large amount of code, > lots of things change and I can imagine the internal notifications > (announcements) overloading the browsers who are struggling to keep up. > > >> > > >> This means something can be optimized in the browser... Browsers > have a very limited view on the underlying code, more or less a subset > of a class methods and their relation in higher stuff, such as the > package, which means loading a large body of code has little effect on > the Browser (unless it's a live CodeCity instance :)). > > >> > > >> > > >> Now, there is probably something wrong, and things can probably be > tuned, but I think this will always be slower. > > >> > > >> Not by much. > > >> > > >> > > >> Like StÃ©phane said, loading a big batch of code should happen in a > special way, disabling updates and firing a full reset at the end - or > something along those lines. > > >> > > >> I disagree with you there. > > >> > > >> Disabling updates causes problems in many different places > (RPackage, for one) and correct implementation of the Browser updates > should not slow it down significantly. And it allow us, in the future, > to have a responsive GUI while loading code. > > >> > > >> I know because after optimising it, it went from very visible to > being almost invisible on the profile (far below the time spent #pragma > updating). > > >> > > >> Thierry > > >> > > >> -- > > >> Thierry Goubier > > >> CEA list > > >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > > >> 91191 Gif sur Yvette Cedex > > >> France > > >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > >> > > >> > > >> > > >> I can not reproduce this, neither the crash nor the image memory > blow up. > > >> I tested several ConfigurationOfXXX, with one or more open Browsers. > > >> > > >> Can you tell me what Configuration you are trying to load and if > this is a fresh pharo image or > > >> are there any other packages loaded. > > >> And do you have any Nautilus plugins enabled? > > >> > > >> regards > > >> Nicolai > > > > > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 27, 2014

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

by phil＠highoctane.be

Same story here. Loading with browsers closed leads to a 10x faster load. Phil Le 27 juin 2014 10:31, "Johan Brichau" <johan(a)inceptive.be> a Ã©crit : > > I reported it as bug 13422 [1]. > > For now, I was only able to do a comparison before/after which instances are being kept around. > > Johan > > [1] https://pharo.fogbugz.com/default.asp?13422#104139 > > On 26 Jun 2014, at 16:33, Johan Brichau <johan(a)inceptive.be> wrote: > > > Nicolai, > > > > It's not a public configuration and it loads quite some packages. > > I will pick up this issue this evening to get a better reproducible case. > > > > thx > > Johan > > > > On 26 Jun 2014, at 16:03, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > >> 2014-06-26 15:37 GMT+02:00 Goubier Thierry <thierry.goubier(a)cea.fr>: > >> > >> > >> Le 26/06/2014 15:25, Sven Van Caekenberghe a Ã©crit : > >> > >> > >> On 26 Jun 2014, at 15:17, Johan Brichau <johan(a)inceptive.be> wrote: > >> > >> I will do that, but the main problem is not the loading speed. > >> The real problem is that the image blows up (i.e. crashes) when a browser is open because it runs out of memory. > >> > >> But yes, I will make a ticket and get some more profiling with that so we can fix it. > >> Right now, I have to tell my co-workers to close all browsers when they do a full code load interactively... it works but it's a bit ridiculous ;-) > >> > >> I disagree a bit ;-) > >> > >> Like Thierry said before: we all expect open browsers to react to anything that happens, so when you load a very large amount of code, lots of things change and I can imagine the internal notifications (announcements) overloading the browsers who are struggling to keep up. > >> > >> This means something can be optimized in the browser... Browsers have a very limited view on the underlying code, more or less a subset of a class methods and their relation in higher stuff, such as the package, which means loading a large body of code has little effect on the Browser (unless it's a live CodeCity instance :)). > >> > >> > >> Now, there is probably something wrong, and things can probably be tuned, but I think this will always be slower. > >> > >> Not by much. > >> > >> > >> Like StÃ©phane said, loading a big batch of code should happen in a special way, disabling updates and firing a full reset at the end - or something along those lines. > >> > >> I disagree with you there. > >> > >> Disabling updates causes problems in many different places (RPackage, for one) and correct implementation of the Browser updates should not slow it down significantly. And it allow us, in the future, to have a responsive GUI while loading code. > >> > >> I know because after optimising it, it went from very visible to being almost invisible on the profile (far below the time spent #pragma updating). > >> > >> Thierry > >> > >> -- > >> Thierry Goubier > >> CEA list > >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > >> 91191 Gif sur Yvette Cedex > >> France > >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > >> > >> > >> > >> I can not reproduce this, neither the crash nor the image memory blow up. > >> I tested several ConfigurationOfXXX, with one or more open Browsers. > >> > >> Can you tell me what Configuration you are trying to load and if this is a fresh pharo image or > >> are there any other packages loaded. > >> And do you have any Nautilus plugins enabled? > >> > >> regards > >> Nicolai > > > >

June 27, 2014

Spec TreeModel

by Yuriy Tymchuk

Hi, Iâd like to improve the TreeModel of Spec, but I need some help. Fist of all UI breaks when different theme is used: When you deselect checkbox and at that moment item is not highlighted. This happens when checkbox is clicked, the item is not highlighted and so itâs original color is not stored, but when you uncheck item it IS unhighlighted for some reason, and as default color is not stored, black one is used. First of all we can replace black color by theme color, and also I think that we should handle checkbox and list clicks in a separate manner. Now the other thing is related. I can turn on checkbox, but can I turn off the list selection? Are the selected items distinguished is any way, or all items with checked checkboxes and highlights merged into one list? Uko

June 27, 2014

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

by Johan Brichau

I reported it as bug 13422 [1]. For now, I was only able to do a comparison before/after which instances are being kept around. Johan [1] https://pharo.fogbugz.com/default.asp?13422#104139 On 26 Jun 2014, at 16:33, Johan Brichau <johan(a)inceptive.be> wrote: > Nicolai, > > It's not a public configuration and it loads quite some packages. > I will pick up this issue this evening to get a better reproducible case. > > thx > Johan > > On 26 Jun 2014, at 16:03, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> 2014-06-26 15:37 GMT+02:00 Goubier Thierry <thierry.goubier(a)cea.fr>: >> >> >> Le 26/06/2014 15:25, Sven Van Caekenberghe a Ã©crit : >> >> >> On 26 Jun 2014, at 15:17, Johan Brichau <johan(a)inceptive.be> wrote: >> >> I will do that, but the main problem is not the loading speed. >> The real problem is that the image blows up (i.e. crashes) when a browser is open because it runs out of memory. >> >> But yes, I will make a ticket and get some more profiling with that so we can fix it. >> Right now, I have to tell my co-workers to close all browsers when they do a full code load interactively... it works but it's a bit ridiculous ;-) >> >> I disagree a bit ;-) >> >> Like Thierry said before: we all expect open browsers to react to anything that happens, so when you load a very large amount of code, lots of things change and I can imagine the internal notifications (announcements) overloading the browsers who are struggling to keep up. >> >> This means something can be optimized in the browser... Browsers have a very limited view on the underlying code, more or less a subset of a class methods and their relation in higher stuff, such as the package, which means loading a large body of code has little effect on the Browser (unless it's a live CodeCity instance :)). >> >> >> Now, there is probably something wrong, and things can probably be tuned, but I think this will always be slower. >> >> Not by much. >> >> >> Like StÃ©phane said, loading a big batch of code should happen in a special way, disabling updates and firing a full reset at the end - or something along those lines. >> >> I disagree with you there. >> >> Disabling updates causes problems in many different places (RPackage, for one) and correct implementation of the Browser updates should not slow it down significantly. And it allow us, in the future, to have a responsive GUI while loading code. >> >> I know because after optimising it, it went from very visible to being almost invisible on the profile (far below the time spent #pragma updating). >> >> Thierry >> >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> >> >> >> I can not reproduce this, neither the crash nor the image memory blow up. >> I tested several ConfigurationOfXXX, with one or more open Browsers. >> >> Can you tell me what Configuration you are trying to load and if this is a fresh pharo image or >> are there any other packages loaded. >> And do you have any Nautilus plugins enabled? >> >> regards >> Nicolai >

June 27, 2014

[pharo-project/pharo-core] c73c30: 40048

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: c73c301cc203f275017ce069c367c775886541b5 https://github.com/pharo-project/pharo-core/commit/c73c301cc203f275017ce069… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-06-27 (Fri, 27 Jun 2014) Changed paths: R AST-Interpreter-Core.package/extension/OCInstanceVariable/instance/accept_assign_inNode_.st R AST-Interpreter-Core.package/extension/OCInstanceVariable/instance/readWith_inNode_.st A FileSystem-Core.package/FileReference.class/class/instance creation/newTempFilePrefix_suffix_.st A FileSystem-Tests-Core.package/FileReferenceTest.class/instance/tests/testTempFilePrefixSuffix.st R OpalCompiler-Core.package/OCInstanceVariable.class/README.md R OpalCompiler-Core.package/OCInstanceVariable.class/definition.st R OpalCompiler-Core.package/OCInstanceVariable.class/instance/accessing/index.st R OpalCompiler-Core.package/OCInstanceVariable.class/instance/accessing/index_.st R OpalCompiler-Core.package/OCInstanceVariable.class/instance/accessing/name.st R OpalCompiler-Core.package/OCInstanceVariable.class/instance/accessing/name_.st R OpalCompiler-Core.package/OCInstanceVariable.class/instance/emitting/emitStore_.st R OpalCompiler-Core.package/OCInstanceVariable.class/instance/emitting/emitValue_.st R OpalCompiler-Core.package/OCInstanceVariable.class/instance/testing/isInstance.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script48.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40048.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot.package/Slot.class/instance/emitting/emitStore_.st A Slot.package/Slot.class/instance/emitting/emitValue_.st A Slot.package/TestSlot.class/README.md A Slot.package/TestSlot.class/definition.st A Slot.package/TestSlot.class/instance/meta-object-protocol/read_.st A Slot.package/TestSlot.class/instance/meta-object-protocol/write_to_.st R SmartSuggestions.package/extension/OCInstanceVariable/instance/specialCommands.st Log Message: ----------- 40048 13420 Abstract slot class should emit code to reflectively read the slot https://pharo.fogbugz.com/f/cases/13420 13419 remove OCInstanceVariable https://pharo.fogbugz.com/f/cases/13419 13405 Get support for temporary files https://pharo.fogbugz.com/f/cases/13405 http://files.pharo.org/image/40/40048.zip

June 27, 2014

[pharo-project/pharo-core]

by GitHub

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

June 27, 2014

[Pharo4] Slots: Code Generation and an Example

by Marcus Denker

Hi, So now Opal delegates code generation for read and write to the Slot meta objects. The methods called are #emitValue: and #emitStore:, the parameter is an IRBuilder. With this the implementor of a Slot is free to generate whatever bytecode needed, it will be inlined at the read or assignment site in the method. For the ivar Slot this is e.g. just emitStore: methodBuilder methodBuilder storeInstVar: index emitValue: methodBuilder methodBuilder pushInstVar: index. Now the implementors of Slots should not need to be bothered about bytecode, therefore we have in the superclass of all Slots defaults emit methods that implement a *reflective* read and write using the MOP of the Slot itself (slower than code generation, but often enough): emitValue: aMethodBuilder aMethodBuilder pushLiteral: self; pushReceiver; send: #read: emitStore: aMethodBuilder aMethodBuilder pushLiteral: self; pushReceiver; send: #writeToSlot:of: What this means is that for someone who wants to implement a slot, you do not have to deal with bytecode at all. Here is a simple Slot: Slot subclass: #TestSlot instanceVariableNames: 'value' classVariableNames: '' category: 'Slot-Scopeâ read: anObject ^ value write: aValue to: anObject value := aValue So this is a strange kind of Slot that stores the value in itself, which means it is shared between all objects as there is only one Slot meta object per class per slot. (not something you want to do in real world, but a nice demo) Now we can create a class (not yet easily as we have not yet enabled a class template, so lets use the ClassBuilder directly): PharoClassInstaller make: [ :builder | builder name: #A; slots: { TestSlot named: #iv }; category: #Playground ]. In class A we can implement accessors: iv ^iv iv: anObject iv := anObject They look like normal ivar accesses, but in the background, the compiler delegated to the Slot the code generation, calling emit*, which leads to the bytecode e.g. for the read: 21 <20> pushConstant: iv => TestSlot 22 <70> self 23 <E1> send: read: 24 <7C> returnTop you could override the emit* methods to generate faster code, but to get something running it is not needed. To test, e.g. you can set the slot from one object and read it from another: A new iv: 6 A new iv Then inspect the slot: (A slotNamed: #iv) inspect (this should all Work in 4.0 048, the example is there as TestSlot for now) ...next steps: 1) Class Definition template for classes with Slots 2) How do we save these classes in Monticello? 3) Virtual Slots (Boolean and PropertySlots) Marcus

June 27, 2014

Re: [Pharo-dev] Spec, groups and version-specific packages

by Christophe Demarey

Le 26 juin 2014 Ã 14:49, Roberto Minelli a Ã©crit : > Hi Christophe, > > Thanks for the answer. I managed to do that! > > Am I interpreting something wrong or the CoolBrowser-Platform itself is an empty package? Some kind of. It is just a name you define that will then be bound to a "real" package.

June 27, 2014

Centring label

by Yuriy Tymchuk

Hi, is there a way to align text of Specâs LabelModel, so it will appear in the middle? Uko

June 27, 2014

Re: [Pharo-dev] about ~=

by Goubier Thierry

Le 26/06/2014 18:11, Richard Sargent a Ã©crit : > Esteban A. Maringolo wrote >> If one thing confuses people in that realm is non arithmetic precedence: >> Eg. 2 + 3 * 4 = 20 instead of the "expected" 14. >> >> And we're not going to change that either. It's not worthy, and I >> doubt if it is possible at all. > > I'm probably late to the party with this reply. The primary reason for not > changing this is that it would be incorrect. It comes down to intrinsic > versus extrinsic meaning. A multiple operator has an intrinsic meaning: it > means multiple. But a message name does not have intrinsic meaning (other > than it is a good idea to have the name represent what it does). The meaning > of a message is determined by the receiver. e.g. if PetitParser defines #* > to mean "0 or more repetitions", what happens when someone has decided that > it should be evaluated before #+? > > Message sending precedence can only be defined in terms of the type of > message: unary, binary (or infix), and keyword, since the interpretation of > the message is the receiver's responsibility, not the compiler's. You could do it, but then you would have to wire the smalltalk parser with additional data (binary messages precedence) that would have to add a way or another to your binary method definition. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 27, 2014