- Pharo-dev - lists.pharo.org

Re: [Pharo-project] we will start 1.3 really soon

by StÃ©phane Ducasse

On Jan 15, 2011, at 9:57 AM, Adrian Lienhard wrote: > Cool :) > > BTW, I have a question related to 1.2 from a user's perspective: could we generate a summary to help people migrate from 1.1.1 to 1.2? In particular, the question is which changes in 1.2 are not backwards compatible and may break my code? I've been a bit out of the loop during the last months... so at least for me this is not obvious ;). There's http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotTwo but it doesn't tell the important bits. going over the issues tagged 1.2 and generate a report will take me at least a couple of hours.... so I'm not sure that I have the time to do it. Now if someone starts I can help improving the results. We can also take all the comments in the scriptloader methods. Stef > > Cheers, > Adrian > > On Jan 15, 2011, at 09:27 , StÃ©phane Ducasse wrote: > >> Hi guys >> >> there are some minors fixes to be addressed (like the preferences use in dev) but we will go 1.3 probably this evening and >> we will start to harvest a large list of pending issues. If you have seen fixes in squeak that you think are good please add a bug entry. >> After that we will plan for the big changes in 1.3 for me >> I would like to see >> - collection enh (finishing hashed collection) >> - weak structure support >> - announcement using weak structure >> - file system use >> - new package implementation (cyrille worked and will continue to really make sure everything works) >> - real beta of OPAL >> The goal is to have a release for 1.3 by June/July. >> >> Stef >> > >

Jan. 15, 2011

Re: [Pharo-project] we will start 1.3 really soon

by Janko MivÅ¡ek

Stef, you again forgot namespaces ... ;) Janko On 15. 01. 2011 09:27, StÃ©phane Ducasse wrote: > Hi guys > > there are some minors fixes to be addressed (like the preferences use in dev) but we will go 1.3 probably this evening and > we will start to harvest a large list of pending issues. If you have seen fixes in squeak that you think are good please add a bug entry. > After that we will plan for the big changes in 1.3 for me > I would like to see > - collection enh (finishing hashed collection) > - weak structure support > - announcement using weak structure > - file system use > - new package implementation (cyrille worked and will continue to really make sure everything works) > - real beta of OPAL > The goal is to have a release for 1.3 by June/July. > > Stef > -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Jan. 15, 2011

Re: [Pharo-project] [Pharo-users] Where do I find KeyedSet?

by StÃ©phane Ducasse

On Jan 15, 2011, at 9:52 AM, HernÃ¡n Morales Durand wrote: > Hi Stef > > 2011/1/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> On Jan 14, 2011, at 6:24 PM, HernÃ¡n Morales Durand wrote: >> >>> Try PluggableSet >>> >>> http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg22890.ht… >>> >>> Is there a way for you guys to deprecate deleted classes or mantain a >>> record of deleted behaviors? (IIRC VW did this from 2.x versions) >> >> We try but we do not have the engineers of VW. >> Now find somebody that pay us just 3 engineers full time for two years and you will not >> recognized pharo and its process. > > I know we are very few, but what about this idea, instead of just > deleting a class we may adopt these simple rules: > > 1 - If deleting a class add the deleted class name somewhere (in a method?) > 2 - If renaming a class, make the class to know its previous names > like #previousNames > (Norberto Manzanos implemented this for his own package management and > I think is a great idea) > > doesn't require tools, just some consensus and maybe a modified > #deleteClass to enforce this "policy" yes this would be nice to have tool doing it for us. > > it sounds feasible for you? what do you think? > > HernÃ¡n >

Jan. 15, 2011

Re: [Pharo-project] [Pharo-users] Where do I find KeyedSet?

by StÃ©phane Ducasse

Previous names is a good idea We should adopt it! Stef On Jan 15, 2011, at 9:52 AM, HernÃ¡n Morales Durand wrote: > Hi Stef > > 2011/1/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> On Jan 14, 2011, at 6:24 PM, HernÃ¡n Morales Durand wrote: >> >>> Try PluggableSet >>> >>> http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg22890.ht… >>> >>> Is there a way for you guys to deprecate deleted classes or mantain a >>> record of deleted behaviors? (IIRC VW did this from 2.x versions) >> >> We try but we do not have the engineers of VW. >> Now find somebody that pay us just 3 engineers full time for two years and you will not >> recognized pharo and its process. > > I know we are very few, but what about this idea, instead of just > deleting a class we may adopt these simple rules: > > 1 - If deleting a class add the deleted class name somewhere (in a method?) > 2 - If renaming a class, make the class to know its previous names > like #previousNames > (Norberto Manzanos implemented this for his own package management and > I think is a great idea) > > doesn't require tools, just some consensus and maybe a modified > #deleteClass to enforce this "policy" > > it sounds feasible for you? what do you think? > > HernÃ¡n >

Jan. 15, 2011

Re: [Pharo-project] Issue 3236 in pharo: Cuis DateAndTime Enhancement

by pharo＠googlecode.com

Updates: Labels: Milestone-1.3 Comment #2 on issue 3236 by stephane...(a)gmail.com: Cuis DateAndTime Enhancement http://code.google.com/p/pharo/issues/detail?id=3236 (No comment was entered for this change.)

Jan. 15, 2011

Re: [Pharo-project] DateAndTime millisecond is always 0

by StÃ©phane Ducasse

