- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GT / Debugger Inspector Duplication

by Marcus Denker

> On 17 Feb 2015, at 01:59, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Right now, for the Debugger one must describe an object-specific inspector > using EyeInspector, and then again with GT for the Playground. Can these > tools be unified and build themselvs using the same declarative code? Yes, we right now have 2 sets of inspectors in the system: GT and Eye. The debugger is the eye-based debugger. There is a debugger in developlement (and already used by Moose) that is based on GT. Marcus

Feb. 17, 2015

GT / Debugger Inspector Duplication

by Sean P. DeNigris

Right now, for the Debugger one must describe an object-specific inspector using EyeInspector, and then again with GT for the Playground. Can these tools be unified and build themselvs using the same declarative code? ----- Cheers, Sean -- View this message in context: http://forum.world.st/GT-Debugger-Inspector-Duplication-tp4806064.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 17, 2015

Re: [Pharo-dev] Proposal for LiteralArray class

by Sven Van Caekenberghe

> On 16 Feb 2015, at 23:32, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2015-02-05 16:02 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 05 Feb 2015, at 15:44, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-02-02 3:03 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > > On Sun, Feb 1, 2015 at 3:39 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > > > 2015-02-01 10:52 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > > > Looking into Image locking problems [1] caused by a recursive array such as this... > > > > literalArray := #( 1 2 3 ). > > literalArray at: 3 put: literalArray. > > > > I find that "literalArray printString" locks the image due to Array>>printOn: use of the recursive #shouldBePrintedAsLiteral method. Now its implementation is identical to #isLiteral and indeed "literalArray isLiteral" also locks the Image. So comparing implementors of #isLiteral... > > > > > > > > Squeak uses a Set to store all visited elements for shouldBePrintedAsLiteral and this protects against the recursive loop. > > > > shouldBePrintedAsLiteralVisiting: aSet > > self class == Array ifFalse: > > [^false]. > > (aSet includes: self) ifTrue: > > [^false]. > > aSet add: self. > > ^self allSatisfy: [:each | each shouldBePrintedAsLiteralVisiting: aSet] > > > > > > isn't there a common pattern to handle this kind of potential endless recursion? > > > > At Cadence we fixed it thus: > > > > Object>>shouldBePrintedAsLiteral > > > > ^self isLiteral > > > > Array>>shouldBePrintedAsLiteral > > > > ^self class == Array > > and: [self shouldBePrintedAsLiteralVisiting: (IdentitySet new: 8)] > > > > Object>>shouldBePrintedAsLiteralVisiting: aSet > > > > ^self isLiteral > > > > Array>>shouldBePrintedAsLiteralVisiting: aSet > > self class == Array ifFalse: > > [^false]. > > (aSet includes: self) ifTrue: > > [^false]. > > aSet add: self. > > ^self allSatisfy: [:each | each shouldBePrintedAsLiteralVisiting: aSet] > > > > > > Is there something more "generic". Something we can use for any object tracing. > > Isn't there something the GC uses? The GC obviously does not fall into this loop. > > (It flags visited objects, but there is nothing exposed that can be used > > at the image level?) > > How do ImageSegment or Fuel work with recursive structures? > > In Moose there is DeepTraverser which does something similar it seems. > > FUEL & STON do this too. > > How is it done in Fuel and STON ? Do they both use DeepTraverser, or > is there another implementation in Fuel and another one in STON? They both have their own implementation. The actual traversal is not that difficult, doing it efficiently is a bit harder. Getting all the edge cases of the total algorithm (the serialisation) right is a more work. I am not familiar with DeepTraverser, I just know it exists. > > Nicolai > > > > > > > > Object>>isLiteral ^false > > Boolean>>isLiteral ^true > > Character>>isLiteral ^true > > Integer>>isLiteral ^true > > String>>isLiteral ^true > > UndefinedObject>>isLiteral ^true > > > > ByteArray>>isLiteral ^self class == ByteArray > > Float>>isLiteral ^self isFinite "^(self - self) = 0.0" > > ScaledDecimal>>isLiteral ^denominator = 1 or: [(10 raisedTo: scale)\\denominator = 0] > > > > Array>>isLiteral ^self class == Array and: [self allSatisfy: [:each | each isLiteral]] > > > > ...I find most are very basic (might even say deterministic), with the recursion of Array>>isLiteral seeming an annomaly. Also, the big IF condition in Array>>printOn: smells like a design decision being made at runtime (Valloud AMCOS p12). > > > > Array>>printOn: aStream > > self shouldBePrintedAsLiteral ifTrue: [self printAsLiteralFormOn: aStream. ^ self]. > > self isSelfEvaluating ifTrue: [self printAsSelfEvaluatingFormOn: aStream. ^ self]. > > super printOn: aStream > > > > Flipping between two printString formats seems like selecting between two class types. Indeed, if we had a LiteralArray class, there would be no need for its printOn: to recursively search to determine its form, thus allowing #printStringLimitedTo: to do its thing to protect against infinite recursion. > > > > Also, instead of a recursive Array>>isLiteral we'd have something like > > LiteralArray>>isLiteral ^true > > Array>>isLiteral ^false > > which seems to align much better with the pattern of the other #isLiteral implementors. > > > > I notice there is both RBArrayNode and RBLiteralArrayNode. > > > > So what are the wider concerns that might apply? > > (In particular, I'm not sure how the #isSelfEvaluating (which is also recursive) fits into the big picture) > > > > cheers -ben > > > > [1] https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg25156.html > > > > > > > > > > -- > > best, > > Eliot

