- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] news from block :)

by stepharo

> Same here. None of them are replacementsâ¦ is a framework for > visualisations (in the case of Roassal) and a framework for drawing > (in case of Athens). One is on top of Morphic and the other is below > it (you can do morphs that are drawn with Athens). In the future Bloc will use Athens to display Blocs :) >> I don't have a problem with Pharo abandoning Morphic. Afterally you >> all use Pharo far more than I do. I will continue learning Spec, >> Roassal and Athens. But for me Morphic is the most beautiful Graphics >> API I have ever worked with. > > We are not moving out from Morphic any time soon. > Also, moving from an implementation of Morphic does not means we are > going to refuse his general design or all the cool experience we > accumulated in the time. > Think on morphic and block like with Battlestar Galactica from 1978 > and 2003: Same general design, but a complete âre-imaginedâ taking > with us all we learned in the mean time :) Exactly :)

June 12, 2014

Re: [Pharo-dev] news from block :)

by stepharo

> I like the idea. The current Morph classes are too big. It is > difficult to understand them and to find out how to work with them > "the right way" (event handling for example or layouting). > > Can you describe something more about the design. Or is the design > a work in progress. > > Please, I hope the "properties"-Dictionary is only a left over for > Morphic compatibility. I never understood why these are > used instead of proper selector and objects representing actual > properties. > For some objects you need a hashtable-based object because you may need a property that does not make sense all the time or just for some kinds of objects. So the extension is not a bad idea per se but we should pay attention. Stef

June 12, 2014

[pharo-project/pharo-core]

by GitHub

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

June 12, 2014

[pharo-project/pharo-core] 9be0a2: 40021

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 9be0a245c89b952a28afea4d7c58d8f756407cc6 https://github.com/pharo-project/pharo-core/commit/9be0a245c89b952a28afea4d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-06-12 (Thu, 12 Jun 2014) Changed paths: M Kernel.package/Float.class/instance/private/absPrintOn_base_digitCount_.st M Komitter.package/KomitNewSlice.class/instance/accessing/remote.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script21.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40021.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tools.package/MethodFinder.class/instance/initialize/initialize.st Log Message: ----------- 40021 13089 reciprocalFloorLog: should be deprecated or just removed https://pharo.fogbugz.com/f/cases/13089 13303 komitter is still using Pharo30Inbox as destination of new slices https://pharo.fogbugz.com/f/cases/13303 http://files.pharo.org/image/40/40021.zip

June 12, 2014

HowToMakeYourOwnTutorial, how to launch my own?

by Marc-Philippe Huget

Hello everybody, I try to do a tutorial for our project and I decided to use ProfStef, so I follow the instructions as given in HowToMakeYourOwnTutorial, so * no problem to create a class inheriting from AbstractClass * creating two protocols lessons and tutorial * a method tutorial returning the list of tutorials as an array * a method per tutorial My only problem is regarding running this tutorial In ProfStef, we do ProfStef go but here, go is not recognized If I change from AbstractTutorial to PharoTutorial, I obviously have go, goOn and next but this is not my tutorial I guess this is a problem of player, but how? Thanks in advance for your help Regards, mph

June 12, 2014

Re: [Pharo-dev] news from block :)

by Alain Plantec

