December 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] Eclipse Icons for Pharo

by Ben Coman

Dec. 11, 2011

Re: [Pharo-project] Cleaning up SmartRefStream use

by Mariano Martinez Peck

On Sun, Dec 11, 2011 at 4:35 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Dec 11, 2011, at 4:26 PM, Mariano Martinez Peck wrote: > > > > > > > On Sun, Dec 11, 2011 at 11:32 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > Indeed this is fun I was doing the same :) > > Now I do not understand why some parts of the system uses dataStream, > others ReferenceStream and finally others SmartRefStream > > why not all of them use SmartRefStream. > > > > It is not that I like these guys, but their class comments are pretty > clear: > > - DataStream does NOT handle cycles, but hence it may be faster in > certain scenarios. I guess that for example, Monticello is sure that in its > definitions, there cannot be cycles. In addition, it doesn't take into > account variables names/order and hence class reshape isn't supported. > > - ReferenceStream supports cycles but still doesn't support class > reshape. > > - SmartRefStream supports cycles and class reshape. > > > sounds good Yes it does. In fact, I would love also to have those things optional/configurable in Fuel: optional cycle detection and optional class reshape support :) > then we should be able to replace all the reference stream and smart by > fuel. > Yes, but Fuel is not completly ready to fully replace them. There are some hooks they provide that Fuel does not yet. But we will get there at some point. > > stef > -- Mariano http://marianopeck.wordpress.com

Dec. 11, 2011

Re: [Pharo-project] [ANN] Eclipse Icons for Pharo

by Ben Coman

Dec. 11, 2011

Re: [Pharo-project] Keymapping & OB conflict (was Re: Chasing Browsers)

by Lukas Renggli

> This is important for us to know that and this is a really nice stab > in our back and this will kill a lot of the effort we build over the years. I don't understand why you think this is a stab into your back? I have repeated the same concerns over and over again. > Now how can we make progress if we do not change Pharo? Again, we already discussed this many times. I think Pharo is totally off the track: Pharo should concentrate on getting a stable core and enabling distributions on top, not on integrating as much new things as possible. > May be a dead pharo is better for you. A dead Pharo is not my goal. I need a minimal Pharo with an absolutely trusted and stable core; a system where I can load all my code; a system that does not force me to use things I don't want to use. > @Lukas: please, could you point out what are the expected problems? > For example, all PetitParser-Tests are green out of the box in the latest 1.4. Nice, maybe the others also just work? OB does not work though because Polymorph changed (and the debugger doesn't even open in the UI thread anymore either, so it is not possible to figure out the problem); and because it expects a different version of RB. > You were against changing RB, so how can we do remote tooling? I was against chaining RB, because the proposed changes undermined design decisions in RB. In general, it feels extremely strange to me if people change code (or even class comments) without understanding the code. Also, for that matter, I don't see how you want to use RB for remote tooling? If you remember, I pointed out an interview a while ago with John where they discuss why remote tooling wouldn't work without rewriting most parts. Lukas -- Lukas Renggli www.lukas-renggli.ch

Dec. 11, 2011

Re: [Pharo-project] Cleaning up SmartRefStream use

by StÃ©phane Ducasse

On Dec 11, 2011, at 4:26 PM, Mariano Martinez Peck wrote: > > > On Sun, Dec 11, 2011 at 11:32 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Indeed this is fun I was doing the same :) > Now I do not understand why some parts of the system uses dataStream, others ReferenceStream and finally others SmartRefStream > why not all of them use SmartRefStream. > > It is not that I like these guys, but their class comments are pretty clear: > - DataStream does NOT handle cycles, but hence it may be faster in certain scenarios. I guess that for example, Monticello is sure that in its definitions, there cannot be cycles. In addition, it doesn't take into account variables names/order and hence class reshape isn't supported. > - ReferenceStream supports cycles but still doesn't support class reshape. > - SmartRefStream supports cycles and class reshape. > sounds good then we should be able to replace all the reference stream and smart by fuel. stef

Dec. 11, 2011

Re: [Pharo-project] Cleaning up SmartRefStream use

