June 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Refactoring File Package

by stepharo

>> I guess you have scripts outside the image to shrink the image and >> then bootstrap it. However these are not necessarily visible to >> everyone and I am wondering once the bootstrap goal is achieved you >> will handle the entropy of ongoing development by many others >> accidentally introducing dependencies that breaks the bootstrap? >> >> Also what I have seen is classes being moved out of their current >> packaging (sorry I forget the details, but I think it was moved out of >> System) into a new top-level package, which I think loses something in >> structure and might pollute the top-level packages. >> >> So considering the recent discussion of package tags, I wonder if >> somehow we could have a "Bootstrap" tag and realtime critics that >> complain if Bootstrap-tagged-class references any >> non-Bootstrap-tagged-class. There might even be several levels of >> Bootstrap tags. This would improve ongoing visibility of the >> bootstrap structure and help the rest of us to not shoot it in the >> foot. > One of the things I really like about ENVY (as found in VA Smalltalk) is > that packages are formally modelled and are distinct from method categories. > (Another is that a method can have multiple categories.) And by formally > modelling packages, one can easily include proper dependency relationships > and more easily detect references to behaviours outside a packages > prerequisites chain. we have the same with the dependency browser. Christophe is adding some logic to get the messages sent but not implemented in a package and its dependents. We are also adding dependencies to the packaege themselves. > > I realize that is a huge departure from current Squeak and Pharo practice. > But, I hope it's one that will get consideration. (Given all the other first > class modelling you've been adding to Pharo, I think this would be > consistent with the current philosophy!) So we are slowly adding metadata to package manifest. Now packages are not added the Smalltalk namespace and I do not know if this would be good to have. > >> I wonder also if tags might also be extended to method protocols, so >> you can have a method with the "accessors" tag and also the >> "bootstrap" tag, so that even a Bootstrap-tagged-class can be further >> minimised by the methods it needs during bootstrap. Otherwise I guess >> to minimise the methods in a Bootstrap-tagged-class, later extension >> by another package could not add methods to the "accessors" protocol. >> >> P.S. I know I do a lot of wondering, and of course divergent thought >> is easier than concrete answers. >> cheers -ben >> >> >>> Then the bootstrap will include essential packages at the beginning and >>> non-essential will be just loaded on top. >>> >>> The rationale is: the smaller the kernel, the fastest the bootstrap, and >>> with it the feedback loop we have. >>> >>> That's why I was working on the File abstractions, and splitting some >>> other >>> kernel package. >>> >>> El vie., 5 de jun. de 2015 a la(s) 7:35 p. m., stepharo < >> stepharo@ >> > >>> escribiÃ³: >>>> Yes sven but with guille we are working on a really small kernel. So we >>>> can duplicate just the classes we need but I would prefer not >>>> but we can do it. The size is important for us because it takes time to >>>> bootstrap. >>>> >>>> Stef >>>> >>>> Le 5/6/15 19:06, Sven Van Caekenberghe a Ã©crit : >>>>>> On 05 Jun 2015, at 18:43, Guillermo Polito < >> guillermopolito@ >> > >>>>>> wrote: >>>>>> >>>>>> The only encoder that makes a bit of noise to me is the ZnByteEncoder >>>>>> that contains a lot of mapping tables for mostly unused encodings >>>>> 67 encoding specifications, each a 128 array. The method constant is >>>>> shared when used. >>>>> In the beginning there were only a couple, one day I added many more, >>>>> some people need them. >>>>> For me, the cost is reasonable. >>>>> >>>>>> (plus methods with metadata to recreate them)... >>>>> That is just two method (which is pretty cool, I love spec based >>>>> programming). >>>>> >>>>>> El vie., 5 de jun. de 2015 a la(s) 6:30 p. m., Sven Van Caekenberghe >>>>>> < >> sven@ >> > escribiÃ³: >>>>>>> On 05 Jun 2015, at 18:20, stepharo < >> stepharo@ >> > wrote: >>>>>>> Sven >>>>>>> >>>>>>> we were talking about splitting your package into two parts :) >>>>>>> Would you be ok to get the basic encoders in a separate package? >>>>>> Zinc-Character-Encoding is already a separate package, it depends on >>>>>> nothing. >>>>>> Zinc-Resource-Meta is next up (containing URL and Mime-Type). >>>>>> Both are completely independent of any HTTP stuff. >>>>>> All this is by design. >>>>>> >>>>>> You probably mean that you want a separate config ? Right now they >>>> are >>>>>> just a groups. >>>>>> >>>>>>> We were also thinking that NullEncoder could be called AsciiEncoder? >>>>>> Maybe, maybe not, let me think about that a bit. >>>>>> >>>>>>> Stef >>>>>>> >>>>>>>>> On 05 Jun 2015, at 18:09, Damien Cassou < >> damien.cassou@ >> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Guillermo Polito < >> guillermopolito@ >> > writes: >>>>>>>>>> Well, I made a cleaner implementation at the side with >>>>>>>>>> >>>>>>>>>> - a simple File object that is a sequential File as we all know >>>>>>>>>> - a binary File stream on top of it that is composable with Zn >>>>>>>>>> encoders and >>>>>>>>>> other decorators >>>>>>>>>> - a new interface to access Stdio streams >>>>>>>>> that's really good news Guillermo. >>>>>>>> Yes it is (need time to look at this in detail) >>>>>>>> >>>>>>>>> Is it ok to make File reading depend >>>>>>>>> on Zinc? This sounds strange. Wouldn't that make bootstrapping >>>>>>>>> harder? >>>>>>>> It does not depend on the HTTP part, but on the Encoding part below >>>>>>>> it, so that should be OK. >>>>>>>> >>>>>>>>> -- >>>>>>>>> Damien Cassou >>>>>>>>> http://damiencassou.seasidehosting.st >>>>>>>>> >>>>>>>>> "Success is the ability to go from one failure to another without >>>>>>>>> losing enthusiasm." --Winston Churchill >>>>>>>>> >>>>> >>>> > > > > > -- > View this message in context: http://forum.world.st/Refactoring-File-Package-tp4830625p4830987.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

