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

Re: [Pharo-dev] [Pharo-users] new Pharo Success story

by Pablo R. Digonzelli

Great! Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 De: "Tudor Girba" <tudor(a)tudorgirba.com> Para: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> CC: "Pharo Development List" <pharo-dev(a)lists.pharo.org> Enviados: Lunes, 20 de Octubre 2014 6:59:33 Asunto: Re: [Pharo-dev] [Pharo-users] new Pharo Success story +100 Doru On Mon, Oct 20, 2014 at 11:41 AM, Sven Van Caekenberghe < sven(a)stfx.eu > wrote: > On 19 Oct 2014, at 09:44, stepharo < stepharo(a)free.fr > wrote: > > Hi > > we just published a new success story: Pharo at CSOB > > http://pharo.org/success > > And yes we are interested in your sucess stories > > Stef > > PS: big thanks to Tomas and CSOB for letting us making this public. Beautiful! Great work. It is a lot of work to do a project inside such a big bank, let alone make a success of it. Congratulation to Tomas and the rest of his team. Sven -- www.tudorgirba.com "Every thing has its own flow"

Oct. 20, 2014

Re: [Pharo-dev] Use Komitter in MC Browser?

by stepharo

> I hacked the MC Browser to open up a Changes window along-side my commit > dialog. Then I realized we already have this (and a bit more) with Komitter. > What if we just plug Komitter into the "Save" operation? We should pay attention that Komitter is sometimes a bit fragile and having string back doors is nice. May be we should have Save (K) and Save ?

Oct. 20, 2014

Re: [Pharo-dev] Image Segment semantics and weakness

by stepharo

While I as a big fan of imageSegment and proposed to mariano to work on imageSegment2 (it was the original idea for his phd) he convinced us that imagesegment were not worth their complexity. So why do you want to have imageSegment? Stef On 20/10/14 03:01, Eliot Miranda wrote: > Hi All, > > I want to check my understanding of reference semantics for image > segments as I'm close to completing the Spur implementation. > Specifically the question is whether objects reachable only through > weak pointers should be included in an image segment or not. > > Remember that an image segment is created from the transitive closure > of an Array of root objects, the /segment roots/. i.e. we can think of > an image segment as a set of objects created by tracing the object > graph from the segment roots. > > The segment always includes the segment roots. Except for the roots, > objects are excluded from the segment that are also reachable form the > roots of the system (the /system roots/, effectively the root > environment, Smalltalk, and the stack of the current process). > > Consider a weak array in the transitive closure that is not reachable > from the system roots, and hence should be included in the segment. > Objects referenced from that weak array may be in one of three categories > > - reachable from the system roots (and hence not to be included in the > segment) > - /not/ reachable form the system roots, but reachable from the > segment roots via strong pointers (and hence to be included in the > segment) > - /not/ reachable form the system roots, /not/ reachable from the > segment roots via strong pointers > > Should this last category be included or excluded from the segment? I > think that it makes no difference, and excluding them is only an > optimization. The argument is as follows. Imagine that immediately > after loading the image segment there is a garbage collection. That > garbage collection will collect all the objects in the last category > as they are only reachable from the weak arrays in the segment. Hence > we are free to follow weak references as if they are strong when we > create the image segment, leaving it to subsequent events to reclaim > those objects. > > An analogous argument accounts for objects reachable from ephemerons. > Is my reasoning sound? > -- > best, > Eliot

Oct. 20, 2014

Re: [Pharo-dev] [squeak-dev] Image Segment semantics and weakness

by J. Vuletich (mail lists)

