- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Kernel-Tests and SystemAnnouncer

by Peter UhnÃ¡k

And not just announcers, some of the tests there leave quite a footprint. I've recently discussed something similar with regards to performance of subclassing in tests http://forum.world.st/fast-subclassing-class-creation-in-tests-td4857779.ht… So Kernel-Tests might also benefit from it. Right now I've also encountered this thread http://forum.world.st/New-class-factory-for-tests-and-other-use-cases-td129… , it's quite old (2009), but maybe it could be used instead of directly manipulating the env. On the other hand, how often do you manually trigger Kernel-Tests? CI doesn't care that much about it. Peter On Fri, Nov 20, 2015 at 12:21 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Hi, > > Ideally shouldn't Kernel-Tests, or tests in general, be silent and not > trigger a lot of system announcers? > Right now Kernel-Tests trigger around 250 announcements through the > SystemAnnouncer. > > Cheers, > Andrei

Nov. 20, 2015

Kernel-Tests and SystemAnnouncer

by Andrei Chis

Hi, Ideally shouldn't Kernel-Tests, or tests in general, be silent and not trigger a lot of system announcers? Right now Kernel-Tests trigger around 250 announcements through the SystemAnnouncer. Cheers, Andrei

Nov. 20, 2015

Re: [Pharo-dev] ConfigurationOfIDE working again

by stepharo

Le 19/11/15 22:45, Pavel Krivanek a Ã©crit : > Hi Stef, > > 2015-11-19 21:44 GMT+01:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Pavel > > may be you want to sync with christophe because he is working hard > on getting the bootstrap working for real :) > > > I already talked to him about a month ago to find out where can I help. excellent! > > Then after we really want to load Pharo using configurations or > cargo package manager. > Once we will get done the configurations will be always checked. > > > Some time ago I added a simple test that checked if the amount of > unimplemented calls was increased in the minimal Pharo. If yes it > cased the job failure. I expected that it will fail about once per > month or two but in real Marcus complained up to two times per day > that it generation of the minimal Pharo failed because of this check. > It illustrates how sometimes hard is to keep things working in this > area. We need to focus on it more to start to use the image building > process based on configurations in production because with the current > way we will have only very small progress with a lot of spent energy. Yes :) This is why we want to arrive to a bootstrap point. Stef > > Cheers, > -- Pavel > > Stef > > Le 19/11/15 11:16, Pavel Krivanek a Ã©crit : > > Hi, > > the job for ConfigurationOfIDE that loads GUI and tools (not > all for now) to minimal Pharo is now producing usable image > again.: > > https://ci.inria.fr/pharo/view/5.0-SysConf/job/Pharo-5.0-ConfigurationOfIDE/ > > We definitely need to find a way how to keep it green and > improve and clean it instead of spending one forenoon once in > a while by fixing it ;-) > > Cheers, > -- Pavel > > > >

Nov. 20, 2015

Cleanup of debug requests API

by Denis Kudriashov

Hi I try to investigate how debugger opens and who initiates it. I want to cleanup this logic and simplify current debugger API. I found that basic error debugging starts with UIManager then UIManager calls SpecDebugger, then SpecDebugger calls UIManager and again... At the end of this chain debugger is opened by #openFullSuspendLabel: or #openNotifierContents:label: There are two places where opening debugger initiated differently: - Low space watcher calls SpecDebugger class>>openInterrupt:onProcess: - Warning default action calls SpecDebugger class>>openContext:label:contents: (And it not uses UIManager. I guess non interactive mode not working here). In latest Pharo image it is only users of this methods. Is anybody know anyone else? I almost cleaned basic errors debugging. And I want use it for this two cases too. But they implements very specific logic. They both contains primitive simulation guard 19 and some kind of recursion tracking. I understand that low space watcher requires something clever. But why Warning not opens debugger with way Error does it? Any suggestions? Best regards, Denis

Nov. 20, 2015

Re: [Pharo-dev] About being a real Pharo Jedi developer

by Dimitris Chloupis

