- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 94b774: 50573

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 94b7749d57060689f8e2e88dbf472ce504f15289 https://github.com/pharo-project/pharo-core/commit/94b7749d57060689f8e2e88d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-02-09 (Tue, 09 Feb 2016) Changed paths: A Rubric.package/RubShoutStylerDecorator.class/instance/composition/recomposeFrom_to_delta_.st M Rubric.package/RubTextComposer.class/instance/private composition/recomposeFrom_to_delta_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50572.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50573.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50572.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50573.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Sources.package/ChangesLog.class/instance/event-listening/registerToAnnouncements.st Log Message: ----------- 50573 17551 random fail on RubTextComposer>>recomposeFrom:to:delta: https://pharo.fogbugz.com/f/cases/17551 17549 ChangesLog should subscribe weakly to SystemAnnouncer https://pharo.fogbugz.com/f/cases/17549 17538 Remove dead SystemAnnouncer subscriptions https://pharo.fogbugz.com/f/cases/17538 http://files.pharo.org/image/50/50573.zip

Feb. 9, 2016

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

by Christophe Demarey

Le 9 fÃ©vr. 2016 Ã 14:12, Guille Polito a Ã©crit : > However, now that we found that something was missing in the startup list, we should check for others... There are currently 3 classes not registered in the startup list: #SystemSettingsPersistence #MCGitBasedNetworkRepository #UUIDGenerator A slice is ready to fix that: https://pharo.fogbugz.com/f/cases/17553/missing-classes-in-startup-list

Feb. 9, 2016

Re: [Pharo-dev] Some questions

by Alain Plantec

> > The same for me... Besides SpaceElement there is BlSpace which is a model. > Doru suggested to rename: > > BlWorldElement -> BlWorld > BlSpace -> BlSpaceModel > BlSpaceElement -> BlSpace > > Would such naming by more self-describing for you? yes Alain

Feb. 9, 2016

Re: [Pharo-dev] Bloc Documentation

by Alain Plantec

and please, do not ask too much to Alex. Alex is doing a pass (great job), and (I guess) he is doing it alone. I will come back to Pharo and Bloc in two weeks, reimplement examples and adapt the first Bloc documentation that we did with Stephane. Then it will be easier for the community to help. Cheers Alain > On 9 fÃ©vr. 2016, at 14:26, Alain Plantec <alain.plantec(a)yahoo.com> wrote: > > >> On 9 fÃ©vr. 2016, at 13:24, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> On 09/02/16 11:53, Aliaksei Syrel wrote: >>> So I'm asking: what parts of Bloc do you find especially complicated to >>> understand. so we could concentrate on them? Root class >>> BlElement(methods) has good doc, so please use it to start your >>> exploration journey. >> >> A lot of confusing comes from BlMorphXX things still being around all over the place. I prefer good examples as a starting point. Making Bloc-DragPanels work again? > > yes, it should be easy to adapt it to the current Bloc implementation. > I will reimplement examples. > And you will see that things are nearly the same regarding Bloc user point of view. > Cheers > Alain > > >> >> Stephan >> >> >> >

Feb. 9, 2016

Re: [Pharo-dev] Bloc Documentation

by Alain Plantec

> On 9 fÃ©vr. 2016, at 13:24, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 09/02/16 11:53, Aliaksei Syrel wrote: >> So I'm asking: what parts of Bloc do you find especially complicated to >> understand. so we could concentrate on them? Root class >> BlElement(methods) has good doc, so please use it to start your >> exploration journey. > > A lot of confusing comes from BlMorphXX things still being around all over the place. I prefer good examples as a starting point. Making Bloc-DragPanels work again? yes, it should be easy to adapt it to the current Bloc implementation. I will reimplement examples. And you will see that things are nearly the same regarding Bloc user point of view. Cheers Alain > > Stephan > > >

Feb. 9, 2016

Re: [Pharo-dev] Bloc Documentation

by Alain Plantec