Hi Nicolai, > I like the idea. cool > The current Morph classes are too big. It is > difficult to understand them and to find out how to work with them > "the right way" (event handling for example or layouting). this is our goal to clean and make the hierarchy easier to understand. Morph has to much responsibilities. Regarding the Morph hierarchy, so far, there are: BlProtoMorph BlAtomicMorph BlImageMorph BlHandMorph BlMorph BlCompositeMorph BlMorphWithLayout ( not ready ) BlPasteUpMorph BlWorldMorph BlProtoMorph "space owner drawer announcer visible locked position properties layerNumber transform errorOnDraw" BlHandMorph "pointer targetOffset savedPatch dragged" BlImageMorph "form alpha cachedForm" BlMorph "extent layoutProperties fillStyle boundsCache eventHandler borderStyle" BlCompositeMorph "submorphs" BlMorphWithLayout "layoutPolicy" BlWorldMorph "menuBuilder" As an example of cleaning, just compare HandMorph and BlHandMorph. HandMorph 'mouseFocus keyboardFocus eventListeners mouseListeners keyboardListeners mouseClickState mouseOverHandler lastMouseEvent targetOffset damageRecorder cacheCanvas cachedCanvasHasHoles temporaryCursor temporaryCursorOffset hardwareCursor hasChanged savedPatch lastEventBuffer lastKeyScanCode combinedChar eventSource lastSystemEvent captureBlock recentModifiers' A lot of HandMorph responsibilities and inst vars are now implemented in other classes (BlUserInputProcessor and BlSpace) Sorry it is a bit short but we will explain them (and more) in deeper detail later with a separate documentation and then we will discuss and learn from feedbacks :) > > Can you describe something more about the design. Or is the design > a work in progress. yes, it is in progress > > Please, I hope the "properties"-Dictionary is only a left over for > Morphic compatibility. I never understood why these are > used instead of proper selector and objects representing actual > properties. It is mandatory for MorphCompatibility. A lot of properties have already been properly reified as inst vars. But I don't have a definitive opinion about if it is useful/good design or not. Cheers Alain > > nicolai > > > > On 11 juin 2014, at 22:11, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > I would be interested in trying to play with Block. Is it available? > > > > Cheers, > > Doru > > > > > > On Wed, Jun 11, 2014 at 9:55 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > On 11 Jun 2014, at 16:39, kilon alios <kilon.alios(a)gmail.com> wrote: > > > >> excellent news. I really believe in Morphic and I really like its general design. If you we can clean the mud I am sure we will discover quite a diamond underneath. Thanks. > > > > which general design? the pattern in which is based? thatâs not enough to keep it :) > > Sorry but there is no easy/efficient way to clean it. > > The only way to clean Morphic is to reimplement it. > > Clean it is just too much workâ¦ and too many design decisions where made that time and patches made them obsolete or not correct. > > Not to talk about the mix of concepts (bah, the no existence of separation between them). > > > > Block is not a clean. Is a revamp. > > > > No offence intended to Morphic: no matter how good was at the beginning, *every* system evolves up to a point the effort required to maintain it is superior to the effort required to reimplement it (with all the experience as a superior step). > > (yeah, yeahâ¦ a lot of people will disagree. But time has proven me rightâ¦ and will continue doing it :P) > > > > Esteban > > > >> > >> > >> On Wed, Jun 11, 2014 at 10:25 PM, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> wrote: > >> \o/ > >> > >> > >> On Wed, Jun 11, 2014 at 4:23 PM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > >> > >> On 11 juin 2014, at 15:31, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> wrote: > >> > >>> What is bloc ? > >>> I've searched in the pharo-dev list but couldn't find it :/ > >> > >> A Morphic clean/revamp lead by Alain and Stef. > >> > >>> > >>> On Wed, Jun 11, 2014 at 2:26 PM, stepharo <stepharo(a)free.fr> wrote: > >>> looks so exciting... > >>> > >>> From: Alain Plantec <alain.plantec(a)univ-brest.fr> > >>> Subject: Bloc news > >>> Date: 11 Jun 2014 14:10:29 GMT+2 > >>> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >>> Cc: Alain Plantec <alain.plantec(a)univ-brest.fr> > >>> > >>> Name: Bloc-Core-AlainPlantec.15 > >>> Author: AlainPlantec > >>> Time: 11 June 2014, 2:07:16.813171 pm > >>> UUID: d58ae82e-b5dd-41d9-bc31-a48c3e9e5cf1 > >>> Ancestors: Bloc-Core-AlainPlantec.14 > >>> > >>> - BlMorphs manage their submorphs with local coordinate. > >>> - Drawing and drag&drop has been adapted to local coordinate > >>> - Consequence: TransformationMorph should not be useful anymore because each morph has its own transform (not only TransformationMorph). Each morph uses its own transform to declare changed portions of its bounds and to draw its submorphs. > >>> - The world is no more a special morph: > >>> - the hand is owned by the space > >>> - the canvas and the display/redisplay of morphs are space responsibilities. > >>> This open the door to several worlds per space. > >>> > >>> Now the current global redrawing mechanism efficiency is not obvious. > >>> Next actions: > >>> - try to localize as much as possible the redrawing of morphs, > >>> - dig several Worlds for a space > >>> - start to comment and write a separate documentation with the help of Stephane :) > >>> > >>> > >>> > >> > >> > >> > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > >

June 12, 2014

Re: [Pharo-dev] [ANN] Base62/Base36

by Norbert Hartl

Hmm *cough* http://smalltalkhub.com/#!/~NorbertHartl/Base62 Norbert Am 12.06.2014 um 13:12 schrieb Norbert Hartl <norbert(a)hartl.name>: > Just for the record. Iâve uploaded a package to smalltalkhub that contains util classes to en-/decode values into/from Base62/Base36. > > Base62/Base36 encode numbers in short strings. These are used e.g. by url shortener services from google, bit.ly etc. > > Base36 uses lowercase letters and numbers to encode, Base62 uses all characters from Base36 plus all uppercase letters. Base62 produces smaller strings while Base36 produces case insensitive ones. > > Example: > > Base62 fromNumber: 100000 -> 'q0Uâ > > Base36 fromNumber: 100000 -> â255s' > > FYI, > > Norbert > >

June 12, 2014

[ANN] Base62/Base36