Thanks for the info. I think i am on safe side of things since I dont mess with pharo internals. You say if I override an existing method, that method cannot be recovered, but that is strange since the system does have versions for each method , so I assume here that is not that is not possible rather than none actually implemented this in a convenient way. How you can have class collision , I assumed so far that the system does not allow you to have two classes with the same name. If you have subclasses in another package then I would let them MNU. I think its kinda insane to try to protect the user from all scenarios, at least not before you deal with more pressing issues / bugs. One thing that could help here is to have something similar to when we install a project that warns us that a project depends on other projects/ classes we could have the same warning for when we remove classes. I think also its a good idea to allow user some control, for example maybe the user want to keep those subclasses and make them subclass another class instead. Yeah I will look into unloading with metacello that sounds cleaner this is an issue that really interests me. How to make my project uninstallable and automatically update-able is two areas that deeply interest me. On Fri, Nov 20, 2015 at 12:56 AM Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > To unload a package you can do it from Monticello Browser..Select the > package (left column), right click, "Unload Package". > But not that it will not work properly in cases where you have method > overrides (the original methods you override will NOT be recovered), or > class collisions (imagine your package has a class name collision with a > class name of another package)... > Then you can have instances of classes you unload...hence the Obsolete > thingy (instances are now instance of an obsolete class). > Then you can also have subclasses in ANOTHER package of classes of the > package you unload. What you do with the subclasses? and with the instances > of such subclasses? > So... order of unloading does matter across packages (in the same way that > loading does). So for unloading multiple packages you should be using > Meacello or similar. > > As you can see, it's not an easy task. > > > > > On Thu, Nov 19, 2015 at 7:23 PM, milton mamani <akevalion(a)gmail.com> > wrote: > >> +1 >> By the way so how one can unload a project from the pharo image ? I never >> tried that one before. >> >> Use the Force Dimitris >> >> Sorry I dont have the answer for this now, but I am interested on this >> issue. >> >> 2015-11-19 18:05 GMT-04:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: >> >>> I prefer being a technomage to a jedi, jedies are too, well naive and >>> purists. >>> >>> By the way so how one can unload a project from the pharo image ? I >>> never tried that one before. >>> >>> On Thu, Nov 19, 2015 at 10:59 PM stepharo <stepharo(a)free.fr> wrote: >>> >>>> When I was getting to be a Jedi, my Yoda master (Joseph Pelrine) told me >>>> the following (yes back in 96) >>>> >>>> translated from Yoda language: >>>> >>>> you will be a real Jedi when your code will load in one click! >>>> you will be a real Jedi when your code will unload in one click and >>>> do not let shit behind it! >>>> >>>> Simple no. So when do we get real Jedi knights? >>>> >>>> Stef >>>> >>>> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Nov. 20, 2015

Re: [Pharo-dev] About being a real Pharo Jedi developer

by Craig Latta

Stef writes: > When I was getting to be a Jedi, my Yoda master (Joseph Pelrine) told > me the following (yes back in 96) > > translated from Yoda language: > > you will be a real Jedi when your code will load in one click! > you will be a real Jedi when your code will unload in one click > and do not let shit behind it! > > Simple no. So when do we get real Jedi knights? We get them when we have modules that exist as live objects all the time, to which we can delegate the task of unloading. Those modules have access to all versions of methods and class definitions, and every method and class definition is covered by the module system at all times. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Nov. 20, 2015

Re: [Pharo-dev] opal optimize to do limits

by Eliot Miranda