June 26, 2015

Re: [Pharo-dev] RBEnvironments allClasses/Traits/Meta ...

by Nicolai Hess

2015-06-23 9:44 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > I would say, that besides #checkClass: and #checkMethod: rules should also > have #checkMetaClass: this will allow rule developers to be more flexible, > and will add a bit more certainty. > > Because sometimes you need to check both, then you implement a method and > call it from #checkClass: and #checkMetaClass:. Sometimes you only need to > check one of them. And you will always know that metaclass will not sendup > in your method. > And maybe we should exclude traits and provide a checkTrait method, because now there are some lint rules failing because there is code like checkClasse: aClass |meta| meta := aClass class. .... check on meta and if this method is called for a trait like TBehavior, TBehavior class -> Trait meta is not the classTrait of TBehavior but the Metaclass of Trait. > > Uko > > On 23 Jun 2015, at 08:40, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > What if rules that need metaclasses ask for them explicitly to the class? > > environment allClasses do: [ :theInstanceSide | > self doSomethingWith: theInstanceSide. > self doSomethingWith: theInstanceSide classSide. ] > > Just putting another possibility on the table... > > El lun., 22 de jun. de 2015 a la(s) 10:40 p. m., Nicolai Hess < > nicolaihess(a)web.de> escribiÃ³: > >> >> 2014-12-18 22:32 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: >> >>> Iâm ready to help with this issue, but as far as I can tell, itâs not >>> hard to implement the mentors. Here we should decide on the meaning of the >>> phrases. What are "all behaviorsâ and so on. The reason of the refactoring >>> that Iâve done was that there were two methods with similar names that were >>> doing different things. >>> >>> Uko >>> >>> On 18 Dec 2014, at 21:19, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> >>> Hi, >>> >>> some time ago Yuriy cleaned up the RBBrowserEnvironment methods for >>> allClassesAndTraits(Do), classesDo, .... >>> >>> The fix was good and necessary (I think). But they had an impact >>> on some SmallLint-rules (they arent applied on the class side) and the >>> behavior >>> for the different Environments changed (compared with Pharo3 >>> (-> 14621 <https://pharo.fogbugz.com/default.asp?14621> Some >>> RBBrowserEnvironments don't work well with Metaclasses)) >>> >>> As some SmallLint-rules need to iterate over the metaclasses as well and >>> I don't want to revert Yuriys change, I 'll add another method that >>> collect classes and metaclasses. >>> >>> So, I need some help, how to name this methods: >>> >>> all classes (Object, Integer, ....) -> allClasses, ok >>> all classes and metaclasses (Object, Object class, Integer class ) -> ? >>> allBehaviors? >>> all classes and traits -> allClassesAndTraits, ok >>> all classes and meta classes and traits and class traits -> ? no idea! >>> all metaclasses and class traits -> allMeta(ClassesAndTraits) ? I don't >>> know if we need this >>> >>> One problem with "allBehaviors" is, SystemNavigation uses allBehaviors >>> to iterate >>> over classes, metaclasses, traits and class traits, >>> allthough a Trait is not a Behavior. (TClass isBehavior -> false) >>> >>> feedback is welcome >>> >>> >>> nicolai >>> >>> >>> >>> >> >> >> Pharo 3.0: >> SystemNavigation default allClasses size. 4024 >> Smalltalk allClasses size. 4024. >> RBBrowserEnvironment default allClasses size. 4024 >> RBBrowserEnvironment default classes size. 8048 >> >> Pharo 4.0: >> >> SystemNavigation default allClasses size. 5012 >> Smalltalk allClasses size. 5012 >> RBBrowserEnvironment default allClasses size. 5012 >> RBBrowserEnvironment default classes size. 5012 >> >> -> I "define" the Pharo 4.0 behavior as the correct one. >> RBEnvironment>>#classes should not contain meta classes. >> >> Some other RBEnvironments and/or RBRules rely on the "classes = classes >> and metaclasses" (-> see issue >> 14621 <https://pharo.fogbugz.com/default.asp?14621> >> Some RBBrowserEnvironments don't work well with Metaclasses >> 14230 <https://pharo.fogbugz.com/default.asp?14230> >> Some rules aren't applied on the classside anymore >> 15302 <https://pharo.fogbugz.com/default.asp?15302> >> a RBEnvironment from #referencesTo: does not list meta classes >> >> I will change them, and if appropiate, add a new >> classesAndMetaclasses resp. classesAndMetaclassesDo: >> >> I don't know about classesAndMetaclassesTraits. And I skip "behaviors" >> for now. >> #allBehaviors is suspicious to me, I still don't >> know what they are: >> >> Smalltalk globals allBehaviors includes:TBehavior. -> true (1) >> TBehavior isBehavior. -> false (!) >> >> >> >> >