Hello, yes, #formerOwner: and #formerPosition: are here for compatibility with Morphic. and it will be like that for a while :) The bloc drag&drop mechanism is implemented differently with the help of events. Cheers Alain > On 9 fÃ©vr. 2016, at 13:25, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > formerOwner: anElementOrNil > "Set my former or remove property of argument is nil" > > anElementOrNil > ifNil: [ self removeProperty: #formerOwner ] > ifNotNil: [ self setProperty: #formerOwner toValue: anElementOrNil ] > > I hate this method :) It is identical to Morph>>#formerOwner: (ctrl+c, ctrl+v) > Basically it should be removed after reimplementation of drag&drop mechanism. Current one was copied from morphic to support compatibility. > We will need to find better solution. Drag&drop is not so easy to do right. Help from community is appreciated :) > > Cheers, > Alex > > On Tue, Feb 9, 2016 at 1:12 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > formerOwner: anElementOrNil > "Set my former or remove property of argument is nil" > > anElementOrNil > ifNil: [ self removeProperty: #formerOwner ] > ifNotNil: [ self setProperty: #formerOwner toValue: anElementOrNil ] > > I'd prefer to see a #setProperty:toValueOrRemove: there, > as that pattern is used a lot. > > Stephan > > >

Feb. 9, 2016

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

by Ben Coman