by StÃ©phane Ducasse

> That's a very good question. Where should design decisions be documented? > On one side, we should have requirements that we document with some > high level TestCase. > But whether the implementation is guided by time/memory efficiency, > code simplicity, or just historically available packages is not easily > described by tests. > Obviously, you would have a hard time discovering this in legacy code > (digging squeak wiki and mailing list?). > The question should apply to Pharo too. > Pharo is young, so maybe all design decisions can be retrieved by > virtue of human memory... > But will it be the case in 5 years? We will introduce package manifesto and they should hold this. as well as false positive for rules checking and documentation. I think that any successful system will have such problem. Now high level rules, tests are documentation are important. Stef

Dec. 11, 2011

Re: [Pharo-project] Cleaning up SmartRefStream use

by Mariano Martinez Peck

On Sun, Dec 11, 2011 at 11:32 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Indeed this is fun I was doing the same :) > Now I do not understand why some parts of the system uses dataStream, > others ReferenceStream and finally others SmartRefStream > why not all of them use SmartRefStream. > It is not that I like these guys, but their class comments are pretty clear: - DataStream does NOT handle cycles, but hence it may be faster in certain scenarios. I guess that for example, Monticello is sure that in its definitions, there cannot be cycles. In addition, it doesn't take into account variables names/order and hence class reshape isn't supported. - ReferenceStream supports cycles but still doesn't support class reshape. - SmartRefStream supports cycles and class reshape. > Stef > > On Dec 11, 2011, at 10:43 AM, Marcus Denker wrote: > > > Hi, > > > > We should minimize the use of SmartRefStream... so we can remove it > eventually. > > > > I already did a little bit (e.g. removing BitmapStreamTests). These are > the next steps: > > > > Issue 5081: Remve Morph saving to file/loading > > http://code.google.com/p/pharo/issues/detail?id=5081 > > > > Anyone needs this? > > > > Issue 5084: Remove textStyle FileOut > > http://code.google.com/p/pharo/issues/detail?id=5084 > > > > Is this used? Strange corner of the system... lots of dead code. > > > > Issue 5083: remove unused methods from SmartRefStream > > http://code.google.com/p/pharo/issues/detail?id=5083 > > > > Towards removing it alltogether. > > > > > > > > > > -- > > Marcus Denker -- http://marcusdenker.de > > > > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 11, 2011

Re: [Pharo-project] Cleaning up SmartRefStream use

by Nicolas Cellier

2011/12/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Indeed this is fun I was doing the same :) > Now I do not understand why some parts of the system uses dataStream, others ReferenceStream and finally others SmartRefStream > why not all of them use SmartRefStream. > > Stef > That's a very good question. Where should design decisions be documented? On one side, we should have requirements that we document with some high level TestCase. But whether the implementation is guided by time/memory efficiency, code simplicity, or just historically available packages is not easily described by tests. Obviously, you would have a hard time discovering this in legacy code (digging squeak wiki and mailing list?). The question should apply to Pharo too. Pharo is young, so maybe all design decisions can be retrieved by virtue of human memory... But will it be the case in 5 years? Nicolas > On Dec 11, 2011, at 10:43 AM, Marcus Denker wrote: > >> Hi, >> >> We should minimize the use of SmartRefStream... so we can remove it eventually. >> >> I already did a little bit (e.g. removing BitmapStreamTests). These are the next steps: >> >> Issue 5081: Â Remve Morph saving to file/loading >> Â Â Â http://code.google.com/p/pharo/issues/detail?id=5081 >> >> Â Â Â Anyone needs this? >> >> Issue 5084: Â Remove textStyle FileOut >> Â Â Â http://code.google.com/p/pharo/issues/detail?id=5084 >> >> Â Â Â Is this used? Strange corner of the system... lots of dead code. >> >> Issue 5083: Â remove unused methods from SmartRefStream >> Â Â Â http://code.google.com/p/pharo/issues/detail?id=5083 >> >> Â Â Â Towards removing it alltogether. >> >> >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> > >

Dec. 11, 2011

Re: [Pharo-project] Keymapping & OB conflict (was Re: Chasing Browsers)