Hi Eliot, Quoting Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi All, Â > Â Â I want to check my understanding of reference semantics for image > segments as I'm close to completing the Spur implementation.Â > Specifically the question is whether objects reachable only through weak > pointers should be included in an image segment or not. > Â > Remember that an image segment is created from the transitive closure > of an Array of root objects, the /segment roots/. i.e. we can think of > an image segment as a set of objects created by tracing the object graph > from the segment roots. > Â > The segment always includes the segment roots.Â Except for the roots, > objects are excluded from the segment that are also reachable form the > roots of the system (the /system roots/,Â effectively the root > environment, Smalltalk, and the stack of the current process). > Â > Consider a weak array in the transitive closure that is not reachable > from the system roots, and hence should be included in the segment.Â > Objects referenced from that weak array may be in one of three categories > Â > - reachable from the system roots (and hence not to be included in > the segment) > - /not/Â reachable form the system roots, butÂ reachable from the > segment roots via strong pointers (and hence to be included in the > segment) > -Â /not/Â reachable form the system roots, /not/Â reachable from the > segment roots via strong pointers > Â > Should this last category be included or excluded from the segment?Â > I think that it makes no difference, and excluding them is only an > optimization.Â The argument is as follows.Â Imagine that immediately > after loading the image segment there is a garbage collection.Â That > garbage collection will collect all the objects in the last category as > they are only reachable from the weak arrays in the segment.Â Hence we > are free to follow weak references as if they are strong when we create > the image segment, leaving it to subsequent events to reclaim those > objects. Â > Â > An analogous argument accounts for objects reachable from > ephemerons.Â Is my reasoning sound? > -- > best, Eliot I think you are right. But there is a risk of somehow, someone, gaining a strong reference to the object after the image segment was created, breaking our invariants when the segment is loaded again. An object might be (not reachable / strongly reachable / weakely reachable) from system roots and / or segment roots. This gives us 9 possibilities. Six of them are easy (and I'll not go into them). The other three are tricky: a- Not reachable from system roots. Weakely reachable from segment roots. Do not include them. It is best to run a GC before building the image segment, to get rid of them (run termination, etc). This is to avoid the risk of the object gaining somehow a strong reference after the segment is built, making the segment miss the weak ref to it. Doing this way would also mean that any objects affected by termination would be consistent, both in the image and in the segment. b- Weakely reachable from system roots. Weakely reachable from segment roots. Do not include them. If the object manages to survive by gaining a strong ref from the system roots, the weak ref will be repaired on segment load (Am I right on this?) If the original object was included in the segment, then on segment load it would point to a duplicate object that is about to be collected (and maybe terminated?) In any case, doing this way would also mean that any objects affected by termination would be consistent, both in the image and in the segment. c- Weakely reachable from system roots. Strongly reachable from segment roots. Do include them. It seems reasonable to run a GC and get rid of them after unloading the segment, to avoid the risk of the object gaining somehow a strong ref in the image, and being duplicated on segment load. But doing as I say means that we would be loading into the image an object that was already terminated, although in the state it had before running termination. Not really sure if this is ok. There could be some risk of objects in the segment being in some pre-termination state, with some objects in the image being in some after-termination state. In any case, this would suggest bad design... So perhaps it makes sense to throw an exception in these cases? I hope this rant is of use. Cheers, Juan Vuletich

Oct. 20, 2014

[pharo-project/pharo-core]

by GitHub

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

Oct. 20, 2014

[pharo-project/pharo-core] 9bafe0: 40313

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 9bafe0c881abce55b35e9cd3880f44924508ba3f https://github.com/pharo-project/pharo-core/commit/9bafe0c881abce55b35e9cd3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-20 (Mon, 20 Oct 2014) Changed paths: R AST-Interpreter-Core.package/ASTBlockClosure.class/instance/controlling/whileFalse.st R AST-Interpreter-Core.package/ASTBlockClosure.class/instance/controlling/whileFalse_.st R AST-Interpreter-Core.package/ASTBlockClosure.class/instance/controlling/whileTrue.st R AST-Interpreter-Core.package/ASTBlockClosure.class/instance/controlling/whileTrue_.st M Kernel.package/BlockClosure.class/instance/controlling/whileFalse.st M Kernel.package/BlockClosure.class/instance/controlling/whileFalse_.st M Kernel.package/BlockClosure.class/instance/controlling/whileTrue.st M Kernel.package/BlockClosure.class/instance/controlling/whileTrue_.st M Kernel.package/CompiledMethodTrailer.class/instance/initialize-release/method_.st M OpalCompiler-Core.package/extension/Object/instance/mustBeBooleanInMagic_.st M ProfStef-Core.package/PharoTutorial.class/class/zen/openPharoZenWorkspace.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script313.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40313.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/MessageBrowser.class/instance/text selection/autoSelect_.st Log Message: ----------- 40313 14240 evaluating nil and: [true] gives an infinite loop https://pharo.fogbugz.com/f/cases/14240 14264 World Menu > Help > Pharo Zen DNU https://pharo.fogbugz.com/f/cases/14264 14263 fix "search all source" https://pharo.fogbugz.com/f/cases/14263 14262 small speedup of CompiledMethod>>#endPC https://pharo.fogbugz.com/f/cases/14262 http://files.pharo.org/image/40/40313.zip

Oct. 20, 2014

Re: [Pharo-dev] [Pharo-users] new Pharo Success story

by Tudor Girba

