November 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Old ClassBuilder remove!

by StÃ©phane Ducasse

+ 1000 I want relationship using Slot :) Stef On Nov 21, 2013, at 2:45 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > This is not *just cleaning*! You might perceive it as such being so involved in it. You guys replaced something ugly with something based on a sound explicit model. > > When you do this at such a core level, the possibilities explode two layers on top. You might just do not see it, yet :). > > Just two examples: > - Morphic uses a dictionary to allow extensions to add attributes to the base class. This is closed-world-based-assumption thinking because I have to know in advance what parts will be extended by someone else. This should be easily changeable with slots given that slots are manipulate-able at runtime (ideally). > - In Fame we implement bidirectional relationships. By bidirectional relationships I mean you have classes like A ->* B, and when you have a B object and set the A parent, it automatically adds the B instance to the collection in A. The current implementation in Fame is difficult to grasp and the code of specifying the slots is spread over the whole Moose models. Once slots are supported as first class, we can build the strategy of bidirectionality directly in the slot support. This will be more elegant. > > Doru > > > On Thu, Nov 21, 2013 at 2:24 PM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 21 nov. 2013, at 13:44, kilon alios <kilon.alios(a)gmail.com> wrote: > >> any links why newcomers like me should be impressed ? Whats the advantages ? > > That's just cleaning. The old class builder was an incredibly complex piece of code that is now replaced with the Slot class builder. > The later is based on slots and is much more understandable and thus much easier to maintain. > It's been integrated some time ago thanks to Martin. > > Slots are the work of Toon and Camillo and enables a lot of useful features: > http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectL… > They are based on the reification of class layouts (variable,weak,fixed and co) and instance variables (slots). > Slots are an abstraction added on top of low-level class "fields". > It means that one will be able to create a customized slot class that define the logic to read and write a slot: > > Object subclass: #MyClass > slots: { x => MyFancySlot } > category: 'Playground' > > Then when a method read or writes x, the logic you defined in MyFancySlot is executed. > All that still need to be absorbed by Opal so it's not available right now but it will (Pharo 4)! > >> >> >> >> On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment. >> >> Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :) >> >> Doru >> >> >> >> >> On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >> wow, impressive! >> >> >> On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Hi, >> >> Yesterday Camille did the change to finally remove the old class builder! >> (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes). >> >> This means >> - 1000 Loc of completely un-understandable code removed. >> - we now 100% run on the new class builder from the Slot Project. >> >> Next on the list (not all for Pharo3): >> >> - remove PackageInfo >> - old Browser + CodeHolder hierarchy >> - PseudoClass&Co â> Ring >> - old AST+Compiler (this in Pharo4) >> >> We already did (all in Pharo3): >> -> remove URI >> -> deprecated Url for ZnUrl >> -> removed HTTPSocket facade >> -> MIMEType retired for ZnMimeType >> -> old Debugger is removed >> -> Class categories are replaced by Protocols >> >> I am quite sure that these cleanups will enable us to build a lot of very interesting things >> in the future. >> >> Marcus >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Nov. 23, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by StÃ©phane Ducasse

On Nov 21, 2013, at 2:24 PM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 21 nov. 2013, at 13:44, kilon alios <kilon.alios(a)gmail.com> wrote: > >> any links why newcomers like me should be impressed ? Whats the advantages ? > > That's just cleaning. No this is more than that. Classbuilder was an horrible beast. > The old class builder was an incredibly complex piece of code that is now replaced with the Slot class builder. > The later is based on slots and is much more understandable and thus much easier to maintain. > It's been integrated some time ago thanks to Martin. > > Slots are the work of Toon and Camillo and enables a lot of useful features: > http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectL… > They are based on the reification of class layouts (variable,weak,fixed and co) and instance variables (slots). > Slots are an abstraction added on top of low-level class "fields". > It means that one will be able to create a customized slot class that define the logic to read and write a slot: > > Object subclass: #MyClass > slots: { x => MyFancySlot } > category: 'Playground' > > Then when a method read or writes x, the logic you defined in MyFancySlot is executed. > All that still need to be absorbed by Opal so it's not available right now but it will (Pharo 4)! > >> >> >> >> On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment. >> >> Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :) >> >> Doru >> >> >> >> >> On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >> wow, impressive! >> >> >> On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Hi, >> >> Yesterday Camille did the change to finally remove the old class builder! >> (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes). >> >> This means >> - 1000 Loc of completely un-understandable code removed. >> - we now 100% run on the new class builder from the Slot Project. >> >> Next on the list (not all for Pharo3): >> >> - remove PackageInfo >> - old Browser + CodeHolder hierarchy >> - PseudoClass&Co â> Ring >> - old AST+Compiler (this in Pharo4) >> >> We already did (all in Pharo3): >> -> remove URI >> -> deprecated Url for ZnUrl >> -> removed HTTPSocket facade >> -> MIMEType retired for ZnMimeType >> -> old Debugger is removed >> -> Class categories are replaced by Protocols >> >> I am quite sure that these cleanups will enable us to build a lot of very interesting things >> in the future. >> >> Marcus >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >

Nov. 23, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by StÃ©phane Ducasse

On Nov 21, 2013, at 9:02 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > Yesterday Camille did the change to finally remove the old class builder! > (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes). > > This means > - 1000 Loc of completely un-understandable code removed. oh yes! > - we now 100% run on the new class builder from the Slot Project. Excellent. There is so many things that I would like to do (think about bootstrap and mini kernel). > Next on the list (not all for Pharo3): > > - remove PackageInfo > - old Browser + CodeHolder hierarchy > - PseudoClass&Co â> Ring > - old AST+Compiler (this in Pharo4) > > We already did (all in Pharo3): > -> remove URI > -> deprecated Url for ZnUrl > -> removed HTTPSocket facade > -> MIMEType retired for ZnMimeType > -> old Debugger is removed > -> Class categories are replaced by Protocols > > I am quite sure that these cleanups will enable us to build a lot of very interesting things > in the future. yes :)

Nov. 23, 2013

Re: [Pharo-dev] Xtreams in Pharo 3

by StÃ©phane Ducasse

>> >>> If Xtreams goes in the core of Pharo (which could be good), there should be no compatibility layers with others platforms. >>> Sorry but we have too many of them and we do not want to have strings attached. >>> if necessary we can rename the complete library so that people can load the real CrossPlatformXtream projects on top of Pharo. >>> >>> I'm not sure that people can understand that but this is important. And we do not do that for the sake of it. >>> As one of the keeper of the core I do not want to have to think about systems I do not know. >> >> I completely understand the desire to do this. Every other platform >> maintainer agrees with you. That's why hardly anything ever gets done >> between the dialects, and why those that do maintain cross-dialect >> libraries probably (I know I certainly do) curse all the platform >> maintainers for being so insular. This problem even has a name: the >> tragedy of the commons. >> >> frank > > @Stef - yes, I understand, but that is only an issue if/when we actually do include it for real, and if/when we actually start using it (remember Nile, it was there, but never used) Yes I think that treams will have a better chance > For now, I think it would be better to move together (remember, this code started and lives in VW), when we encounter insurmountable problems with compatibility, then weâll deal with them. Sure.

Nov. 23, 2013

Re: [Pharo-dev] How to use Opal for parsing peace of code?

by Juraj Kubelka

Hi Marcus, thank you for the deep explanation. I have just started to play with parsing source code. And I have found out the OpalCompiler example. Now I understand it is better to use this: root2 := RBParser parseMethod: 'foo1 ^Color blue'. node5 := root2 bestNodeFor: (14 to: 14). node6 := root2 bestNodeFor: (20 to: 21). There is even RBParser>>parseExpression:, if I need it. Cool! Thanks to point me to the right direction. Jura El 23-11-2013, a las 5:33, Marcus Denker <marcus.denker(a)inria.fr> escribiÃ³: > > On 22 Nov 2013, at 21:58, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > >> Hi! >> >> I am interested how to use Opal for parsing peace of code. I have supposed to use something like this: >> >> | root node1 node2 | >> root := OpalCompiler new >> source: 'Color blue yourself'; >> useFaultyForParsing: true; >> parse. >> root doSemanticAnalysis. >> node1 := root bestNodeFor: (2 to: 2). >> node2 := root bestNodeFor: (7 to: 7). >> >> But node1 is a RBMethodNode, and node2 is a RBVariableNode. >> >> Does it matter if source for OpalCompiler is peace of code or method source? >> > > Yes, by default it parses methods. When you tell it to parse expressions, it parses them > as doit-methods (it wraps them into a method node named DoIt and adds a return at the end). > We need to provide a way that it can parse expressionsâ¦ or maybe hide the Doit transform in the > âcompileâ while the parse gives you an untransformed expression? > > We need to do some more iterations on the API to make it nice to use as a general facade for the Parser. > Right now the API was driven purely by replacing existing usage without too much change, > as both Compiler and OpalCompiler have the same API (they are exchangeable). > > Doing the second iteration with keeping compatibility would be quite a challenge (and not fun to do), > so I will start with that as soon as we retire the old compiler and thus are in a position to really clean up. > > other notes: > > - the faulty (code with syntax error) parsing is very much an experiment. Do you need it? > - maybe for now just using RPParser directly is better. > > Yes, we need to enhance the OpalCompiler API to be good enough to not need any direct references to > any Parser (so people can plug their own). > E.g. there are lots of references to RBParser in the Refactoring Engine. The problem is that is we replace > them now, then all these uses break when you switch to the old Compiler as it uses a different API. > > So summary: it needs more work, but we can only do that in Pharo4. > > Marcus

