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

Re: [Pharo-project] [Pharo-users] 1.4 update is broken do not use it

by StÃ©phane Ducasse

+1 And we will do our best to get the best out of us. And people should join if they want more. Stef >>>>> so now updating from https://gforge.inria.fr/frs/download.php/28827/Pharo-1.4-14065.zip >>>> >>>> Is this a core or a full image? If core (which one can use to update further) shouldnt this be reflected in the ZIP's name? >> >>> In 1.4, there is only one image. >>> This simplifies everything.... >> >> >> OK, but then two questions regarding the above image: >> >> - what is the intention? Provide only the core image in the future? >> Will ConfigurationOfPharo still be maintained to be able to >> build a dev image? >> > The intention is that maintaining two images is one too much. > > -> We need to test two images > -> We track bugs in two categories (see my old mails, very confusing "X bugs here, Z bugs open there") > -> We have two completely different ways of how fixes get into the system. > And the one fo the ConfigurationOfPharo is really complex to get even a trivial change in. > > In addtion, it complicates many things: > > -> the story gets complex. Two downloads. Which do I take? Just look at > pharo-project.org. Too complex. > -> The Full image can not be updated. That alone is a killer. > -> We maintain two browsers > -> ..... > > It's not sustainable. > > It should be noted that the ConfigurationOfPharo was broken for far too many days, > and fixing takes too much effort. > > The idea is *not* that this one image has the functionality of the old Core image. > The idea instead is to have *one* image that is the one that everyone uses and that > is the best development environment that we can do. > >> - why is the provided image a Cog only image (was not able to open it >> with the standard VM, so it looks like it was saved with Cog) >> Is this intended? > > I have only one VM on my machine. So this lead to the problem that I updated > the image for download with that VM.... and I forgot that there is problem. This > happend in 1.2 and in 1.3 and in 1.4, and I am tired of it. > > I am too dumb, I will never get it right. > > This is again is a question of complexity: Something that is so complex needs > to be simplified. > > We can not support all old VMs forever. New VMs can load the new image format. > > One of the ideas of 1.4 is that besides one Image, we will have "one" set > of VMs. The ones build by the Jenkins/Hudson. They run the new image format. > > The rule is: for version X of Pharo, use version X of the VM. > > This solves another problem: Moving to the Future. E.g. the new VMs support > better finalization, yet the image needs to be compatible forever to the old code. > The new VMs support Ephemerons. > Do we ever want to use them? An images where they are active will not run on > the old VMs. > > Being able to move forward on the VM side is very, very important. It makes > no sense to be backward *and* forward compatible forever. > > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > >

Aug. 1, 2011

Re: [Pharo-project] How to deprecate a Class?

by StÃ©phane Ducasse

The most important aspects is that there is not reference to it. and that if we replace it by something else, it works. After we can write in the comments in big that the class is deprecated. Stef On Aug 1, 2011, at 8:18 PM, Bernardo Ezequiel Contreras wrote: > Hi all, > In the issue tracker, there are many issues to deprecate several classes. so, What do you do in order to deprecate a class? > Could you explain the procedure to deprecate a class? > > Thanks. >

Aug. 1, 2011

Re: [Pharo-project] condenseChanges problem

by StÃ©phane Ducasse

Thanks! Stef On Aug 1, 2011, at 7:03 PM, Pavel Krivanek wrote: > The problem was with double exclamation mark in method > MultiByteFileStreamTest >> #chunkString. Fix attached to the issue. It > only rewrites original source code with the same one. > > -- Pavel > > > On Mon, Aug 1, 2011 at 2:04 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Aug 1, 2011, at 2:02 PM, Pavel Krivanek wrote: >> >>> Hi, >>> >>> I created a special on the CI server and it seems that we are not able >>> to condense changes. See >>> https://ci.lille.inria.fr/pharo/job/Pharo%201.4%20condenseChanges/5/console >> >> Yes, this is already broken since sime time... >> >> http://code.google.com/p/pharo/issues/detail?id=3923 >> >> (I think even in 1.2). >> >> Everything not tested will break... >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >> >