Feb. 16, 2015

Re: [Pharo-dev] Proposal for LiteralArray class

by Nicolai Hess

2015-02-05 16:02 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 05 Feb 2015, at 15:44, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-02-02 3:03 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > > On Sun, Feb 1, 2015 at 3:39 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > > > 2015-02-01 10:52 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > > > Looking into Image locking problems [1] caused by a recursive array such > as this... > > > > literalArray := #( 1 2 3 ). > > literalArray at: 3 put: literalArray. > > > > I find that "literalArray printString" locks the image due to > Array>>printOn: use of the recursive #shouldBePrintedAsLiteral method. Now > its implementation is identical to #isLiteral and indeed "literalArray > isLiteral" also locks the Image. So comparing implementors of #isLiteral... > > > > > > > > Squeak uses a Set to store all visited elements for > shouldBePrintedAsLiteral and this protects against the recursive loop. > > > > shouldBePrintedAsLiteralVisiting: aSet > > self class == Array ifFalse: > > [^false]. > > (aSet includes: self) ifTrue: > > [^false]. > > aSet add: self. > > ^self allSatisfy: [:each | each shouldBePrintedAsLiteralVisiting: > aSet] > > > > > > isn't there a common pattern to handle this kind of potential endless > recursion? > > > > At Cadence we fixed it thus: > > > > Object>>shouldBePrintedAsLiteral > > > > ^self isLiteral > > > > Array>>shouldBePrintedAsLiteral > > > > ^self class == Array > > and: [self shouldBePrintedAsLiteralVisiting: (IdentitySet new: > 8)] > > > > Object>>shouldBePrintedAsLiteralVisiting: aSet > > > > ^self isLiteral > > > > Array>>shouldBePrintedAsLiteralVisiting: aSet > > self class == Array ifFalse: > > [^false]. > > (aSet includes: self) ifTrue: > > [^false]. > > aSet add: self. > > ^self allSatisfy: [:each | each shouldBePrintedAsLiteralVisiting: > aSet] > > > > > > Is there something more "generic". Something we can use for any object > tracing. > > Isn't there something the GC uses? The GC obviously does not fall into > this loop. > > (It flags visited objects, but there is nothing exposed that can be used > > at the image level?) > > How do ImageSegment or Fuel work with recursive structures? > > In Moose there is DeepTraverser which does something similar it seems. > > FUEL & STON do this too. > How is it done in Fuel and STON ? Do they both use DeepTraverser, or is there another implementation in Fuel and another one in STON? > > > Nicolai > > > > > > > > Object>>isLiteral ^false > > Boolean>>isLiteral ^true > > Character>>isLiteral ^true > > Integer>>isLiteral ^true > > String>>isLiteral ^true > > UndefinedObject>>isLiteral ^true > > > > ByteArray>>isLiteral ^self class == ByteArray > > Float>>isLiteral ^self isFinite "^(self - self) = 0.0" > > ScaledDecimal>>isLiteral ^denominator = 1 or: [(10 raisedTo: > scale)\\denominator = 0] > > > > Array>>isLiteral ^self class == Array and: [self > allSatisfy: [:each | each isLiteral]] > > > > ...I find most are very basic (might even say deterministic), with the > recursion of Array>>isLiteral seeming an annomaly. Also, the big IF > condition in Array>>printOn: smells like a design decision being made at > runtime (Valloud AMCOS p12). > > > > Array>>printOn: aStream > > self shouldBePrintedAsLiteral ifTrue: [self printAsLiteralFormOn: > aStream. ^ self]. > > self isSelfEvaluating ifTrue: [self printAsSelfEvaluatingFormOn: > aStream. ^ self]. > > super printOn: aStream > > > > Flipping between two printString formats seems like selecting between > two class types. Indeed, if we had a LiteralArray class, there would be no > need for its printOn: to recursively search to determine its form, thus > allowing #printStringLimitedTo: to do its thing to protect against infinite > recursion. > > > > Also, instead of a recursive Array>>isLiteral we'd have something like > > LiteralArray>>isLiteral ^true > > Array>>isLiteral ^false > > which seems to align much better with the pattern of the other > #isLiteral implementors. > > > > I notice there is both RBArrayNode and RBLiteralArrayNode. > > > > So what are the wider concerns that might apply? > > (In particular, I'm not sure how the #isSelfEvaluating (which is also > recursive) fits into the big picture) > > > > cheers -ben > > > > [1] https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg25156.html > > > > > > > > > > -- > > best, > > Eliot > >