+100 Doru On Mon, Oct 20, 2014 at 11:41 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 19 Oct 2014, at 09:44, stepharo <stepharo(a)free.fr> wrote: > > > > Hi > > > > we just published a new success story: Pharo at CSOB > > > > http://pharo.org/success > > > > And yes we are interested in your sucess stories > > > > Stef > > > > PS: big thanks to Tomas and CSOB for letting us making this public. > > Beautiful! Great work. > > It is a lot of work to do a project inside such a big bank, let alone make > a success of it. Congratulation to Tomas and the rest of his team. > > Sven > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 20, 2014

Re: [Pharo-dev] [Pharo-users] new Pharo Success story

by Sven Van Caekenberghe

> On 19 Oct 2014, at 09:44, stepharo <stepharo(a)free.fr> wrote: > > Hi > > we just published a new success story: Pharo at CSOB > > http://pharo.org/success > > And yes we are interested in your sucess stories > > Stef > > PS: big thanks to Tomas and CSOB for letting us making this public. Beautiful! Great work. It is a lot of work to do a project inside such a big bank, let alone make a success of it. Congratulation to Tomas and the rest of his team. Sven

Oct. 20, 2014

Re: [Pharo-dev] [Pharo-users] [Ann] Phratch 4.0

by jannik laval

Hi Hilaire, Which version of Linux are you using ? Thank you again for your feedback. Here is my comments for your list: - On Linux, keypad does not work >>> Ok, the last build of the vm I use is from 5 month ! I redo it, it should work today. By the way, keypad does not work on pharo-launcher too. - for me, the font characters in the bricks are too small >> you can change it in settings. Then in settings Phratch click on the button launch to refresh the display. - the robot, has a non transparent white background, I tried to edit it but the sprite I have is of too low resolution to make something clean >>> I don't understand. I have a transparent background. But I saw a bug: When I edit it, the background become white. I fixed it. - some tools in the paint dialogue are mostly invisible (see screenshot) >>> Yes, they is a strange behavior here. Sometimes it works, sometimes there is this crappy green color... I tried again to fix it. We will see what happen. The point is to clean all this part of Phratch, If there are volunteers :) - preview and loading of JPG background does not work (see screenshot fileDialog) On my Ubuntu 14.04 it works fine. - the file dialog dropdown list arrow is shifted vertically (see screenshot fileDialog) >>>fixed - in the file dialogue to load a previously saved project, the author nor description are displayed (screenshot filedialog project). >>> I open a bug entry. It will be fixed in next version. - I load the the Arduino add-on, I have a new Arduino category but no brick. I will answer in another mail. All these changes are currently building. It will be available today, or tomorrow. Cheers, Jannik 2014-10-18 16:41 GMT+02:00 Hilaire <hilaire(a)drgeo.eu>: > Thanks! > > A few points worth mentioning. > > - On Linux, keypad does not work > - for me, the font characters in the bricks are too small > - the robot, has a non transparent white background, I tried to edit it > but the sprite I have is of too low resolution to make something clean > - some tools in the paint dialogue are mostly invisible (see screenshot) > - preview and loading of JPG background does not work (see screenshot > fileDialog) > - the file dialog dropdown list arrow is shifted vertically (see > screenshot fileDialog) > - in the file dialogue to load a previously saved project, the author > nor description are displayed (screenshot filedialog project). > - I load the the Arduino add-on, I have a new Arduino category but no > brick. > > Hilaire > > > > Le 17/10/2014 11:48, jannik laval a Ã©crit : > > hratch 4.0 is out of the box ! > > > > Phratch 4.0 is cleaner, faster and more stable than phratch 3.0. > > > > After the version 3.0 that was a release for usability and stability, > > phratch 4.0 is released to prepare the future. > > > > > -- > Dr. Geo - http://drgeo.eu > iStoa - http://istoa.drgeo.eu > -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info http://car.mines-douai.fr/

Oct. 20, 2014

Re: [Pharo-dev] monkey timeout

by Marcus Denker

I have added a workaround (temporary) to the the RBSentNotImplementedRule to actually not check, this fixed the timeout (but of course the rule needs to be fixed, there is an issue from that already and Yuriy already commented how it will be fixed. On Sat, Oct 18, 2014 at 3:35 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > I think we have to review and revert some changes for > SmallLint (RB-Classes). > issue 14096 and 14098 > for instance, rules on package X are executed on all methods in class Y > if package X extends "one" methode in class Y. > -> issue 14228

Oct. 20, 2014