by Norbert Hartl

Just for the record. Iâve uploaded a package to smalltalkhub that contains util classes to en-/decode values into/from Base62/Base36. Base62/Base36 encode numbers in short strings. These are used e.g. by url shortener services from google, bit.ly etc. Base36 uses lowercase letters and numbers to encode, Base62 uses all characters from Base36 plus all uppercase letters. Base62 produces smaller strings while Base36 produces case insensitive ones. Example: Base62 fromNumber: 100000 -> 'q0Uâ Base36 fromNumber: 100000 -> â255s' FYI, Norbert

June 12, 2014

Re: [Pharo-dev] news from block :)

by Nicolai Hess

2014-06-12 10:01 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > > Am 11.06.2014 um 21:55 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > > On 11 Jun 2014, at 16:39, kilon alios <kilon.alios(a)gmail.com> wrote: > > excellent news. I really believe in Morphic and I really like its general > design. If you we can clean the mud I am sure we will discover quite a > diamond underneath. Thanks. > > > which general design? the pattern in which is based? thatâs not enough to > keep it :) > Sorry but there is no easy/efficient way to clean it. > The only way to clean Morphic is to reimplement it. > Clean it is just too much workâ¦ and too many design decisions where made > that time and patches made them obsolete or not correct. > Not to talk about the mix of concepts (bah, the no existence of separation > between them). > > Block is not a clean. Is a revamp. > > No offence intended to Morphic: no matter how good was at the beginning, > *every* system evolves up to a point the effort required to maintain it is > superior to the effort required to reimplement it (with all the experience > as a superior step). > (yeah, yeahâ¦ a lot of people will disagree. But time has proven me rightâ¦ > and will continue doing it :P) > > Of course, I disagree :) There is no such thing as a reimplementation of > software. I you reimplement it youâll develop something completely > different. If the prior code would be good there would be no point in > redoing it. And there is no point when redoing to do the same as before. > You redo and you have the freedom to design something new while you skip > all the wisdom/experience that has made its way into the old code. If you > make it good the new thing will be an improvement to the old. Mostly you > will end up having a new software with different problems but the same > amount :) > > Norbert > Sure, you can reimplement software, for example you can reimplent an API. The implemenation behind the scene may be totally different but if you still provide the same API, this is what I would call "reimplementation". The reimplentation can be still "better" even if it don't provide new functionality. (Better could mean: maintainable, modular, more performant) But in the case of Morphic, it is more like reimplenting an "Idea" rathern than an API. "If the prior code would be good there would be no point in redoing it" Yes, but we are not talking about "good code", but about Morphic :) ( I don't think morphic is bad or bad code, Morphic has many good parts. The bad thing is, it is all cluttered.) nicolai > > > > > On Wed, Jun 11, 2014 at 10:25 PM, FranÃ§ois Stephany < > tulipe.moutarde(a)gmail.com> wrote: > >> \o/ >> >> >> On Wed, Jun 11, 2014 at 4:23 PM, Camille Teruel <camille.teruel(a)gmail.com >> > wrote: >> >>> >>> On 11 juin 2014, at 15:31, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> >>> wrote: >>> >>> What is bloc ? >>> >>> I've searched in the pharo-dev list but couldn't find it :/ >>> >>> >>> A Morphic clean/revamp lead by Alain and Stef. >>> >>> >>> On Wed, Jun 11, 2014 at 2:26 PM, stepharo <stepharo(a)free.fr> wrote: >>> >>>> looks so exciting... >>>> >>>> From: Alain Plantec <alain.plantec(a)univ-brest.fr> >>>> Subject: Bloc news >>>> Date: 11 Jun 2014 14:10:29 GMT+2 >>>> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>> Cc: Alain Plantec <alain.plantec(a)univ-brest.fr> >>>> >>>> Name: Bloc-Core-AlainPlantec.15 >>>> Author: AlainPlantec >>>> Time: 11 June 2014, 2:07:16.813171 pm >>>> UUID: d58ae82e-b5dd-41d9-bc31-a48c3e9e5cf1 >>>> Ancestors: Bloc-Core-AlainPlantec.14 >>>> >>>> - BlMorphs manage their submorphs with local coordinate. >>>> - Drawing and drag&drop has been adapted to local coordinate >>>> - Consequence: TransformationMorph should not be useful anymore because >>>> each morph has its own transform (not only TransformationMorph). Each morph >>>> uses its own transform to declare changed portions of its bounds and to >>>> draw its submorphs. >>>> - The world is no more a special morph: >>>> - the hand is owned by the space >>>> - the canvas and the display/redisplay of morphs are space >>>> responsibilities. >>>> This open the door to several worlds per space. >>>> >>>> Now the current global redrawing mechanism efficiency is not obvious. >>>> Next actions: >>>> - try to localize as much as possible the redrawing of morphs, >>>> - dig several Worlds for a space >>>> - start to comment and write a separate documentation with the help of >>>> Stephane :) >>>> >>>> >>>> >>> >>> >> > > >