Feb. 16, 2015

Re: [Pharo-dev] What is a Behavior, are Traits behavior too?

by Nicolai Hess

Thank you for your feedback Camille, 2015-02-10 10:24 GMT+01:00 Camille <camille.teruel(a)gmail.com>: > > On 09 Feb 2015, at 18:24, Nicolai Hess <nicolaihess(a)web.de> wrote: > > I thought, Behaviors define the "behavior" of objects, therefore: > > Integer is a behavior, because it defines the behavior of "integer objects" > Integer class is a behavior because it defines the behavior of the object > "Integer". > > 5 isBehavior -> false. > Integer isBehavior -> true. > Integer class isBehavior -> true. > > What about Traits? > > Traits are "behavioral(?)", but they don't define the behavior alone, only > the composition of > Traits in an actual class defines the behavior of an Object. > > TClass isBehavior -> false. > > > So far so good. > > > In fact the first time I saw this I was a bit surprised, I was expecting > it to return true. > After all Trait class inherits TraitBehavior that uses the TBehavior > trait. > Sure a trait alone doesnât define the whole behavior of an object but at > least part of it. > In fact itâs because there is many senders of isBehavior which expect it > to return true only if the receiver is instanciable. > But still itâs a bit confusing. > > Smalltalk globals allBehaviors includes:TClass -> true ! > > No suprise, because #allBehaviors explicitly collect all classes and > traits. > But the question is, what do we want to call a "Behaviorâ? > > > I would prefer isBehavior to return true for traits and rename the current > isBehavior to isInstanciable for exemple. > But this is quite a refactoring and itâs likely to break many things that > are not in the image by default. > I would prefer any solution, as long as it is consistent. Other opinions? > > Likewise in SystemDictionary and SystemNavigation: > > All Classes and MetaClasses (-> Behavior allSubclasses) > > > -> allInstanciable or allClassesAndMetaclasses > > All Classes and Traits > > > -> allInstanceSideBehaviors (and an equivalent allClassSideBehavior for > metaclasses and classtraits) > > All Classes and Traits and MetaClasses and ClassTraits > > > -> allBehaviors > > All Classes and MetaClasses and some Traits? > > > not this one > > (this of course, is related to > http://forum.world.st/RBEnvironments-allClasses-Traits-Meta-tp4796370.html > ). > > In squeak Traits are behavior too. > > > Yes, itâs because in squeak traits are implemented differently: the class > Trait inherits from Behavior so traits are instanciable. > > > > nicolai > > > >

Feb. 16, 2015

Re: [Pharo-dev] Number>>#percent

by Sven Van Caekenberghe

I like it, it is just one method. > On 16 Feb 2015, at 22:41, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Guillermo Polito wrote >> Sean, but if you need something like that, why wouldn't you load >> aconcagua? >> >> I'm just in the crusade of putting less in the kernel by default ^^. > > Good question! The little project I was working on when I implemented that > method /was/ using Aconcagua! But: > 1. This is a simple, common conversion which > a. could make the kernel itself a bit more intention revealing > Job>>#progress > ^ min >= max ifTrue: [ 1 ] ifFalse: [ (currentValue - min) / (max - min) ] > could become: > ^ min >= max ifTrue: [ 100 percent ] ifFalse: [ (currentValue - min) / (max > - min) ] > b. would've made my life a bit easier on several occasions, but feels much > too lightweight to load a library for. There doesn't seem to be an entire > domain behind it. One method gets you the whole thing. > 2. AFAICT, Aconcagua doesn't really solve this problem. It defines families > of units and conversions between them, but here there's just one concept as > mentioned in 1.b. above > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Number-percent-tp4805988p4806047.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Feb. 16, 2015

Re: [Pharo-dev] do we need to debug testmethods from within Nautilus ?

by Nicolai Hess

Ok, thank you marcus Nicolai 2015-02-16 16:52 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > On 16 Feb 2015, at 16:45, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 15 Feb 2015, at 18:34, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Issue: > 14060 <https://pharo.fogbugz.com/default.asp?14060> MNU: receiver of > "stepToCallee" is nil > > I suggest we remove this method from nautilus. > If we really want to provide such a feature, the implementation > should go to TestCase and/or Context. > The SystemBrowser should not tinker with processes and manipulate > context stacks. > > > Yes. (The method is NautilusUI>>#debugTest: ) > > > > I committed a change to remove it. > > Marcus >