June 26, 2015

Re: [Pharo-dev] GitFileTree dependencies

by stepharo

Yes StringHolder does not exist anymore. So may be you can load an old version and change GitFileTree but GitFileTree should not rely on this old and bad class. It took us 3 years to remove it. Stef Le 19/6/15 11:32, Yuriy Tymchuk a Ã©crit : > Hi, > > when loading GitFileTree in Pharo 5, I get: > > This package depends on the following classes: > StringHolder > You must resolve these dependencies before you will be able to load these definitions: > CrLfFileEditor > â¦ > > Does anybody know if this was caused by any recent changes? > > Uko > > > P.S. we should add some mechanics to report dependency issues at CI server. Because when one loads Moose (for example) from scratch, he will encounter dependency issues, but as most of people who work on Moose download the ready-made image from CI, itâs not a visible problem. > >

June 26, 2015

Re: [Pharo-dev] RBEnvironments allClasses/Traits/Meta ...

by Nicolai Hess

2015-06-23 8:40 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > What if rules that need metaclasses ask for them explicitly to the class? > > environment allClasses do: [ :theInstanceSide | > self doSomethingWith: theInstanceSide. > self doSomethingWith: theInstanceSide classSide. ] > > Just putting another possibility on the table... > Yes, something like that. > > El lun., 22 de jun. de 2015 a la(s) 10:40 p. m., Nicolai Hess < > nicolaihess(a)web.de> escribiÃ³: > >> >> 2014-12-18 22:32 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: >> >>> Iâm ready to help with this issue, but as far as I can tell, itâs not >>> hard to implement the mentors. Here we should decide on the meaning of the >>> phrases. What are "all behaviorsâ and so on. The reason of the refactoring >>> that Iâve done was that there were two methods with similar names that were >>> doing different things. >>> >>> Uko >>> >>> On 18 Dec 2014, at 21:19, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> >>> Hi, >>> >>> some time ago Yuriy cleaned up the RBBrowserEnvironment methods for >>> allClassesAndTraits(Do), classesDo, .... >>> >>> The fix was good and necessary (I think). But they had an impact >>> on some SmallLint-rules (they arent applied on the class side) and the >>> behavior >>> for the different Environments changed (compared with Pharo3 >>> (-> 14621 <https://pharo.fogbugz.com/default.asp?14621> Some >>> RBBrowserEnvironments don't work well with Metaclasses)) >>> >>> As some SmallLint-rules need to iterate over the metaclasses as well and >>> I don't want to revert Yuriys change, I 'll add another method that >>> collect classes and metaclasses. >>> >>> So, I need some help, how to name this methods: >>> >>> all classes (Object, Integer, ....) -> allClasses, ok >>> all classes and metaclasses (Object, Object class, Integer class ) -> ? >>> allBehaviors? >>> all classes and traits -> allClassesAndTraits, ok >>> all classes and meta classes and traits and class traits -> ? no idea! >>> all metaclasses and class traits -> allMeta(ClassesAndTraits) ? I don't >>> know if we need this >>> >>> One problem with "allBehaviors" is, SystemNavigation uses allBehaviors >>> to iterate >>> over classes, metaclasses, traits and class traits, >>> allthough a Trait is not a Behavior. (TClass isBehavior -> false) >>> >>> feedback is welcome >>> >>> >>> nicolai >>> >>> >>> >>> >> >> >> Pharo 3.0: >> SystemNavigation default allClasses size. 4024 >> Smalltalk allClasses size. 4024. >> RBBrowserEnvironment default allClasses size. 4024 >> RBBrowserEnvironment default classes size. 8048 >> >> Pharo 4.0: >> >> SystemNavigation default allClasses size. 5012 >> Smalltalk allClasses size. 5012 >> RBBrowserEnvironment default allClasses size. 5012 >> RBBrowserEnvironment default classes size. 5012 >> >> -> I "define" the Pharo 4.0 behavior as the correct one. >> RBEnvironment>>#classes should not contain meta classes. >> >> Some other RBEnvironments and/or RBRules rely on the "classes = classes >> and metaclasses" (-> see issue >> 14621 <https://pharo.fogbugz.com/default.asp?14621> >> Some RBBrowserEnvironments don't work well with Metaclasses >> 14230 <https://pharo.fogbugz.com/default.asp?14230> >> Some rules aren't applied on the classside anymore >> 15302 <https://pharo.fogbugz.com/default.asp?15302> >> a RBEnvironment from #referencesTo: does not list meta classes >> >> I will change them, and if appropiate, add a new >> classesAndMetaclasses resp. classesAndMetaclassesDo: >> >> I don't know about classesAndMetaclassesTraits. And I skip "behaviors" >> for now. >> #allBehaviors is suspicious to me, I still don't >> know what they are: >> >> Smalltalk globals allBehaviors includes:TBehavior. -> true (1) >> TBehavior isBehavior. -> false (!) >> >> >> >>

