- Pharo-dev - lists.pharo.org

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

by Schwab,Wilhelm K

Some specific constructive feedback: the ones that "don't work" (IMHO) are the debug and profile icons. Overall, great job! ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Sunday, December 11, 2011 4:04 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] Eclipse Icons for Pharo On 11 Dec 2011, at 03:15, Esteban Lorenzano wrote: > Today I was bored and not wanting to think too much... but I wanted to do something for Pharo... Great initiative! I personnaly don't like each of them, but these icons form a big, consistent set and make a good modernization of the UI. We should take this as a start and go over all missing ones, and maybe add a few unique once. Thanks. Sven

Dec. 11, 2011

Re: [Pharo-project] Cleaning up SmartRefStream use

by StÃ©phane Ducasse

On Dec 11, 2011, at 4:54 PM, Mariano Martinez Peck wrote: > > > 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. we will have because we do not want to stay indefinitely with image segment and smart ref. :) > > > stef > > > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 11, 2011

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

by StÃ©phane Ducasse

All the compilation chain and code management and manipulation tools should be able to work on remote environment. We already discussed and I do not have the time to explain that the design of john was not taking into account that we would like to be able to work with one tool on another environment. The Browser environment = the complete code in the image does not work anymore. Anyway you do not want to change and this is perfect. It is just raging that I do not have enough time to fix it. Now we will see in 1.4 if people want to still use 1.3 or if they have benefit to work with 1.4. We integrated RB because we need to be able to move forward. It would be easy to have two configurations one for 1.3 and one for 1.4 but since you do not want to maintain it when you change your versions then we have to spend more time and frustration but we will do it. I spent a full day the last time while it would have cost you may be 10 min but I have no problem with that since the only thing I can do is to do it, I will do it. We will continue to work and push pharo and people can continue to use it or not. We know where we want to go and we will take responsibility and probably it will burn a bit more of our energy but there is no other paths sadly. Stef On Dec 11, 2011, at 4:42 PM, Lukas Renggli wrote: >> 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] [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