- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] New Gold Member LabWare

by Pablo R. Digonzelli

+100 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 ----- Mensaje original ----- De: "stepharo" <stepharo(a)free.fr> Para: "Pharo Development List" <pharo-dev(a)lists.pharo.org> Enviados: Lunes, 20 de Octubre 2014 17:19:01 Asunto: Re: [Pharo-dev] [ANN] New Gold Member LabWare On 17/10/14 17:42, Esteban A. Maringolo wrote: > Indeed it is. > > AFAIR Andres Valloud works there. oh yes big big thanks to him.

Oct. 20, 2014

Re: [Pharo-dev] [ANN] New Gold Member LabWare

by stepharo

On 17/10/14 17:42, Esteban A. Maringolo wrote: > Indeed it is. > > AFAIR Andres Valloud works there. oh yes big big thanks to him.

Oct. 20, 2014

Re: [Pharo-dev] Question on Package comments [SO]

by stepharo

Hi nicolai - ideally I would like a small DSL to describe the key design of a package. - then the configuration of the package is the place to put a documentation https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/ - when the configuration is loaded, the fly by help on the name of the package shows the description. - we could also use the package manifest. Christophe is in the process of redoing everything now that my prototype shows that it could work nicely. Stef On 17/10/14 17:30, Nicolai Hess wrote: > There was a question on SO about documentations for Packages: > http://stackoverflow.com/questions/26292060/is-there-any-pharo-package-refe… > > I don't have enough reputation for adding comments in SO, > therefore, I ask the questions here: > > The question is closed and I don't understand why. > It is a valid question and I do > remember that this was a topic on this list as well: > show document/help text in configuration browser/ > tooltip for packages in Nautilus/ > comment package like it is done for classes. > > For that user, who asked the question on SO: > At least for external packages there are sometimes some > information on github or squeaksource and we should show him > a link to the pharo user mailing list. > > > > (and no, the http://lmgtfy.com/ link is not helpful nor funny) > > > nicolai > > >

Oct. 20, 2014

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

by Esteban Lorenzano

> On 20 Oct 2014, at 21:41, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Mon, Oct 20, 2014 at 8:26 AM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > 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. > > I absolutely agree. > > So why do you want to have imageSegment? > > Because of backwards-compatibility. If Spur does not provide image segments then the barrier to entry for Terf, eToys and Squeak may be too high. Spur is supposed to be a plug-in replacement for Cog, not something that requires lots of effort to port to. butâ¦ (and tell me if Iâm saying something stupid), it would be probably better to ask the guys using ImageSegments to spend some time doing an adaptor to use fuel (who is already there, works fine and faster than ImageSegments itself). In the not-so-long term, is better investment that make you replicate a technology that we all agree is not the best option (also, I would bet is better to use your valuable time in other stuff). Is not that there is no alternative to ISâ¦ and also, the IS binary format for Spur will not be compatible with the older one, soâ¦ why not? anyway, thatâs my 2c Esteban > > 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 > > > > > -- > best, > Eliot

Oct. 20, 2014

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

by stepharo

Sorry for breaking the stream. I could not find the email with thunderbird :( Just for the record, you see what netstyle people did: they use image segment and they had to kill everything (like processes and others) because of possible pointers so after saving a segment the image was basically dead because some escaping pointers to make a kind of memory leak. Now they migrated to Fuel. So now I think that people should better use Fuel. IS were nice at first but not when you look carefully to them, especially when you have an object not in the roots pointing to an object inside the graph. Then you have to do a GCâ¦. Mariano spent a year fighting with that and his PhD is really nice. Less magic, more stability, simpler VMs. Because all the energy that you will put in something from the past will not be put in things for the future(not counting the bug hunting). Stef On Mon, Oct 20, 2014 at 8:26 AM, stepharo <stepharo(a)free.fr> wrote: 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. I absolutely agree. So why do you want to have imageSegment? Because of backwards-compatibility. If Spur does not provide image segments then the barrier to entry for Terf, eToys and Squeak may be too high. Spur is supposed to be a plug-in replacement for Cog, not something that requires lots of effort to port to

Oct. 20, 2014

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

by Eliot Miranda

On Mon, Oct 20, 2014 at 8:26 AM, stepharo <stepharo(a)free.fr> wrote: > 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. > I absolutely agree. > So why do you want to have imageSegment? > Because of backwards-compatibility. If Spur does not provide image segments then the barrier to entry for Terf, eToys and Squeak may be too high. Spur is supposed to be a plug-in replacement for Cog, not something that requires lots of effort to port to. > 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 > > > -- best, Eliot

Oct. 20, 2014

Re: [Pharo-dev] [for testing] speeding up code loading

by Sven Van Caekenberghe

> On 20 Oct 2014, at 20:09, Marcus Denker <marcus.denker(a)gmail.com> wrote: > > Ceterum censeo: we need to get rid of sources/changesâ¦ Now I learned another Latin proverb, nice !

Oct. 20, 2014

Re: [Pharo-dev] Spec Understandability

by Sean P. DeNigris

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. 20, 2014

Re: [Pharo-dev] [for testing] speeding up code loading

by Marcus Denker

On Monday, Oct 20, 2014 at 7:46 pm, Esteban A. Maringolo <emaringolo(a)gmail.com>, wrote: 2014-10-20 12:50 GMT-03:00 Marcus Denker : > Hi, > > [Object compileSilently: 'foo ^ 1' classified: 'testing'] bench > > -- 267 per second > > Load from inbox: > SLICE-Issue-14242-Installing-a-method-is-slow-MarcusDenker.3 > > run bench again ==> 2320 per second. > > This will work as long the .changes is small enough so that it uses a > normal > (not extended) source pointer. What is "small enough"? @inria.fr> some 32MB Â How can I compress the changes file? @inria.fr> PharoChangesCondenser condense. Ceterum censeo: we need to get rid of sources/changesâ¦Â Â Â Marcus

Oct. 20, 2014

Re: [Pharo-dev] [for testing] speeding up code loading

by Sven Van Caekenberghe

> On 20 Oct 2014, at 19:45, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > 2014-10-20 12:50 GMT-03:00 Marcus Denker <marcus.denker(a)inria.fr>: >> Hi, >> >> [Object compileSilently: 'foo ^ 1' classified: 'testing'] bench >> >> -- 267 per second >> >> Load from inbox: >> SLICE-Issue-14242-Installing-a-method-is-slow-MarcusDenker.3 >> >> run bench again ==> 2320 per second. >> >> This will work as long the .changes is small enough so that it uses a >> normal >> (not extended) source pointer. > > > What is "small enough"? > > How can I compress the changes file? PharoChangesCondenser > Regards!

Oct. 20, 2014