June 26, 2015

Re: [Pharo-dev] [ANN] Edge bundles

by Volkert

That is really cool. Volkert Am 26.06.2015 um 20:51 schrieb Alexandre Bergel: > Dear All, > > Here is a preview of what we will demonstrate at ESUG. > > > Best is to see it live try this: > > -=-=-=-=-=-=-=-=-=-=-=-= > b := RTBundleBuilder new. > b from: {TRObject. TRTest} using: #subclasses. > b edges shape line color: Color black. > b bezier color: (Color blue alpha: 0.5). > b useBezierlineWith: #dependentClasses. > b build. > lb := RTLegendBuilder new. > lb view: b view; right. > lb addText: 'RTBundleBuilder: TRObject and TRTest subclasses'. > lb addColor: Color black text: 'Hierarchy'. > lb addColor: (Color r: 0 g: 120 b: 0 range: 255) text: 'Dependent > classes'. > lb addColor: Color red text: 'Senders'. > lb build. > b view > -=-=-=-=-=-=-=-=-=-=-=-= > > A very short video is available on: https://vimeo.com/131891902 > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > >

June 26, 2015

Re: [Pharo-dev] help removing NewList

by stepharo

Thanks I forgot to look at the Model references! Le 26/6/15 20:31, Nicolai Hess a Ã©crit : > > EyeInspector (ContextInspector) uses newlist > > Am 26.06.2015 7:22 nachm. schrieb "stepharo" <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Hi guys > > I'm trying to remove NewList, MorphicAdapter. So I edited > initializeBindings and did > SpecInterpreter hardReset (or something like that). > > Now I cannot open the Debugger anymore... endless loop. > I'm looking for the reference to NewList via Spec but I cannot > find them. I tried several > times. I looked at the initializePresenters... > Do you have any ideas? Suggestions? > > Stef > >