Aug. 1, 2011

Re: [Pharo-project] [Pharo-users] 1.4 update is broken do not use it

by Marcus Denker

On Aug 1, 2011, at 6:27 PM, Torsten Bergmann wrote: > Marcus wrote: >>>> so now updating from https://gforge.inria.fr/frs/download.php/28827/Pharo-1.4-14065.zip >>> >>> Is this a core or a full image? If core (which one can use to update further) shouldnt this be reflected in the ZIP's name? > >> In 1.4, there is only one image. >> This simplifies everything.... > > > OK, but then two questions regarding the above image: > > - what is the intention? Provide only the core image in the future? > Will ConfigurationOfPharo still be maintained to be able to > build a dev image? > The intention is that maintaining two images is one too much. -> We need to test two images -> We track bugs in two categories (see my old mails, very confusing "X bugs here, Z bugs open there") -> We have two completely different ways of how fixes get into the system. And the one fo the ConfigurationOfPharo is really complex to get even a trivial change in. In addtion, it complicates many things: -> the story gets complex. Two downloads. Which do I take? Just look at pharo-project.org. Too complex. -> The Full image can not be updated. That alone is a killer. -> We maintain two browsers -> ..... It's not sustainable. It should be noted that the ConfigurationOfPharo was broken for far too many days, and fixing takes too much effort. The idea is *not* that this one image has the functionality of the old Core image. The idea instead is to have *one* image that is the one that everyone uses and that is the best development environment that we can do. > - why is the provided image a Cog only image (was not able to open it > with the standard VM, so it looks like it was saved with Cog) > Is this intended? I have only one VM on my machine. So this lead to the problem that I updated the image for download with that VM.... and I forgot that there is problem. This happend in 1.2 and in 1.3 and in 1.4, and I am tired of it. I am too dumb, I will never get it right. This is again is a question of complexity: Something that is so complex needs to be simplified. We can not support all old VMs forever. New VMs can load the new image format. One of the ideas of 1.4 is that besides one Image, we will have "one" set of VMs. The ones build by the Jenkins/Hudson. They run the new image format. The rule is: for version X of Pharo, use version X of the VM. This solves another problem: Moving to the Future. E.g. the new VMs support better finalization, yet the image needs to be compatible forever to the old code. The new VMs support Ephemerons. Do we ever want to use them? An images where they are active will not run on the old VMs. Being able to move forward on the VM side is very, very important. It makes no sense to be backward *and* forward compatible forever. Marcus -- Marcus Denker -- http://marcusdenker.de

Aug. 1, 2011

Re: [Pharo-project] [squeak-dev] Contexts must only be created with newForMethod: ...

by Mariano Martinez Peck

Hi Chris. Yes, I have this problem when materializing MethodContext instances in Fuel. I've solved it adding the method: ContextPart class >> newFromFrameSize: aFrameSize ^ super basicNew: aFrameSize but it is a hack. So yes, if there is no real reason to do the opposite, I would change #basicNew: Cheers On Mon, Aug 1, 2011 at 8:27 PM, Chris Muller <ma.chris.m(a)gmail.com> wrote: > .. but #newForMethod: requires more in the API than it really uses. > It only checks the methods #frameSize to determine what basicSized > MethodContext to create - it doesn't actually set its method from the > one passed in. > > newForMethod: aMethod > --- (comment snipped for brevity) --- > ^ super basicNew: aMethod frameSize > > So, would it be ok to relax MethodContext class>>basicNew: to something > like: > > basicNew: size > ^ (size = CompiledMethod smallFrameSize or: [ size = > CompiledMethod fullframeSize ]) > ifTrue: [ super basicNew: size ] > ifFalse: [ self error: 'Contexts must be ', > CompiledMethod smallFrameSize, ' or ', CompiledMethod fullframeSize, ' > bytes.' ] > > -- Mariano http://marianopeck.wordpress.com