Hi Nicolai, > On Nov 20, 2015, at 12:33 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > Thanks eliot, Clement, > > but if the argument for to:do: is not an expression but one of the method argument, this > transformation is not needed. Or still? That's the corollary to what I said. Since method (*) arguments are read-only it is safe to use them directly and avoid the transformation. One could implement this quickly in the Squeak compiler too :-). How many cases have you identified where this matters? Is it very common? (* and with the right preference, block) _,,,^..^,,,_ (phone) > > > > > 2015-11-20 8:31 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> You can use whileTrue: if it's a problem for you not to evaluate the limit at each iteration of the loop. > > I don't need this. I just compared some compiled methods bytecodes after the latest fix for the wrong frame size calculation. > For this, I compared opal compilers result with that of the old compiler. And I noticed that some methods compiled with > opal had some "hidden" temps and couldn't explain way:) > > >> >> If you look at OrderedCollection for example, there are implemented differently in Pharo/VW and Squeak. Pharo and VW use to:do: whereas Squeak uses whileTrue: to iterate over the collection. Hence, if you remove elements from the OrderedCollection while iterating over it, the behavior is different. >> >> >> 2015-11-20 1:34 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> Because were to:do: not inlined the expression passed as the to: actual argument would be evaluated exactly once (bound to the formal argument for to:) and so assigning to a temporary preserves the semantics in the most direct way. If the expression has side effects then those side effects must occur only once. >>> >>> Note that were the to: expression merely another variable then the compiler could only substitute the original variable if it's value could not change, e.g. in >>> >>> exampleToDoArgumentLimitIsExpression >>> | count sum | >>> count := 10. >>> sum := 0. >>> 1 to: count do: [ :each | sum := sum + each]. >>> ^sum >>> >>> It is ok to use count directly as the limit variable, but in this it is not: >>> >>> exampleToDoArgumentLimitIsExpression >>> | count sum | >>> count := 10. >>> sum := 0. >>> 1 to: count do: [ :each | sum := sum + each. count := #somethingElseEntirely]. >>> ^sum >>> >>> _,,,^..^,,,_ (phone) >>> >>> > On Nov 19, 2015, at 1:14 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> > >>> > What is the purpose of replacing expressions, used as limits in a >>> > to:do: call with by a new temporary variable? >>> > >>> > For example: >>> > >>> > OCOpalExamples>>#exampleToDoArgumentLimitIsExpression >>> > the code is >>> > >>> > exampleToDoArgumentLimitIsExpression >>> > | count sum | >>> > count := 10. >>> > sum := 0. >>> > 1 to: count - 1 do: [ :each | sum := sum + each]. >>> > ^sum >>> > >>> > the decompiled bytecode : >>> > >>> > exampleToDoArgumentLimitIsExpression >>> > | tmp1 tmp2 tmp3 | >>> > tmp1 := 10. >>> > tmp2 := 0. >>> > tmp3 := tmp1 - 1. >>> > 1 to: tmp3 do: [ :tmp4 | tmp2 := tmp2 + tmp4 ]. >>> > ^ tmp2 >>> > >>> > So, the expression (count - 1) in the to:do: loop is replaced by a new >>> > temporay (tmp3). >>> > >>> > Ok, but why ? >

Nov. 20, 2015

Re: [Pharo-dev] EyeInspector with subclasses of ProtoObject

by Eliot Miranda

