June 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] evicted zombie process from run queue

by stepharo

> Esteban wrote: >> Other frameworks use a datasource design (like cocoa, swtâ¦ and basically all the serious frameworks I know about). can you give a pointer? >> and no, we do not have a default design for this kind of big components (a serious absence, IMO). > Serious absence indeed. > > Stephan >

June 26, 2014

Re: [Pharo-dev] about ~=

by stepharo

;) On 26/6/14 12:46, Nicolas Cellier wrote: > $! is not classified as a binary character right now, is it? > Of course it's possible but I'd just say why this particular symbol? > It does not look mathematical either. Or do you love C/C++ so much? > > Note that ~= has same meaning in Matlab. > > There are other possibilities like /= or <> (Fortran 95, ADA), even > the long form =/=. > > But frankly, I don't buy this kind of change, for the sake of looking > like some {} language, making such a deep change is overkill. > > In any case, a big -1 for != >

June 26, 2014

How to get started with Git and Pharo?

by stepharo

Hi I do not know the dif between git file tree, file tree.... and I would like to know how to get started with git in Pharo? What should I read? Stef

June 26, 2014

Re: [Pharo-dev] about ~=

by Richard Sargent

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. -- View this message in context: http://forum.world.st/about-tp4764892p4765070.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 26, 2014

[pharo-project/pharo-core]

by GitHub

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

June 26, 2014

[pharo-project/pharo-core] a4c40a: 40047

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: a4c40ae92c67b2d4d63635d89dac0f7bbaa214d5 https://github.com/pharo-project/pharo-core/commit/a4c40ae92c67b2d4d63635d8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-06-26 (Thu, 26 Jun 2014) Changed paths: A Kernel.package/Object.class/instance/introspection/readSlotNamed_.st A Kernel.package/Object.class/instance/introspection/readSlot_.st A Kernel.package/Object.class/instance/introspection/writeSlotNamed_value_.st A Kernel.package/Object.class/instance/introspection/writeSlot_value_.st A Kernel.package/Object.class/instance/introspection/writeToSlot_of_.st A KernelTests.package/ObjectTest.class/instance/tests - introspection/testReadSlot.st A KernelTests.package/ObjectTest.class/instance/tests - introspection/testReadSlotNamed.st A KernelTests.package/ObjectTest.class/instance/tests - introspection/testWriteSlotNamedValue.st A KernelTests.package/ObjectTest.class/instance/tests - introspection/testWriteSlotValue.st A KernelTests.package/ObjectTest.class/instance/tests - introspection/testWriteToSlotOf.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script47.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40047.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot.package/InstanceVariableSlot.class/class/cleanup/resetIvarSlots.st M Slot.package/Slot.class/instance/meta-object-protocol/write_to_.st M Slot.package/Slot.class/instance/private/internalWrite_to_.st Log Message: ----------- 40047 13412 add Helper: resetIvarSlots https://pharo.fogbugz.com/f/cases/13412 13414 Keyboard shortcuts in Nautilus stopped working https://pharo.fogbugz.com/f/cases/13414 13418 reflective API for Slots on Object https://pharo.fogbugz.com/f/cases/13418 http://files.pharo.org/image/40/40047.zip

June 26, 2014

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by Marcus Denker

On 25 Jun 2014, at 14:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > Already in Pharo3 all instance variables are described using meta-objects (so called slots). > > To make it easier to access the slots, I added some simple methods to ClassDescription on 4.0 043, > Now we can do e.g.: > > Context slots > Context allSlots > > Point hasSlotNamed: #x > Point slotNamed: #x > As Camille noted, we need a different API on the Objects to read and write slots. We came up with: #readSlot: #readSlotNamed: #writeSlot:value: #writeSlotNamed:value: #writeToSlot:of: (this is what the compiler generates to reflectively write a slot) e.g. 5@3 readSlot: (Point slotNamed: #x) 5@3 writeSlotNamed: #x value: 7 This is in the issue tracker: https://pharo.fogbugz.com/f/cases/13418/reflective-API-for-Slots-on-Object Marcus

June 26, 2014

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

by Johan Brichau

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 26, 2014

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

by Nicolai Hess

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 26, 2014

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

by Johan Brichau

On 26 Jun 2014, at 15:25, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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. If you try that in Pharo3, the RPackage structure is broken. From there on, you cannot do anything reasonable anymore with a package (loading, comparing, publishing,... ) I reported a bug in this sense, but it was flagged as invalid [1] Johan [1] https://pharo.fogbugz.com/default.asp?13213#102915

June 26, 2014