On Tue, Feb 9, 2016 at 9:12 PM, Guille Polito <guillermopolito(a)gmail.com> wrote: > AAAANNNDDD! It looks I found the real cause of this! > > - I tested an image pre-new session manager, and an image post-new session > manager. The issue only appeared in the latter. > > - Checking, it seems that UUIDGenerator is not subscribed to the new startup > list. This means that the UUIDGenerator is not being reinitialized on every > startup. This means, moreover, that every person that is loading the latest > Pharo image is using the same UUIDGenerator instance, with the same random > seed => same generated UUIDs. > > So, adding UUIDGenerator to the list would be the simplest solution and the > integration of NeoUUIDGenerator can be moved to Pharo6 maybe. > > However, now that we found that something was missing in the startup list, > we should check for others... > > Guille Good find. How can we make a test for this? Maybe it needs to be done from outside the image? cheers -ben > > > On 02/09/2016 10:36 AM, Guille Polito wrote: >> >> Yes, go on. I think it is the easiest. >> >> Right now, to check if a slice is good or not I have to commit, browse >> Smalltalkhub's UI, and if it not good I have to delete the mcz manually... >> >> On 02/09/2016 10:10 AM, Sven Van Caekenberghe wrote: >>> >>> You want me to do it then ? >>> >>> I don't want us to do double work ... >>> >>>> On 09 Feb 2016, at 10:09, Guillermo Polito <guillermopolito(a)gmail.com> >>>> wrote: >>>> >>>> Sad and true... :'( >>>> >>>> On Tue, Feb 9, 2016 at 10:01 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >>>> wrote: >>>> Beside, you can't make slices ;-) >>>> >>>>> On 09 Feb 2016, at 09:58, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>> I can do the integration too, but I need some people to say go ahead. >>>>> I vote for replacing everything, there is no need for a plugin. >>>>> >>>>>> On 09 Feb 2016, at 09:25, Guille Polito <guillermopolito(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>> Sven, just to answer your last question. The UUID generation right now >>>>>> generates the UUID fields like this: >>>>>> >>>>>> UUIDGenerator>>generateFieldsVersion4 >>>>>> >>>>>> timeLow := self generateRandomBitsOfLength: 32. >>>>>> timeMid := self generateRandomBitsOfLength: 16. >>>>>> timeHiAndVersion := 16r4000 bitOr: (self >>>>>> generateRandomBitsOfLength: 12). >>>>>> clockSeqHiAndReserved := 16r80 bitOr: (self >>>>>> generateRandomBitsOfLength: 6). >>>>>> clockSeqLow := self generateRandomBitsOfLength: 8. >>>>>> node := self generateRandomBitsOfLength: 48. >>>>>> >>>>>> So... It's basically completely random. There is no part of the UUID >>>>>> that is actually based on the node, the clock or the time. It is actually a >>>>>> random string of bits that are generated using a number from /dev/urandom as >>>>>> seed (in linux). >>>>>> >>>>>> Does the mac VM include the plugin? (I do not have a mac any more to >>>>>> test fast ^^) >>>>>> >>>>>> I'll work on the integration of NeoUUID now, I hope this is the kind >>>>>> of issues that got integrated in code-freeze :) >>>>>> >>>>>> Guille >>>>>> >>>>>> On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote: >>>>>>> >>>>>>> Here is a new version, in preparation of possible integration in the >>>>>>> main image: >>>>>>> >>>>>>> === >>>>>>> Name: Neo-UUID-SvenVanCaekenberghe.2 >>>>>>> Author: SvenVanCaekenberghe >>>>>>> Time: 8 February 2016, 8:33:04.141334 pm >>>>>>> UUID: a909453e-35dd-4c25-8273-62a9b2bd982e >>>>>>> Ancestors: Neo-UUID-SvenVanCaekenberghe.1 >>>>>>> >>>>>>> Streamline UUID generation >>>>>>> >>>>>>> Add a current, shared instance >>>>>>> >>>>>>> Added better class and method comments >>>>>>> >>>>>>> Add more tests >>>>>>> >>>>>>> As suggested by Henrik Johansen, change to a version 0 UUID to >>>>>>> indicate that we follow a custom approach >>>>>>> === >>>>>>> >>>>>>> The class comments now reads as follows: >>>>>>> >>>>>>> === >>>>>>> I am NeoUUIDGenerator, I generate UUIDs. >>>>>>> >>>>>>> An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit >>>>>>> number that can be used for identification purposes. Concretely, a UUID is a >>>>>>> 16 element byte array. >>>>>>> >>>>>>> The intent of UUIDs is to enable distributed systems to uniquely >>>>>>> identify information without significant central coordination. In this >>>>>>> context the word unique should be taken to mean "practically unique" rather >>>>>>> than "guaranteed unique". >>>>>>> I generate UUIDs similar, in spirit, to those defined in RFC4122, >>>>>>> though I use version 0 to indicate that I follow none of the defined >>>>>>> versions. This does not matter much, if at all, in practice. >>>>>>> >>>>>>> I try to conform to the following aspects: >>>>>>> - each 'node' (machine, image, instance) should generate unique UUIDs >>>>>>> - even when generating UUIDs at a very fast rate, they should remain >>>>>>> unique >>>>>>> - be fast and efficient >>>>>>> >>>>>>> To achieve this goal, I >>>>>>> - take several aspects into account to generate a unique node ID >>>>>>> - combine a clock, a counter and some random bits >>>>>>> - hold a state, protected for multi user access >>>>>>> >>>>>>> I can generate about 500K UUIDs per second. >>>>>>> >>>>>>> Implementation: >>>>>>> >>>>>>> Although a UUID should be seen as totally opaque, here is the >>>>>>> concrete way I generate one: >>>>>>> - the first 8 bytes are the millisecond clock value with the smallest >>>>>>> quantity first; this means that the later of these 8 bytes will be identical >>>>>>> when generated with small(er) timespans; within the same millisecond, the >>>>>>> full first 8 bytes will be identical >>>>>>> - the next 2 bytes represent a counter with safe overflow, held as >>>>>>> protected state inside me; after 2*16 this value will repeat; the counter >>>>>>> initalizes with a random value >>>>>>> - the next 2 bytes are simply random, based on the system PRNG, >>>>>>> Random >>>>>>> - the final 4 bytes represent the node ID; the node ID is unique per >>>>>>> instance of me, across OS environments where the image might run; the node >>>>>>> ID is the MD5 hash of a string that is the concatenation of several elements >>>>>>> (see #computeNodeIdentifier) >>>>>>> Some bits are set to some predefined value, to indicate the variant >>>>>>> and version (see #setVariantAndVersion:) >>>>>>> >>>>>>> Usage: >>>>>>> >>>>>>> NeoUUIDGenerator next. >>>>>>> NeoUUIDGenerator current next. >>>>>>> NeoUUIDGenerator new next. >>>>>>> >>>>>>> Sharing an instance is more efficient and correct. >>>>>>> Instances should be reset whenever the image comes up. >>>>>>> >>>>>>> See also: >>>>>>> >>>>>>> http://en.wikipedia.org/wiki/UUID >>>>>>> https://tools.ietf.org/html/rfc4122 >>>>>>> === >>>>>>> >>>>>>> If we integrate this, I think we should replace the old generator and >>>>>>> the use of the primitive/plugin. But that requires at least some support >>>>>>> apart from me. >>>>>>> >>>>>>> And although I think that we should integrate this generator and get >>>>>>> rid of the plugin, I think there is probably an underlying problem here (why >>>>>>> did the generator fail ?) that could be important to find. >>>>>>> >>>>>>> Sven >>>>>>> >>>>>>>> On 08 Feb 2016, at 10:38, Henrik Johansen >>>>>>>> <henrik.s.johansen(a)veloxit.no> wrote: >>>>>>>> >>>>>>>>> On 08 Feb 2016, at 10:29 , Sven Van Caekenberghe <sven(a)stfx.eu> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> 2) Misrepresenting the way the UUID was generated (a combination >>>>>>>>>> of node identifier + timestamp + random value, similar to type 3, but with >>>>>>>>>> differently sized/ordered fields) by marking it as being of type 4, which is >>>>>>>>>> defined to be UUID consisting of random bytes. >>>>>>>>>> IOW, I think it should be marked as type 0 instead of 4, so for >>>>>>>>>> the 1 person in each country who might be found to assume something about >>>>>>>>>> the implementation based on the type field, won't later feel he's been duped >>>>>>>>>> when checking the generator. >>>>>>>>> >>>>>>>>> OK, I certainly want to change the type. Thing is, I cannot find a >>>>>>>>> reference to type 0 anywhere that I am looking (I mostly used >>>>>>>>> https://en.wikipedia.org/wiki/Universally_unique_identifier) Where did you >>>>>>>>> find a definition of type 0 ? Or would that be a way to say 'no specific >>>>>>>>> type' then ? >>>>>>>> >>>>>>>> My rationale was that it is currently unassigned, and the least >>>>>>>> likely number to be chosen as identifier by new versions of the standard. >>>>>>>> IOW, for those who care, it might raise a "hmm, this is strange, >>>>>>>> better check the source", upon which they will discover it is generated in a >>>>>>>> non-standard fashion (but can verify for themselves it is generated in a way >>>>>>>> still pretty much guaranteed to be unique), and the rest... well, they can >>>>>>>> (most probably) keep on living happily without ever seeing a collision. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Henry >>>> >>>> >> > >

Feb. 9, 2016

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

by Guille Polito

AAAANNNDDD! It looks I found the real cause of this! - I tested an image pre-new session manager, and an image post-new session manager. The issue only appeared in the latter. - Checking, it seems that UUIDGenerator is not subscribed to the new startup list. This means that the UUIDGenerator is not being reinitialized on every startup. This means, moreover, that every person that is loading the latest Pharo image is using the same UUIDGenerator instance, with the same random seed => same generated UUIDs. So, adding UUIDGenerator to the list would be the simplest solution and the integration of NeoUUIDGenerator can be moved to Pharo6 maybe. However, now that we found that something was missing in the startup list, we should check for others... Guille On 02/09/2016 10:36 AM, Guille Polito wrote: > Yes, go on. I think it is the easiest. > > Right now, to check if a slice is good or not I have to commit, browse > Smalltalkhub's UI, and if it not good I have to delete the mcz > manually... > > On 02/09/2016 10:10 AM, Sven Van Caekenberghe wrote: >> You want me to do it then ? >> >> I don't want us to do double work ... >> >>> On 09 Feb 2016, at 10:09, Guillermo Polito >>> <guillermopolito(a)gmail.com> wrote: >>> >>> Sad and true... :'( >>> >>> On Tue, Feb 9, 2016 at 10:01 AM, Sven Van Caekenberghe >>> <sven(a)stfx.eu> wrote: >>> Beside, you can't make slices ;-) >>> >>>> On 09 Feb 2016, at 09:58, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>> I can do the integration too, but I need some people to say go ahead. >>>> I vote for replacing everything, there is no need for a plugin. >>>> >>>>> On 09 Feb 2016, at 09:25, Guille Polito >>>>> <guillermopolito(a)gmail.com> wrote: >>>>> >>>>> Sven, just to answer your last question. The UUID generation right >>>>> now generates the UUID fields like this: >>>>> >>>>> UUIDGenerator>>generateFieldsVersion4 >>>>> >>>>> timeLow := self generateRandomBitsOfLength: 32. >>>>> timeMid := self generateRandomBitsOfLength: 16. >>>>> timeHiAndVersion := 16r4000 bitOr: (self >>>>> generateRandomBitsOfLength: 12). >>>>> clockSeqHiAndReserved := 16r80 bitOr: (self >>>>> generateRandomBitsOfLength: 6). >>>>> clockSeqLow := self generateRandomBitsOfLength: 8. >>>>> node := self generateRandomBitsOfLength: 48. >>>>> >>>>> So... It's basically completely random. There is no part of the >>>>> UUID that is actually based on the node, the clock or the time. It >>>>> is actually a random string of bits that are generated using a >>>>> number from /dev/urandom as seed (in linux). >>>>> >>>>> Does the mac VM include the plugin? (I do not have a mac any more >>>>> to test fast ^^) >>>>> >>>>> I'll work on the integration of NeoUUID now, I hope this is the >>>>> kind of issues that got integrated in code-freeze :) >>>>> >>>>> Guille >>>>> >>>>> On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote: >>>>>> Here is a new version, in preparation of possible integration in >>>>>> the main image: >>>>>> >>>>>> === >>>>>> Name: Neo-UUID-SvenVanCaekenberghe.2 >>>>>> Author: SvenVanCaekenberghe >>>>>> Time: 8 February 2016, 8:33:04.141334 pm >>>>>> UUID: a909453e-35dd-4c25-8273-62a9b2bd982e >>>>>> Ancestors: Neo-UUID-SvenVanCaekenberghe.1 >>>>>> >>>>>> Streamline UUID generation >>>>>> >>>>>> Add a current, shared instance >>>>>> >>>>>> Added better class and method comments >>>>>> >>>>>> Add more tests >>>>>> >>>>>> As suggested by Henrik Johansen, change to a version 0 UUID to >>>>>> indicate that we follow a custom approach >>>>>> === >>>>>> >>>>>> The class comments now reads as follows: >>>>>> >>>>>> === >>>>>> I am NeoUUIDGenerator, I generate UUIDs. >>>>>> >>>>>> An RFC4122 Universally Unique Identifier (UUID) is an opaque >>>>>> 128-bit number that can be used for identification purposes. >>>>>> Concretely, a UUID is a 16 element byte array. >>>>>> >>>>>> The intent of UUIDs is to enable distributed systems to uniquely >>>>>> identify information without significant central coordination. In >>>>>> this context the word unique should be taken to mean "practically >>>>>> unique" rather than "guaranteed unique". >>>>>> I generate UUIDs similar, in spirit, to those defined in RFC4122, >>>>>> though I use version 0 to indicate that I follow none of the >>>>>> defined versions. This does not matter much, if at all, in practice. >>>>>> >>>>>> I try to conform to the following aspects: >>>>>> - each 'node' (machine, image, instance) should generate unique >>>>>> UUIDs >>>>>> - even when generating UUIDs at a very fast rate, they should >>>>>> remain unique >>>>>> - be fast and efficient >>>>>> >>>>>> To achieve this goal, I >>>>>> - take several aspects into account to generate a unique node ID >>>>>> - combine a clock, a counter and some random bits >>>>>> - hold a state, protected for multi user access >>>>>> >>>>>> I can generate about 500K UUIDs per second. >>>>>> >>>>>> Implementation: >>>>>> >>>>>> Although a UUID should be seen as totally opaque, here is the >>>>>> concrete way I generate one: >>>>>> - the first 8 bytes are the millisecond clock value with the >>>>>> smallest quantity first; this means that the later of these 8 >>>>>> bytes will be identical when generated with small(er) timespans; >>>>>> within the same millisecond, the full first 8 bytes will be >>>>>> identical >>>>>> - the next 2 bytes represent a counter with safe overflow, held >>>>>> as protected state inside me; after 2*16 this value will repeat; >>>>>> the counter initalizes with a random value >>>>>> - the next 2 bytes are simply random, based on the system PRNG, >>>>>> Random >>>>>> - the final 4 bytes represent the node ID; the node ID is unique >>>>>> per instance of me, across OS environments where the image might >>>>>> run; the node ID is the MD5 hash of a string that is the >>>>>> concatenation of several elements (see #computeNodeIdentifier) >>>>>> Some bits are set to some predefined value, to indicate the >>>>>> variant and version (see #setVariantAndVersion:) >>>>>> >>>>>> Usage: >>>>>> >>>>>> NeoUUIDGenerator next. >>>>>> NeoUUIDGenerator current next. >>>>>> NeoUUIDGenerator new next. >>>>>> >>>>>> Sharing an instance is more efficient and correct. >>>>>> Instances should be reset whenever the image comes up. >>>>>> >>>>>> See also: >>>>>> >>>>>> http://en.wikipedia.org/wiki/UUID >>>>>> https://tools.ietf.org/html/rfc4122 >>>>>> === >>>>>> >>>>>> If we integrate this, I think we should replace the old generator >>>>>> and the use of the primitive/plugin. But that requires at least >>>>>> some support apart from me. >>>>>> >>>>>> And although I think that we should integrate this generator and >>>>>> get rid of the plugin, I think there is probably an underlying >>>>>> problem here (why did the generator fail ?) that could be >>>>>> important to find. >>>>>> >>>>>> Sven >>>>>> >>>>>>> On 08 Feb 2016, at 10:38, Henrik Johansen >>>>>>> <henrik.s.johansen(a)veloxit.no> wrote: >>>>>>> >>>>>>>> On 08 Feb 2016, at 10:29 , Sven Van Caekenberghe <sven(a)stfx.eu> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> 2) Misrepresenting the way the UUID was generated (a >>>>>>>>> combination of node identifier + timestamp + random value, >>>>>>>>> similar to type 3, but with differently sized/ordered fields) >>>>>>>>> by marking it as being of type 4, which is defined to be UUID >>>>>>>>> consisting of random bytes. >>>>>>>>> IOW, I think it should be marked as type 0 instead of 4, so >>>>>>>>> for the 1 person in each country who might be found to assume >>>>>>>>> something about the implementation based on the type field, >>>>>>>>> won't later feel he's been duped when checking the generator. >>>>>>>> OK, I certainly want to change the type. Thing is, I cannot >>>>>>>> find a reference to type 0 anywhere that I am looking (I mostly >>>>>>>> used >>>>>>>> https://en.wikipedia.org/wiki/Universally_unique_identifier) >>>>>>>> Where did you find a definition of type 0 ? Or would that be a >>>>>>>> way to say 'no specific type' then ? >>>>>>> My rationale was that it is currently unassigned, and the least >>>>>>> likely number to be chosen as identifier by new versions of the >>>>>>> standard. >>>>>>> IOW, for those who care, it might raise a "hmm, this is strange, >>>>>>> better check the source", upon which they will discover it is >>>>>>> generated in a non-standard fashion (but can verify for >>>>>>> themselves it is generated in a way still pretty much guaranteed >>>>>>> to be unique), and the rest... well, they can (most probably) >>>>>>> keep on living happily without ever seeing a collision. >>>>>>> >>>>>>> Cheers, >>>>>>> Henry >>> >

Feb. 9, 2016

Re: [Pharo-dev] Bloc Documentation

by Ben Coman

On Tue, Feb 9, 2016 at 4:15 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Bloc does not have examples yet. > What classes/methods do you need to be commented first to understand the > system? > > On Feb 9, 2016 4:46 AM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: >> >> I realize it's a fast-moving work in progress, but what's the best way to >> try >> to understand the system? >> >> For example, I saw class comments, some of which seem to be out of date, >> and >> I no longer see many of the examples I remember from last year - maybe I >> have to load them separately? Maybe... How about starting with some old fashioned hand sketches, scanned, with maybe some audio attached to the static image describing the architecture would give people the quickest start. Just like you were introducing someone new who was sitting next to you -- but for those of us aroudn the world who can't make there ;). Or maybe (??) do an adhoc whiteboard presentation to a few people locally that you video. It doesn't need to be nicely edited. These might be quicker than sitting down to write class comments - and maybe others can assist by extracting class comments from this material. cheers -ben

Feb. 9, 2016

Re: [Pharo-dev] Bloc Documentation

by Aliaksei Syrel

> > Please add a comment in the method stating it. > People are not reading your mind. I know :) I'm arguing that some classes/method could wait. We need to concentrate on most important ones. And then come to the rest. On Tue, Feb 9, 2016 at 1:52 PM, stepharo <stepharo(a)free.fr> wrote: > Please add a comment in the method stating it. > People are not reading your mind. > > Stef > > Le 9/2/16 13:25, Aliaksei Syrel a Ã©crit : > > formerOwner: anElementOrNil >> "Set my former or remove property of argument is nil" >> >> anElementOrNil >> ifNil: [ self removeProperty: #formerOwner ] >> ifNotNil: [ self setProperty: #formerOwner toValue: >> anElementOrNil ] > > > I hate this method :) It is identical to Morph>>#formerOwner: (ctrl+c, > ctrl+v) > Basically it should be removed after reimplementation of drag&drop > mechanism. Current one was copied from morphic to support compatibility. > We will need to find better solution. Drag&drop is not so easy to do > right. Help from community is appreciated :) > > Cheers, > Alex > > On Tue, Feb 9, 2016 at 1:12 PM, Stephan Eggermont < <stephan(a)stack.nl> > stephan(a)stack.nl> wrote: > >> formerOwner: anElementOrNil >> "Set my former or remove property of argument is nil" >> >> anElementOrNil >> ifNil: [ self removeProperty: #formerOwner ] >> ifNotNil: [ self setProperty: #formerOwner toValue: >> anElementOrNil ] >> >> I'd prefer to see a #setProperty:toValueOrRemove: there, >> as that pattern is used a lot. >> >> Stephan >> >> >> > >

Feb. 9, 2016