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

Re: [Pharo-dev] Spec Understandability

by kilon alios

For me there is nothing that sucks more than having to type code to create a GUI in year 2014.... This a strong reason why I miss my days coding in Delphi so much. at least halos try to compensate for that partly.I love halos please dont remove them, good thing they suck for you, they rock for me. The fact that I can close a problematic morph that refuses to exit, by bringing its halo and clicking x , is enough reason to keep them around for me. I love the idea of halos the idea that you can hack any gui with simple actions, with no code invloved, and resynthesised it is definetly something I find immensely useful though the implementation of halos is far from ideal. On Tue, Oct 21, 2014 at 9:18 AM, stepharo <stepharo(a)free.fr> wrote: > Note that halo implementation sucks! > In Bloc alain clean it and he is able to plug halos and package them > cleanly. > > In addition in Bloc he took the decision not to implement for now the > direct creation of certain widget because > this kind of feature leads to spaghetti dependencies. > > Stef > > > > On 20/10/14 20:35, Sean P. DeNigris wrote: > >> Ralph Boland wrote >> >>> I am not in the habit of using halos, not really sure what they are for. >>> But your description implies they are quite useful. >>> What does "bring up halos on and inspect a button to see how to >>> duplicate >>> its action" mean? Could you please describe in step by step detail. >>> >> Hi Ralph! I think the best way to understand why Morphic is revolutionary >> is >> to read the papers of its creators (e.g. >> http://web.media.mit.edu/~jmaloney/papers/DirectnessAndLivenessInMorphic >> .pdf). >> I also wrote http://stackoverflow.com/a/4410189/424245 which should give >> a >> taste and also answers your question more directly. HTH. >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Spec- >> Understandability-tp4778370p4785597.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >> > >

Oct. 21, 2014

Re: [Pharo-dev] Ring

by Marcus Denker

Yes, RBObject and RBNamedDefinition have been merged into RGDefinition. (both classes just added one ivar + API, had no subclasses and no need to ever have subclassesâ¦) On Tue, Oct 21, 2014 at 9:13 AM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > Thanks Marcus, > Ok, so I need to check more carefully because I experience a problem on one of my extensions that was adding > #asRingDefinition to RGObject (if I am not mistaken). > Cheers, > R >> On Oct 21, 2014, at 9:08 AM, <marcus.denker(a)gmail.com> <marcus.denker(a)gmail.com> wrote: >> >> It still is. We just simplified it ( eg remiving ring factory) >> >> >> >> >> On Tue, Oct 21, 2014 at 9:06 AM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: >> >> Hi guys, >> >> I havenât been programming for the last few weeksâ¦ >> I just discovered that Ring is no longer part of the image. >> >> I am wondering if it has been replaced by a new model or it just disappeared. >> >> Cheers, >> Roberto >> >>

Oct. 21, 2014

Re: [Pharo-dev] Ring

by Roberto Minelli

Thanks Marcus, Ok, so I need to check more carefully because I experience a problem on one of my extensions that was adding #asRingDefinition to RGObject (if I am not mistaken). Cheers, R > On Oct 21, 2014, at 9:08 AM, <marcus.denker(a)gmail.com> <marcus.denker(a)gmail.com> wrote: > > It still is. We just simplified it ( eg remiving ring factory) > > > > > On Tue, Oct 21, 2014 at 9:06 AM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > > Hi guys, > > I havenât been programming for the last few weeksâ¦ > I just discovered that Ring is no longer part of the image. > > I am wondering if it has been replaced by a new model or it just disappeared. > > Cheers, > Roberto > >

Oct. 21, 2014

Re: [Pharo-dev] Ring

by marcus.denker＠gmail.com

It still is. We just simplified it ( eg remiving ring factory) On Tue, Oct 21, 2014 at 9:06 AM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > Hi guys, > I havenât been programming for the last few weeksâ¦ > I just discovered that Ring is no longer part of the image. > I am wondering if it has been replaced by a new model or it just disappeared. > Cheers, > Roberto

Oct. 21, 2014

Ring

by Roberto Minelli

Hi guys, I havenât been programming for the last few weeksâ¦ I just discovered that Ring is no longer part of the image. I am wondering if it has been replaced by a new model or it just disappeared. Cheers, Roberto

Oct. 21, 2014

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

by stepharo

Thanks mariano. This is what I call science in action. You convinced me back then and Fuel is a success. On 21/10/14 03:55, Mariano Martinez Peck wrote: > Just a quick note I would like to share.... > For my PhD, I did investigate ImageSegment very very deeply: > > http://dl.acm.org/citation.cfm?id=2076323 > http://www.slideshare.net/MarianoMartinezPeck/2010-smalltalkspeckobject-swa… > > I didn't want to write Fuel just because. I took quite a lot of time > to understand how ImageSegment primitives worked. From that effort, I > remember a few conclusions: > > 1) I found only few users of ImageSegment > 2) The few users I found, were NOT using the real purpose of > ImageSegment, that is, object swapping. It was used instead as an > object serializer. For that, they use #writeForExportOn: which ended > up using SmartRefStream for the rest of the objects. > 3) I noticed I could achieve the same performance or even better with > an OO serializer built at the language side, with all the benefits > this means. Of course, having Cog helped here.... > > In the Fuel paper: > http://rmod.lille.inria.fr/archives/papers/Dias12a-SPE-Fuel.pdf > you can find some benchmark comparison agains IS. Also in my PhD: > http://rmod.lille.inria.fr/archives/phd/PhD-2012-Martinez-Peck.pdf > > Cheers, > > > > > > On Mon, Oct 20, 2014 at 9:56 PM, <jvuletich(a)dc.uba.ar > <mailto:jvuletich@dc.uba.ar>> wrote: > > Hi Eliot, > > > 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 > > > > > > > -- > Mariano > http://marianopeck.wordpress.com

Oct. 21, 2014

[pharo-project/pharo-core]

by GitHub

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

Oct. 21, 2014

[pharo-project/pharo-core] cea480: 40315

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: cea4804b8fefa6b0ae6239807b797fbc59f69bac https://github.com/pharo-project/pharo-core/commit/cea4804b8fefa6b0ae623980… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-21 (Tue, 21 Oct 2014) Changed paths: M Collections-Strings.package/Symbol.class/instance/accessing/precedence.st R Graphics-Tests.package/ColorTest.class/instance/testing/testPrintHtmlString.st A Graphics-Tests.package/ColorTest.class/instance/tests/testPrintHtmlString.st A Graphics-Tests.package/PointTest.class/instance/tests - testing/testNormalized.st A Graphics-Tests.package/PointTest.class/instance/tests - testing/testSideOf.st A Graphics-Tests.package/RectangleTest.class/instance/tests-accessing/testBottom.st A Graphics-Tests.package/RectangleTest.class/instance/tests-accessing/testLeft.st A Graphics-Tests.package/RectangleTest.class/instance/tests-accessing/testRight.st A Graphics-Tests.package/RectangleTest.class/instance/tests-accessing/testTop.st M Graphics-Tests.package/RectangleTest.class/instance/tests/testInsettingByRectangleShouldNotProduceNegativeRectangle.st M Graphics-Tests.package/RectangleTest.class/instance/tests/testRectangleWithNegativeExtentShouldHaveZeroExtent.st A Graphics-Tests.package/RectangleTest.class/instance/tests/testRotateBy.st A Graphics-Tests.package/RectangleTest.class/instance/tests/testScaleBy.st A Graphics-Tests.package/RectangleTest.class/instance/tests/testTranslateBy.st M Refactoring-Critics.package/RBAllAnyNoneSatisfyRule.class/instance/accessing/name.st M Refactoring-Critics.package/RBCodeCruftLeftInMethodsRule.class/instance/initialization/initialize.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script315.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40315.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40315 14272 #_foo: isBinary ---> true https://pharo.fogbugz.com/f/cases/14272 14221 Tests around Graphics https://pharo.fogbugz.com/f/cases/14221 14271 RBCodeCruftLeftInMethodsRule>>initialize and RBAllAnyNoneSatisfyRule>>name have spelling errors https://pharo.fogbugz.com/f/cases/14271 http://files.pharo.org/image/40/40315.zip

Oct. 21, 2014

Re: [Pharo-dev] Spec Understandability

by stepharo

Note that halo implementation sucks! In Bloc alain clean it and he is able to plug halos and package them cleanly. In addition in Bloc he took the decision not to implement for now the direct creation of certain widget because this kind of feature leads to spaghetti dependencies. Stef On 20/10/14 20:35, Sean P. DeNigris wrote: > Ralph Boland wrote >> I am not in the habit of using halos, not really sure what they are for. >> But your description implies they are quite useful. >> What does "bring up halos on and inspect a button to see how to duplicate >> its action" mean? Could you please describe in step by step detail. > Hi Ralph! I think the best way to understand why Morphic is revolutionary is > to read the papers of its creators (e.g. > http://web.media.mit.edu/~jmaloney/papers/DirectnessAndLivenessInMorphic.pdf) > I also wrote http://stackoverflow.com/a/4410189/424245 which should give a > taste and also answers your question more directly. HTH. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Spec-Understandability-tp4778370p4785597.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Oct. 21, 2014

[pharo-project/pharo-core] 3e9067: 40314

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 3e906711b6a1c3b127beca11f7924cae7844e03a https://github.com/pharo-project/pharo-core/commit/3e906711b6a1c3b127beca11… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-21 (Tue, 21 Oct 2014) Changed paths: M Kernel.package/CompiledMethodTrailer.class/instance/accessing/setSourceBySelector.st M Kernel.package/CompiledMethodTrailer.class/instance/decoding/decodeNoTrailer.st M Kernel.package/CompiledMethodTrailer.class/instance/encoding/encodeNoTrailer.st M Kernel.package/CompiledMethodTrailer.class/instance/encoding/encodeSourceBySelector.st A Kernel.package/CompiledMethodTrailer.class/instance/initialization/clear.st A Kernel.package/CompiledMethodTrailer.class/instance/initialization/method_.st R Kernel.package/CompiledMethodTrailer.class/instance/initialize-release/clear.st R Kernel.package/CompiledMethodTrailer.class/instance/initialize-release/method_.st M KernelTests.package/CompiledMethodTrailerTest.class/instance/tests/testEncodingNoTrailer.st M Komitter.package/KomitterUI.class/class/specs/defaultSpec.st M NativeBoost-Core.package/NativeBoost.class/class/subscribing for session change/notifyAboutSessionChange_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script314.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40314.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40314 14269 Komitter: Improve layout for long repo names https://pharo.fogbugz.com/f/cases/14269 14242 Installing a method is slow https://pharo.fogbugz.com/f/cases/14242 14257 Replace Announcer>>#on:send:to:s senders in NativeBoost-Core https://pharo.fogbugz.com/f/cases/14257 http://files.pharo.org/image/40/40314.zip

Oct. 21, 2014