Hi Guille, > On Nov 19, 2015, at 9:11 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > >> On 19 nov 2015, at 5:46 p.m., ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> >> >> 2015-11-19 10:33 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>> I know we can :) and I did some prototypes already as part of my thesis. >>> >>> The question is if that is a design we *want* or not. >> >> There is a misunderstanding. > > Nope :) I understood you well. And yes, you misunderstood my answer :P. I know that the VM already provides the necessary primitives and I know how to use them ^^. > >> I am not talking about prototypes. The operations are in the production VM and are stable. That's why I say you can use it. > > I meant prototypes of mirrors on the image side. I know and used the primitives. The questions are if we want to have a mirror library, if we want core tools (such as the inspector) to use it instead of delegating reflective operations to objects. Also there are many different mirror designs we can come up with. The design I have in mind is pretty much aligned with the idea of mirrors that Camille has in mind where there are low level mirrors to manipulate objects as the VM know them, and then high level mirrors implementing the language concerns AND application specific mirrors. But then this kind of mirror implementation is a beast in itself :) Good question. Let's be clear there are two issues here. One, that shouldn't be in doubt, is that Pharo should use the simple mirror primitives I provided that are already in the VM asap both to provide low level inspectors for proxies and to make the debugger/execution simulator correct. Note that process termination, where a high-priority process terminates a lower one, and end up invoking the execution simulation machinery in getting to a point where unwind blocks can be executed, so the correctness issue can bite in the base system, not just when debugging. The other issue is your question, should there be a proper set of mirror objects as described by Gilad Bracha. The rationale for proper mirrors is security; to avoid making dangerous primitives like instVarAt: and object:instVarAt: (not to mention allInstances, allObjects, class itself, etc etc) generally available so people can write secure code. This is a great rationale, and makes sense, but the current system is a /long/ way away from that. A truly secure system (meaning a single Smalltalk system which could allow untrusted Smalltalk scripts to run within it and not provide these scripts with the ability to break (into) code in the system) would require much more work than merely providing proper mirrors. The whole system of object access, method access, class manipulation needs to be implemented in a secure manner. That's a great long term project, but just adding mirrors is very far from enough. Our experience at Cadence where we have used the newspeak mirror system in a non secure squeak host, is that mirrors introduce a lot of complexity and performance overhead and so we've been eliminating their use. Our application provides an SOC domain model that used to be manipulated by mirrors, but we're phasing that out because it costs so much in performance. So my considered opinion is that we should not add proper mirrors to current Pharo, because we will pay the performance and complexity penalties but not get the security reward. Instead, there should be research projects on small simple systems that attempt to architect a usable secure Smalltalk environment, and when that architecture demonstrates its viability to port the architecture into Pharo. I think that's years away. HTH > Also, answering Stephan Eggermont below: > >> 1 Is it an improvement on the current situation? > > I believe it is. Mirrors allow to extract the reflective behavior in separate objects. With them we would be able to inspect instances of classes that have no methods at all. > > Moreover, it would clean up objectsâ API because there will be no more meta-level methods in the base classes. This would avoid name clashes like #name in metaclasses that was discussed the other day. > >> 2 Is it blocking an improvement direction we want to take? > > I do not completely understand the question. > I just can say that I think having mirrors is an interesting direction. > >> 3 Can it be tested quickly? > > A basic mirror implementation that only exposes VM internals could be easy to implement and test. Adapting the eye inspector to use a mirror instead of a normal object is also fairly easy, at lest for a first implementation. Of course the question always is doing it for real: I do not know how much time would it take to make all tools work as well. > >> >> There is no need to implement additional VM support to debug this kind of objects as it's already done and stable. >> >>> >>> >>>> On 18 nov 2015, at 5:29 p.m., ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >>>> >>>> >>>> >>>> 2015-11-18 8:43 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>>>> Iâd like to discuss also the possibility to add those low level operations on mirrors objects, that could be packaged separately from the kernel of the language. Adding them on a first step is easy, then making all tools use them is the hard/timeconsuming part, yes. >>>> >>>> All the needed operations already exist. You can put them on your mirror objects without any problem. >>>> >>>> >>>>> >>>>>> On 18 nov 2015, at 12:35 p.m., ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> This is known and was discussed on the bug tracker. >>>>>> >>>>>> The problem is that currently Pharo has many tools and classes: EyeInspector in the debugger, GTInspector outside, the debugger itself, the in-image interpreter in the Context class ... that need to be changed to support debugging objects that basically cannot receive any message. >>>>>> >>>>>> We are aware of the solution but fixing it for all the toolkits and classes is quite some work. In addition, if not tested, someone will break it because he won't understand that an inspected object can't receive any message because the expected behavior of an object with no DNU behavior and no methods inherited from Object is to freeze the system. >>>>>> >>>>>> It's a lot of fun doing that though. >>>>>> >>>>>> Clement >>>>>> >>>>>> 2015-11-17 21:39 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>>>>> Hi Esteban, >>>>>>> >>>>>>>> On Tue, Nov 17, 2015 at 1:37 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>>>>>>> 2015-11-17 14:37 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>>>>>> > Hi Esteban, >>>>>>>> > >>>>>>>> > I think EyeInspector needs to handle classes that don't inherit from >>>>>>>> > Object specially. Instead of asking the instance it should ask the class. >>>>>>>> > You should be able to use the Context methods for mirror primitives to >>>>>>>> > extract state without sending messages to the instance. Then the special >>>>>>>> > version of EyeInspector for ProtoObject subclasses can ask this like >>>>>>>> >>>>>>>> Yes, an special inspector for ProtoObject subclasses would be required, but I couldn't find one already suited for this purpose. >>>>>>>> >>>>>>>> > (thisContext objectClass: object) isIndexable ifTrue: >>>>>>>> > [size := thisContext objectSize: object] >>>>>>>> >>>>>>>> I don't know if your code was meant to be accurate or just a guideline of how this could be implemented, but Context doesn't implement #objectClass: nor #objectSize: >>>>>>>> >>>>>>> >>>>>>> Find attached. I think you'll find they are in the Spur version. You might think of back-porting their use in Context form Spur; that'll make the debugger able to handle proxies. >>>>>>> >>>>>>>> > Basically both the Inspector and the Debugger's execution simulation >>>>>>>> > machinery need to treat encapsulators such as MessageArchiver with kid >>>>>>>> > gloves. One *must not* cause inspecting or debugging to send messages >>>>>>>> > through the encapsulator. Instead, all access to the object should be >>>>>>>> > through primitives that don't send messages to the objects. >>>>>>>> >>>>>>>> I know that dealing with Proxies and similar objects is tricky, I had to deal with my own subclasses of ProtoObject in Dolphin, but there the class implemented all that was needed to interact with the environment tools. >>>>>>>> >>>>>>>> Hiwever, to me all this is a kind of black magic, I read the blue book years ago and can understand it, but I do understand it as I understand the mechanics of my car, however when it breaks down I take it to the specialist :) >>>>>>>> >>>>>>> >>>>>>> Well, the thing to think of is that inside the VM objects are just a sequence of words, and the VM, while it sends messages, doesn't send messages to objects to update their state; it just accesses the state directly. So in an execution simulation method such as >>>>>>> >>>>>>> Context methods for instruction decoding >>>>>>> pushReceiverVariable: offset >>>>>>> self push: (receiver instVarAt: offset + 1) >>>>>>> >>>>>>> that will send the message instVarAt: to the receiver, and if the receiver is a proxy, that will go through the proixie's doesNotUnderstand: method and send instVarAt: the the object the proxy wraps, which won't do the right thing at all. Instead it needs to be written >>>>>>> >>>>>>> Context methods for instruction decoding >>>>>>> pushReceiverVariable: offset >>>>>>> self push: (self object: receiver instVarAt: offset + 1) >>>>>>> >>>>>>> which reaches into the object without sending any messages to it. I understand that this will appear in Spur, because I made it part of the bootstrap, but if I were you I would integrate these changes into the current version asap. The debugger won't work properly with proxies, encapsulators etc otherwise. >>>>>>> >>>>>>> _,,,^..^,,,_ >>>>>>> best, Eliot >