June 12, 2014

Re: [Pharo-dev] news from block :)

by Nicolai Hess

2014-06-11 23:13 GMT+02:00 Alain Plantec <alain.plantec(a)yahoo.com>: > Hi Doru, all > > Bloc (and not Block). > It is stored in Smaltalkhub. > MCHttpRepository > location: 'http://smalltalkhub.com/mc/AlainPlantec/Bloc/main' > user: '' > password: '' > > You can use the world menu to create and switch to a Bloc world > and come back to a Morphic one. > The idea is to clean and deeply redesign everything. > So far, only the basic Morph hierarchy is remade. > > We do not have a lot of time to work on it so we progress slowly. > > Cheers > Alain > > > I like the idea. The current Morph classes are too big. It is difficult to understand them and to find out how to work with them "the right way" (event handling for example or layouting). Can you describe something more about the design. Or is the design a work in progress. Please, I hope the "properties"-Dictionary is only a left over for Morphic compatibility. I never understood why these are used instead of proper selector and objects representing actual properties. nicolai > > On 11 juin 2014, at 22:11, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > I would be interested in trying to play with Block. Is it available? > > > > Cheers, > > Doru > > > > > > On Wed, Jun 11, 2014 at 9:55 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > > On 11 Jun 2014, at 16:39, kilon alios <kilon.alios(a)gmail.com> wrote: > > > >> excellent news. I really believe in Morphic and I really like its > general design. If you we can clean the mud I am sure we will discover > quite a diamond underneath. Thanks. > > > > which general design? the pattern in which is based? thatâs not enough > to keep it :) > > Sorry but there is no easy/efficient way to clean it. > > The only way to clean Morphic is to reimplement it. > > Clean it is just too much workâ¦ and too many design decisions where made > that time and patches made them obsolete or not correct. > > Not to talk about the mix of concepts (bah, the no existence of > separation between them). > > > > Block is not a clean. Is a revamp. > > > > No offence intended to Morphic: no matter how good was at the beginning, > *every* system evolves up to a point the effort required to maintain it is > superior to the effort required to reimplement it (with all the experience > as a superior step). > > (yeah, yeahâ¦ a lot of people will disagree. But time has proven me > rightâ¦ and will continue doing it :P) > > > > Esteban > > > >> > >> > >> On Wed, Jun 11, 2014 at 10:25 PM, FranÃ§ois Stephany < > tulipe.moutarde(a)gmail.com> wrote: > >> \o/ > >> > >> > >> On Wed, Jun 11, 2014 at 4:23 PM, Camille Teruel < > camille.teruel(a)gmail.com> wrote: > >> > >> On 11 juin 2014, at 15:31, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> > wrote: > >> > >>> What is bloc ? > >>> I've searched in the pharo-dev list but couldn't find it :/ > >> > >> A Morphic clean/revamp lead by Alain and Stef. > >> > >>> > >>> On Wed, Jun 11, 2014 at 2:26 PM, stepharo <stepharo(a)free.fr> wrote: > >>> looks so exciting... > >>> > >>> From: Alain Plantec <alain.plantec(a)univ-brest.fr> > >>> Subject: Bloc news > >>> Date: 11 Jun 2014 14:10:29 GMT+2 > >>> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >>> Cc: Alain Plantec <alain.plantec(a)univ-brest.fr> > >>> > >>> Name: Bloc-Core-AlainPlantec.15 > >>> Author: AlainPlantec > >>> Time: 11 June 2014, 2:07:16.813171 pm > >>> UUID: d58ae82e-b5dd-41d9-bc31-a48c3e9e5cf1 > >>> Ancestors: Bloc-Core-AlainPlantec.14 > >>> > >>> - BlMorphs manage their submorphs with local coordinate. > >>> - Drawing and drag&drop has been adapted to local coordinate > >>> - Consequence: TransformationMorph should not be useful anymore > because each morph has its own transform (not only TransformationMorph). > Each morph uses its own transform to declare changed portions of its bounds > and to draw its submorphs. > >>> - The world is no more a special morph: > >>> - the hand is owned by the space > >>> - the canvas and the display/redisplay of morphs are space > responsibilities. > >>> This open the door to several worlds per space. > >>> > >>> Now the current global redrawing mechanism efficiency is not obvious. > >>> Next actions: > >>> - try to localize as much as possible the redrawing of morphs, > >>> - dig several Worlds for a space > >>> - start to comment and write a separate documentation with the help of > Stephane :) > >>> > >>> > >>> > >> > >> > >> > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > >

June 12, 2014