June 26, 2015

Re: [Pharo-dev] help removing NewList

by stepharo

Thanks Andrei for the suggestion. Le 26/6/15 20:00, Andrei Chis a Ã©crit : > > Hi Stef, > > You can try to remove NewList from a moose 6 image. The gt debugger > doesn't use the NewList so you should maybe be able to debug the debugger. > > Cheers, > Andrei > > On Jun 26, 2015 7:22 PM, "stepharo" <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi guys > > I'm trying to remove NewList, MorphicAdapter. So I edited > initializeBindings and did > SpecInterpreter hardReset (or something like that). > > Now I cannot open the Debugger anymore... endless loop. > I'm looking for the reference to NewList via Spec but I cannot > find them. I tried several > times. I looked at the initializePresenters... > Do you have any ideas? Suggestions? > > Stef > >

June 26, 2015

Re: [Pharo-dev] help removing NewList

by stepharo

Thanks I was looking in the wrong place! Le 26/6/15 20:31, Nicolai Hess a Ã©crit : > > EyeInspector (ContextInspector) uses newlist > > Am 26.06.2015 7:22 nachm. schrieb "stepharo" <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Hi guys > > I'm trying to remove NewList, MorphicAdapter. So I edited > initializeBindings and did > SpecInterpreter hardReset (or something like that). > > Now I cannot open the Debugger anymore... endless loop. > I'm looking for the reference to NewList via Spec but I cannot > find them. I tried several > times. I looked at the initializePresenters... > Do you have any ideas? Suggestions? > > Stef > >

June 26, 2015

[ANN] Edge bundles

by Alexandre Bergel

Dear All, Here is a preview of what we will demonstrate at ESUG. Best is to see it live try this: -=-=-=-=-=-=-=-=-=-=-=-= b := RTBundleBuilder new. b from: {TRObject. TRTest} using: #subclasses. b edges shape line color: Color black. b bezier color: (Color blue alpha: 0.5). b useBezierlineWith: #dependentClasses. b build. lb := RTLegendBuilder new. lb view: b view; right. lb addText: 'RTBundleBuilder: TRObject and TRTest subclasses'. lb addColor: Color black text: 'Hierarchy'. lb addColor: (Color r: 0 g: 120 b: 0 range: 255) text: 'Dependent classes'. lb addColor: Color red text: 'Senders'. lb build. b view -=-=-=-=-=-=-=-=-=-=-=-= A very short video is available on: https://vimeo.com/131891902 <https://vimeo.com/131891902> Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 26, 2015

Re: [Pharo-dev] help removing NewList

by Nicolai Hess

EyeInspector (ContextInspector) uses newlist Am 26.06.2015 7:22 nachm. schrieb "stepharo" <stepharo(a)free.fr>: > Hi guys > > I'm trying to remove NewList, MorphicAdapter. So I edited > initializeBindings and did > SpecInterpreter hardReset (or something like that). > > Now I cannot open the Debugger anymore... endless loop. > I'm looking for the reference to NewList via Spec but I cannot find them. > I tried several > times. I looked at the initializePresenters... > Do you have any ideas? Suggestions? > > Stef > > >

June 26, 2015