Aug. 1, 2011

Re: [Pharo-project] How to deprecate a Class?

by Marcus Denker

On Aug 1, 2011, at 8:18 PM, Bernardo Ezequiel Contreras wrote: > Hi all, > In the issue tracker, there are many issues to deprecate several classes. so, What do you do in order to deprecate a class? > Could you explain the procedure to deprecate a class? > often it's just moving it to the Deprecated package. (Deprecated14, does not exist yet I think). Sometimes it makes sense to deprecate the class instatiaton methods in addition. Marcus -- Marcus Denker -- http://marcusdenker.de

Aug. 1, 2011

Re: [Pharo-project] How to deprecate a Class?

by Mariano Martinez Peck

This is not easy. So far I saw several things: 1) move the class to a package Deprecated12 or Deprecated13 or whatever pharo version. 2) Nuke the class: empty the method dictionary. That way, you can load code that use such class but you will have lots of dnu at runtime I am not sure which is the desired behavior now. Of course, a correct way to deprecate classes would be awesome, but I guess it is not that easy. On Mon, Aug 1, 2011 at 8:18 PM, Bernardo Ezequiel Contreras < vonbecmann(a)gmail.com> wrote: > Hi all, > In the issue tracker, there are many issues to deprecate several classes. > so, What do you do in order to deprecate a class? > Could you explain the procedure to deprecate a class? > > Thanks. > > -- Mariano http://marianopeck.wordpress.com

Aug. 1, 2011

[Pharo-project] How to deprecate a Class?

by Bernardo Ezequiel Contreras

Hi all, In the issue tracker, there are many issues to deprecate several classes. so, What do you do in order to deprecate a class? Could you explain the procedure to deprecate a class? Thanks.

Aug. 1, 2011

Re: [Pharo-project] Deprecating Protocol browser

by StÃ©phane Ducasse

Ok we will see. But if you really use it may be it is time to have a look at the FlatMessageListBrowser and define a new protocol browser based on it. Because we **will** remove StringHolder. Stef On Aug 1, 2011, at 6:29 PM, Pat Maddox wrote: > On Aug 1, 2011, at 12:24 PM, Randal L. Schwartz wrote: > >>>>>>> "StÃ©phane" == StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> writes: >> >> StÃ©phane> may be :) >> >> StÃ©phane> but for me this flat view never worked. >> >> As an example of how it was useful to me... the WABrush classes are >> fairly deep, particularly in the form elements, and it was difficult to >> see how to configure a given brush. Flattening it as a protocol browser >> instantly gave me the full API, including letting me know which methods >> were inherited so are also likely to be used by other common brushes. >> >> The hierarchy browser can do *some* of that, but I find them both to be >> useful at different times. > > Agreed 100%. Heirarchy browser is decent at figuring out what messages an object responds to, great for figuring out where exactly those are implemented. But if I want to know all the messages it responds to, protocol browser is critical. > > Pat

Aug. 1, 2011

Re: [Pharo-project] Deprecating Protocol browser

by Pat Maddox

On Aug 1, 2011, at 12:24 PM, Randal L. Schwartz wrote: >>>>>> "StÃ©phane" == StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> writes: > > StÃ©phane> may be :) > > StÃ©phane> but for me this flat view never worked. > > As an example of how it was useful to me... the WABrush classes are > fairly deep, particularly in the form elements, and it was difficult to > see how to configure a given brush. Flattening it as a protocol browser > instantly gave me the full API, including letting me know which methods > were inherited so are also likely to be used by other common brushes. > > The hierarchy browser can do *some* of that, but I find them both to be > useful at different times. Agreed 100%. Heirarchy browser is decent at figuring out what messages an object responds to, great for figuring out where exactly those are implemented. But if I want to know all the messages it responds to, protocol browser is critical. Pat

Aug. 1, 2011