Nov. 23, 2013

Re: [Pharo-dev] Xtreams in Pharo 3

by Sven Van Caekenberghe

On 23 Nov 2013, at 11:02, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 23 November 2013 09:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> If Xtreams goes in the core of Pharo (which could be good), there should be no compatibility layers with others platforms. >> Sorry but we have too many of them and we do not want to have strings attached. >> if necessary we can rename the complete library so that people can load the real CrossPlatformXtream projects on top of Pharo. >> >> I'm not sure that people can understand that but this is important. And we do not do that for the sake of it. >> As one of the keeper of the core I do not want to have to think about systems I do not know. > > I completely understand the desire to do this. Every other platform > maintainer agrees with you. That's why hardly anything ever gets done > between the dialects, and why those that do maintain cross-dialect > libraries probably (I know I certainly do) curse all the platform > maintainers for being so insular. This problem even has a name: the > tragedy of the commons. > > frank @Stef - yes, I understand, but that is only an issue if/when we actually do include it for real, and if/when we actually start using it (remember Nile, it was there, but never used) For now, I think it would be better to move together (remember, this code started and lives in VW), when we encounter insurmountable problems with compatibility, then weâll deal with them. >> Stef >> >> >> >>>> It's Pharo specific at the moment AFAICT because it refers to >>>> FileHandle and FileReference, while the upstream repo uses >>>> FSFileHandle and FSFileReference. The conversation's partly at >>>> https://code.google.com/p/xtreams/issues/detail?id=2 >>> >>> Thanks, Frank, for the explanation. Conclusion: for now it can be consider Pharo only (but given some class renames, it should be broader). >>> >>> With/without prefixes is one aspect, forking/not-forking another. >>> >>> Like I said, and like you acknowledged, it is possible to keep things together, but it requires real, continuous effort from all sides. >>> >>> Sven

Nov. 23, 2013

Re: [Pharo-dev] is this ok?

by Marcus Denker

On 22 Nov 2013, at 20:16, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Well this had been here for a while. I discovered it because it was triggered :). But it is very rare that this is triggered. > > Now when I look into the latest Pharo 3, this halt is not present. So I guess Andrei fixed it when we switched to the new debugger. > No, I removed the halt when I added the âwillCreateBlockâ to the checks. (In the past blocks where created with message sends, so #willSend made sure that the loop terminated in front of the block, now it runs over the block creation codeâ¦). > > 2013/11/22 Esteban Lorenzano <estebanlm(a)gmail.com> > in the debugger: > > stepToSendOrReturn > "Simulate the execution of bytecodes until either sending a message or > returning a value to the receiver (that is, until switching contexts)." > > | context | > [ self willSend or: [ self willReturn or: [ self willStore ] ] ] > whileFalse: [ > context := self step. > context == self ifFalse: [ > self halt. "<========================= THIS" > "Caused by mustBeBoolean handling" > ^context ]] > > > so... the halt is ok there? > > cheers, > Esteban >

Nov. 23, 2013

Re: [Pharo-dev] Pharo Success Stories - discovered the folder...

by Marcus Denker

yes, these we collected at the first pharo conf. On 23 Nov 2013, at 11:33, phil(a)highoctane.be wrote: > http://files.pharo.org/successStories/

Nov. 23, 2013

Pharo Success Stories - discovered the folder...

by phil＠highoctane.be

http://files.pharo.org/successStories/

Nov. 23, 2013

Re: [Pharo-dev] Xtreams in Pharo 3

by Frank Shearar

On 23 November 2013 09:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > If Xtreams goes in the core of Pharo (which could be good), there should be no compatibility layers with others platforms. > Sorry but we have too many of them and we do not want to have strings attached. > if necessary we can rename the complete library so that people can load the real CrossPlatformXtream projects on top of Pharo. > > I'm not sure that people can understand that but this is important. And we do not do that for the sake of it. > As one of the keeper of the core I do not want to have to think about systems I do not know. I completely understand the desire to do this. Every other platform maintainer agrees with you. That's why hardly anything ever gets done between the dialects, and why those that do maintain cross-dialect libraries probably (I know I certainly do) curse all the platform maintainers for being so insular. This problem even has a name: the tragedy of the commons. frank > Stef > > > >>> It's Pharo specific at the moment AFAICT because it refers to >>> FileHandle and FileReference, while the upstream repo uses >>> FSFileHandle and FSFileReference. The conversation's partly at >>> https://code.google.com/p/xtreams/issues/detail?id=2 >> >> Thanks, Frank, for the explanation. Conclusion: for now it can be consider Pharo only (but given some class renames, it should be broader). >> >> With/without prefixes is one aspect, forking/not-forking another. >> >> Like I said, and like you acknowledged, it is possible to keep things together, but it requires real, continuous effort from all sides. >> >> Sven > >

Nov. 23, 2013