Feb. 16, 2015

Re: [Pharo-dev] Number>>#percent

by Sean P. DeNigris

Guillermo Polito wrote > Sean, but if you need something like that, why wouldn't you load > aconcagua? > > I'm just in the crusade of putting less in the kernel by default ^^. Good question! The little project I was working on when I implemented that method /was/ using Aconcagua! But: 1. This is a simple, common conversion which a. could make the kernel itself a bit more intention revealing Job>>#progress ^ min >= max ifTrue: [ 1 ] ifFalse: [ (currentValue - min) / (max - min) ] could become: ^ min >= max ifTrue: [ 100 percent ] ifFalse: [ (currentValue - min) / (max - min) ] b. would've made my life a bit easier on several occasions, but feels much too lightweight to load a library for. There doesn't seem to be an entire domain behind it. One method gets you the whole thing. 2. AFAICT, Aconcagua doesn't really solve this problem. It defines families of units and conversions between them, but here there's just one concept as mentioned in 1.b. above ----- Cheers, Sean -- View this message in context: http://forum.world.st/Number-percent-tp4805988p4806047.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 16, 2015

Re: [Pharo-dev] DBXTalk

by Franck Warlouzet

We do have targets, like make an example application using Glorp and being able to exchange the database. We try to make Glorp easier to use (Simple way to create queries, to get the results, etc). When it is done, we will write a cool tutorial and documentation. Franck From: Tudor Girba tudor(a)tudorgirba.com To: pharo-dev(a)lists.pharo.org Subject: DBXTalk Date: Mon, 16 Feb 2015 21:24:32 +0100 Welcome! Great news. This is an important area for Pharo. Please do keep us informed of your progress. Do you have a specific target in mind for this project (besides the SQL Builder)? Cheers, Doru From: franck.warlouzet(a)hotmail.fr To: pharo-dev(a)lists.pharo.org Subject: DBXTalk Date: Mon, 16 Feb 2015 21:12:45 +0100 Hi, We are 3 students from Lille (Franck Warlouzet, Thomas Heniart and Merwan Ouddane) working on Pharo, precisely on DBXTalk. We already fixed some tests, we did an adapter ( available here : http://www.smalltalkhub.com/#!/~ThomasHeniart/GlorpDriverMySQL/ ). GlorpDriverMySQL contains the adapter MySQL for Glorp, so you can use Glorp with MySQL (There is a method NativeMySQLDriver>>beGlorpDefaultDriver to use it as native driver). We wrote a tutorial to show how to use MySQLDriver. It's available here : https://drive.google.com/open?id=0B5GYfJsa6d98YVJGWG1kQXBYcFE&authuser=0 Also, we are working on a SQLBuilder to create queries, for example something like that : (connection newQuery) newTable: 'test' ifNotExists; withColumn: 'integ' ofType: 'Int'; withColumn: 'string' ofType: 'VARCHAR(20)'; build. It will be available soon, when we are done. We would like to know what you would expect from it. We have some ideas, you can complete them, it would help us to do something right. We would appreciate every feedback or idea. Thanks, Franck

Feb. 16, 2015

Re: [Pharo-dev] DBXTalk

by Tudor Girba

Welcome! Great news. This is an important area for Pharo. Please do keep us informed of your progress. Do you have a specific target in mind for this project (besides the SQL Builder)? Cheers, Doru On Mon, Feb 16, 2015 at 9:12 PM, Franck Warlouzet < franck.warlouzet(a)hotmail.fr> wrote: > Hi, > > We are 3 students from Lille (Franck Warlouzet, Thomas Heniart and Merwan > Ouddane) working on Pharo, precisely on DBXTalk. > We already fixed some tests, we did an adapter ( available here : > http://www.smalltalkhub.com/#!/~ThomasHeniart/GlorpDriverMySQL/ ). > GlorpDriverMySQL contains the adapter MySQL for Glorp, so you can use Glorp > with MySQL (There is a method NativeMySQLDriver>>beGlorpDefaultDriver to > use it as native driver). > > We wrote a tutorial to show how to use MySQLDriver. It's available here : > https://drive.google.com/open?id=0B5GYfJsa6d98YVJGWG1kQXBYcFE&authuser=0 > > Also, we are working on a SQLBuilder to create queries, for example > something like that : > > (connection newQuery) > newTable: 'test' > ifNotExists; > withColumn: 'integ' ofType: 'Int'; > withColumn: 'string' ofType: 'VARCHAR(20)'; > build. > > It will be available soon, when we are done. We would like to know what > you would expect from it. We have some ideas, you can complete them, it > would help us to do something right. We would appreciate every feedback or > idea. > > Thanks, > > Franck > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 16, 2015