Nov. 20, 2015

Re: [Pharo-dev] opal optimize to do limits

by Nicolai Hess

Thanks eliot, Clement, but if the argument for to:do: is not an expression but one of the method argument, this transformation is not needed. Or still? 2015-11-20 8:31 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > You can use whileTrue: if it's a problem for you not to evaluate the limit > at each iteration of the loop. > I don't need this. I just compared some compiled methods bytecodes after the latest fix for the wrong frame size calculation. For this, I compared opal compilers result with that of the old compiler. And I noticed that some methods compiled with opal had some "hidden" temps and couldn't explain way:) > > If you look at OrderedCollection for example, there are implemented > differently in Pharo/VW and Squeak. Pharo and VW use to:do: whereas Squeak > uses whileTrue: to iterate over the collection. Hence, if you remove > elements from the OrderedCollection while iterating over it, the behavior > is different. > > > 2015-11-20 1:34 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> Because were to:do: not inlined the expression passed as the to: actual >> argument would be evaluated exactly once (bound to the formal argument for >> to:) and so assigning to a temporary preserves the semantics in the most >> direct way. If the expression has side effects then those side effects >> must occur only once. >> >> Note that were the to: expression merely another variable then the >> compiler could only substitute the original variable if it's value could >> not change, e.g. in >> >> exampleToDoArgumentLimitIsExpression >> | count sum | >> count := 10. >> sum := 0. >> 1 to: count do: [ :each | sum := sum + each]. >> ^sum >> >> It is ok to use count directly as the limit variable, but in this it is >> not: >> >> exampleToDoArgumentLimitIsExpression >> | count sum | >> count := 10. >> sum := 0. >> 1 to: count do: [ :each | sum := sum + each. count := >> #somethingElseEntirely]. >> ^sum >> >> _,,,^..^,,,_ (phone) >> >> > On Nov 19, 2015, at 1:14 PM, Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> > >> > What is the purpose of replacing expressions, used as limits in a >> > to:do: call with by a new temporary variable? >> > >> > For example: >> > >> > OCOpalExamples>>#exampleToDoArgumentLimitIsExpression >> > the code is >> > >> > exampleToDoArgumentLimitIsExpression >> > | count sum | >> > count := 10. >> > sum := 0. >> > 1 to: count - 1 do: [ :each | sum := sum + each]. >> > ^sum >> > >> > the decompiled bytecode : >> > >> > exampleToDoArgumentLimitIsExpression >> > | tmp1 tmp2 tmp3 | >> > tmp1 := 10. >> > tmp2 := 0. >> > tmp3 := tmp1 - 1. >> > 1 to: tmp3 do: [ :tmp4 | tmp2 := tmp2 + tmp4 ]. >> > ^ tmp2 >> > >> > So, the expression (count - 1) in the to:do: loop is replaced by a new >> > temporay (tmp3). >> > >> > Ok, but why ? >> >> >

Nov. 20, 2015

Re: [Pharo-dev] About being a real Pharo Jedi developer

by stepharo

Le 19/11/15 23:13, Chris Muller a Ã©crit : >> translated from Yoda language: >> >> you will be a real Jedi when your code will load in one click! > In Yoda grammar: > > "When, in one click, your code will load, then, and only then, a Jedi > will you be..." > :) Thanks my decoder was not working well :) > >

Nov. 20, 2015