so simple you see if people wants to get that in pharo - get a changeset out of the text - check in cuis if there are other changes - tests? Stef On Jan 15, 2011, at 9:50 AM, Adrian Lienhard wrote: > On Jan 15, 2011, at 09:21 , StÃ©phane Ducasse wrote: > >> >> On Jan 14, 2011, at 11:24 AM, Denis Kudriashov wrote: >> >>> Sorry, >>> >>> I meen DateAndTime now millisecond and DateAndTime now nanoSecond. >>> >>> As I write in last mail. I found cuis fix of this in Pharo issues >> >> >> where? > > Denis sent a link to the issue in question in a previous mail in this thread: > > http://code.google.com/p/pharo/issues/detail?id=3236 > > Adrian > > > __________________________ > www.adrian-lienhard.ch > twitter.com/adrianlienhard > >

Jan. 15, 2011

Re: [Pharo-project] DateAndTime millisecond is always 0

by StÃ©phane Ducasse

Thanks I could not see it ;/ Stef On Jan 15, 2011, at 9:50 AM, Adrian Lienhard wrote: > On Jan 15, 2011, at 09:21 , StÃ©phane Ducasse wrote: > >> >> On Jan 14, 2011, at 11:24 AM, Denis Kudriashov wrote: >> >>> Sorry, >>> >>> I meen DateAndTime now millisecond and DateAndTime now nanoSecond. >>> >>> As I write in last mail. I found cuis fix of this in Pharo issues >> >> >> where? > > Denis sent a link to the issue in question in a previous mail in this thread: > > http://code.google.com/p/pharo/issues/detail?id=3236 > > Adrian > > > __________________________ > www.adrian-lienhard.ch > twitter.com/adrianlienhard > >

Jan. 15, 2011

Re: [Pharo-project] we will start 1.3 really soon

by Adrian Lienhard

Cool :) BTW, I have a question related to 1.2 from a user's perspective: could we generate a summary to help people migrate from 1.1.1 to 1.2? In particular, the question is which changes in 1.2 are not backwards compatible and may break my code? I've been a bit out of the loop during the last months... so at least for me this is not obvious ;). There's http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotTwo but it doesn't tell the important bits. Cheers, Adrian On Jan 15, 2011, at 09:27 , StÃ©phane Ducasse wrote: > Hi guys > > there are some minors fixes to be addressed (like the preferences use in dev) but we will go 1.3 probably this evening and > we will start to harvest a large list of pending issues. If you have seen fixes in squeak that you think are good please add a bug entry. > After that we will plan for the big changes in 1.3 for me > I would like to see > - collection enh (finishing hashed collection) > - weak structure support > - announcement using weak structure > - file system use > - new package implementation (cyrille worked and will continue to really make sure everything works) > - real beta of OPAL > The goal is to have a release for 1.3 by June/July. > > Stef >

Jan. 15, 2011

Re: [Pharo-project] new Cog VMs

by Philippe Marschall

On 10.01.2011 01:28, Eliot Miranda wrote: > Hi All, > > find new VMs in VM.r2344/ > <http://www.mirandabanda.org/files/Cog/VM/VM.r2344/> (SimpleStackBasedCogit) > and VM.r2345/ > <http://www.mirandabanda.org/files/Cog/VM/VM.r2345/> (StackToRegisterMappingCogit) > and VMMaker-oscog-45. These fix a bug that could cause crashes when > converting an interpreted method to a machine-code method on backward > branch (i.e. when the Vm detects an interpreted method is looping). > > I hope there are no new issues with VM.r2344/ > <http://www.mirandabanda.org/files/Cog/VM/VM.r2344/> (SimpleStackBasedCogit). > However, Matthew Fulmer has found that on linux the VM.r2343/ > <http://www.mirandabanda.org/files/Cog/VM/VM.r2343/> VM.r2345/ > <http://www.mirandabanda.org/files/Cog/VM/VM.r2345/> (StackToRegisterMappingCogit) > VMs crash immediately loading Squeak4.2-10856-beta.image. I can > reproduce this but haven't had time to investigate. > The StackToRegisterMappingCogit VMs do start up this image on Mac and > Windows. > > Agan thanks for pounding on these. I may not be able to attend to the > linux/StackToRegisterMappingCogit/Squeak4.2-10856-beta.image until next > weekend. Apologies. r2346 fixes the issues I sometimes had with when the stack would be messed up the first time a method is executed. Cheers Philippe

Jan. 15, 2011

Re: [Pharo-project] [Pharo-users] Where do I find KeyedSet?

by HernÃ¡n Morales Durand

Hi Stef 2011/1/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Jan 14, 2011, at 6:24 PM, HernÃ¡n Morales Durand wrote: > >> Try PluggableSet >> >> http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg22890.ht… >> >> Is there a way for you guys to deprecate deleted classes or mantain a >> record of deleted behaviors? (IIRC VW did this from 2.x versions) > > We try but we do not have the engineers of VW. > Now find somebody that pay us just 3 engineers full time for two years and you will not > recognized pharo and its process. I know we are very few, but what about this idea, instead of just deleting a class we may adopt these simple rules: 1 - If deleting a class add the deleted class name somewhere (in a method?) 2 - If renaming a class, make the class to know its previous names like #previousNames (Norberto Manzanos implemented this for his own package management and I think is a great idea) doesn't require tools, just some consensus and maybe a modified #deleteClass to enforce this "policy" it sounds feasible for you? what do you think? HernÃ¡n

Jan. 15, 2011