by Tudor Girba

Hi, On 11 Dec 2011, at 15:49, Esteban Lorenzano wrote: > Hi Lukas, > > I just loaded Magritte2 into Pharo 1.4 and it loads well with all tests in green. > Also, Magritte-Morph loads and seems to run well... just a small change: > > replace: > > PluggableListMorphOfMany > > with: > > PluggableListMorph ... > beMultipleSelection Thanks for looking into this :). > (now, I want to deprecate #description for #magritteDescription and add a pragma builder with <magritte> and <magritteContainer> keywords :) I think that would be most welcome. Cheers, Doru > cheers, > Esteban > > El 11/12/2011, a las 10:58a.m., StÃ©phane Ducasse escribiÃ³: > >> Thanks for this really bad and sad message. >> So you are implying that Seaside, Magritte, Pier, OB, PetitParser >> will not be maintained on Pharo 1.4. >> >> This is important for us to know that and this is a really nice stab in our back and this will kill >> a lot of the effort we build over the years. >> >> Thanks again lukas! >> At least this is clear. >> >> Stef >> >> On Dec 11, 2011, at 12:33 PM, Lukas Renggli wrote: >> >>>> - then that OB can be loaded on top of Pharo. Remember we are not against OB we just do not have >>>> the knowledge to maintain it. So if lukas gets OB working for 1.4 beta then we will probably include in Pharo. >>>> Now if OB is working for 1.4 only three months after 1.4 is released then we will not include it. >>> >>> Yes please, do not wait for me. >>> >>> Just to repeat myself: With Pharo 1.4 having uncountable changes in >>> core parts of the system and with the system including more and more >>> forked and increasingly incompatible versions of packages (AST, RB, >>> FS, Shout, Regex, ...) I am unwilling to go through the same pain as >>> with Pharo 1.3 again. In the current state, I don't see any of the >>> code I am involved with (including Seaside, Magritte, Pier, OB, >>> PetitParser, ...) to move forward. I suspect that moving to another >>> development platform soon causes less pain than to move to adopt the >>> next Pharo :-( >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> > > -- www.tudorgirba.com "Quality cannot be an afterthought."

Dec. 11, 2011

Re: [Pharo-project] Keymapping & OB conflict (was Re: Chasing Browsers)

by Esteban Lorenzano

Hi Lukas, I just loaded Magritte2 into Pharo 1.4 and it loads well with all tests in green. Also, Magritte-Morph loads and seems to run well... just a small change: replace: PluggableListMorphOfMany with: PluggableListMorph ... beMultipleSelection (now, I want to deprecate #description for #magritteDescription and add a pragma builder with <magritte> and <magritteContainer> keywords :) cheers, Esteban El 11/12/2011, a las 10:58a.m., StÃ©phane Ducasse escribiÃ³: > Thanks for this really bad and sad message. > So you are implying that Seaside, Magritte, Pier, OB, PetitParser > will not be maintained on Pharo 1.4. > > This is important for us to know that and this is a really nice stab in our back and this will kill > a lot of the effort we build over the years. > > Thanks again lukas! > At least this is clear. > > Stef > > On Dec 11, 2011, at 12:33 PM, Lukas Renggli wrote: > >>> - then that OB can be loaded on top of Pharo. Remember we are not against OB we just do not have >>> the knowledge to maintain it. So if lukas gets OB working for 1.4 beta then we will probably include in Pharo. >>> Now if OB is working for 1.4 only three months after 1.4 is released then we will not include it. >> >> Yes please, do not wait for me. >> >> Just to repeat myself: With Pharo 1.4 having uncountable changes in >> core parts of the system and with the system including more and more >> forked and increasingly incompatible versions of packages (AST, RB, >> FS, Shout, Regex, ...) I am unwilling to go through the same pain as >> with Pharo 1.3 again. In the current state, I don't see any of the >> code I am involved with (including Seaside, Magritte, Pier, OB, >> PetitParser, ...) to move forward. I suspect that moving to another >> development platform soon causes less pain than to move to adopt the >> next Pharo :-( >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > >

Dec. 11, 2011