January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Collection new

by Schwab,Wilhelm K

Go easy on the newbies, ok? :) We were all there once... It's been YEARS, but I recall being completely lost with collections and "which ones to use and how." You are indeed correct about non-newbs needing to make sure that any errors are gracefully presented vs. taking out the vm. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Andrew P. Black [black(a)cs.pdx.edu] Sent: Monday, January 30, 2012 1:31 PM To: Pharo Project Subject: [Pharo-project] Collection new Teaching a class of novices, it's not surprising that someone tried "Collection new". What was surprising is that this got the VM is a loop of some kind, with emergency stack dumps and so on. Here is my reply: > On 30 Jan 2012, at 01:18 , Xingzhi Harry Pan wrote: > >> ...it's pretty innocent: >> Collection new > > > OK. I looked at this. The problem comes when trying to print the collection. Somehow the VM gets confused when trying to do do: ... I'm not quite clear why. > > The quick fix is to change the Collection>>new method to > > self error: 'Collection is an abstract class, and cannot be instantiated' > > However this will break Heap>>new: , which sends super new. It ought to send self basicNew instead. > > These two changes seem to avoid the problem, but I'm waiting to see ... > > Andrew But I don't understand the root cause. Printing eventually sends do:, which is self subclassResponsibility. Why don't we get a clean failure? Andrew

Jan. 30, 2012

Re: [Pharo-project] PseudoContext?

by Eliot Miranda

On Mon, Jan 30, 2012 at 11:47 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > > > > > Also think of getting rid of TranslatedMethod > > yes we already did that one > > > and BlockContext if you haven't already. > > it is deprecated > > > Also, collapsing ContextPart and MethodContext onto just Context (or > ActivationContext (?)) would be nice. > > Thanks for the suggestion I will do it. What is the best choice to avoid > incompatibility? Having MethodContext I guess. > Yes. But it is perhaps worth making the change incompatible to say goodbye to BlockContext? One can always do Smalltalk at: #MethodContext put: ActivationContext to get older packages to load. I don't know what's best, but for once I like the clean-up :) > > Stef > -- best, Eliot

Jan. 30, 2012

Re: [Pharo-project] [update 1.4] #14298

by StÃ©phane Ducasse

thanks! On Jan 30, 2012, at 10:00 PM, Marcus Denker wrote: > > On Jan 30, 2012, at 4:52 PM, StÃ©phane Ducasse wrote: > >> >> On Jan 30, 2012, at 1:31 PM, Camillo Bruni wrote: >> >>> I'll check again :) >>> >>> sorry I was unaware of the side-effects :D > > > Works now... I added Camillo's fix as a changeset to the stream as 14299. > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > >

Jan. 30, 2012

Re: [Pharo-project] [update 1.4] #14298

by Marcus Denker

On Jan 30, 2012, at 4:52 PM, StÃ©phane Ducasse wrote: > > On Jan 30, 2012, at 1:31 PM, Camillo Bruni wrote: > >> I'll check again :) >> >> sorry I was unaware of the side-effects :D Works now... I added Camillo's fix as a changeset to the stream as 14299. Marcus -- Marcus Denker -- http://marcusdenker.de

Jan. 30, 2012

Re: [Pharo-project] [update 1.4] #14298

by Sven Van Caekenberghe

On 30 Jan 2012, at 20:52, StÃ©phane Ducasse wrote: > > On Jan 30, 2012, at 1:31 PM, Camillo Bruni wrote: > >> I'll check again :) >> >> sorry I was unaware of the side-effects :D > > where is Ulyss? > O_o > > Stef :) Was he not some mythical, heroic figure with infinite power ? >> >> best >> cami >> >> On 2012-01-30, at 13:13, Sven Van Caekenberghe wrote: >> >>> >>> On 30 Jan 2012, at 12:36, Marcus Denker wrote: >>> >>>> This needs to be reverted: >>>> >>>> http://code.google.com/p/pharo/issues/detail?id=5222 >>>> >>>> So a .cs that either fixes it or reverts the change would help... I can look at reverting it the evening. >>> >>> If you revert MCCacheRepository>>#basicStoreVersion: and MCFileBasedRepository>>#notifyList to their previoius versions it works again. >>> To clean up, #includesFileNamed: should be removed as well. >>> >>> This is really a pity: it did make a noticeable difference. >>> >>> I looked a bit at the code and I can't figure out why this does not work as expected. >>> >>> Please, Camillo, please, it would be a shame to let improvements like this get lost. >>> >>> Sven >> >> > >

Jan. 30, 2012

Re: [Pharo-project] OneClick on website's first page?

by Norbert Hartl

Am 30.01.2012 um 18:16 schrieb Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: > S, Norbert Hartl piÅ¡e: > >>> My intention was dragged into downloads of Shortcuts section and I'm >>> also blind to "marketing" images outside the central area, this is >>> probably a reason :) But it is only me? >> >> yes! > > Are you sure? :) > Sure! :) Norbert

Jan. 30, 2012

Re: [Pharo-project] pharo vision

by Igor Stasenko

On 30 January 2012 18:06, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 30 January 2012 15:34, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 30 January 2012 16:17, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> Thanks Steph! This is much-needed to focus our community and avoid >>> unnecessary confusion and chatter. >>> >>> A few minor edits to Ch. 1: >>> pg. 1 >>> Â Â Â Â "curved in stone" should be carved >> >> No. It is now part of history. It is curved, not carved. >> There was a postings in mailing list somewhere, discussing that :)) > > Sean's right. There is no English idiom like "curved in stone". > "Curved in stone" makes no sense. > Let me turn it like that: it makes sense exactly because it doesn't makes sense. This idiom were invented by Stephane, and part of our history now :) > frank > >>> pg. 4 >>> Â Â Â Â * "based on an integreation server" should be integration >>> Â Â Â Â * "test them and notify its results" should be "tests them and notifies its >>> results" >>> Â Â Â Â * "We will also put in place another level of checks based on integration >>> servers as well." -> To me this sentence adds nothing. Either explain more >>> or remove it. >>> Â Â Â Â * "We will not do that for the sake of changing." I think you mean "We will >>> not change for the sake of change." >>> Â Â Â Â * "expressing in a more com- pact form all kind of information" would be >>> more clear as "expressing all kinds of information in a more compact form" >>> Â Â Â Â * "optimization at compiler level" -> "optimization at the compiler level" >>> Â Â Â Â * "Not only we want that people build" -> "Not only do we want people >>> build" >>> pg. 5 >>> Â Â Â Â * "We want that both users and the system general quality, benefit from the >>> best libraries." -> "We want both users and the general quality of the >>> system to benefit from the best libraries." >>> Â Â Â Â * "we want to have validated packages running check rules and automated >>> tests automatically validated." is unclear, but I don't understand it well >>> enough to change it >>> Â Â Â Â * "*a* good interaction with the rest of the world" should be "good >>> interaction with the rest of the world" >>> Â Â Â Â * "The list *if* not exhaustive but should allow *one* to structure the >>> development effort." -> "The list is not exhaustive but should allow us to >>> structure the development effort." >>> Â Â Â Â * "New IDES" -> "New IDEs" >>> Â Â Â Â * "but also new *way* of handling" -> "but also new ways of handling" >>> Â Â Â Â * "of new *kind* of IDEs, desktop metaphor and" -> "of new kinds of IDEs, >>> desktop metaphor and:" (added colon at end, subsequent bullets are children) >>> pg. 6 >>> Â Â Â Â * "proved that it was worth." Sentence fragment, I'm not clear enough to >>> fix it >>> Â Â Â Â * "and complex *applications*" -> "and complex application" >>> Â Â Â Â * "Obviously everybody prefer to use a fast library than a slow one. We >>> should develop rule checking that include speed regression testing." -> >>> "Obviously everybody prefers using a fast library over a slow one. We should >>> develop rule checking that includes speed regression testing." >>> Â Â Â Â * "64 bits. For managing large amount of data" -> "64 bits. For managing a >>> large amount of data" >>> Â Â Â Â * "Even if theoretically with a 32 bits VM we should be able to run images >>> of at least 2 GBs, this is not the case of current available VMs. For >>> example, the Windows VM does not support images bigger than 512 MB." -> >>> "Although a 32 bit VM can theoretically run images of up to 2 GB, the >>> currently available VMs are more limited. For example, the Windows VM does >>> not support images bigger than 512 MB." >>> pg. 7 >>> Â Â Â Â * "Large applications" section is repeated >>> Â Â Â Â * "OpenSophie proved that Smalltalk and Squeak in particular, the ancestor >>> of Pharo, are good platforms for building advanced multimedia applications. >>> We believe that Pharo can be used in such situation." -> "OpenSophie proved >>> that Smalltalk, and Squeak (Pharo's ancestor) in particular, are good >>> platforms for building advanced multimedia applications. We believe that >>> Pharo is well-suited for this." >>> >>> Sean >>> >>> -- >>> View this message in context: http://forum.world.st/pharo-vision-tp4340345p4341249.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Jan. 30, 2012

Re: [Pharo-project] [update 1.4] #14298

by StÃ©phane Ducasse

On Jan 30, 2012, at 1:31 PM, Camillo Bruni wrote: > I'll check again :) > > sorry I was unaware of the side-effects :D where is Ulyss? O_o Stef :) > > best > cami > > On 2012-01-30, at 13:13, Sven Van Caekenberghe wrote: > >> >> On 30 Jan 2012, at 12:36, Marcus Denker wrote: >> >>> This needs to be reverted: >>> >>> http://code.google.com/p/pharo/issues/detail?id=5222 >>> >>> So a .cs that either fixes it or reverts the change would help... I can look at reverting it the evening. >> >> If you revert MCCacheRepository>>#basicStoreVersion: and MCFileBasedRepository>>#notifyList to their previoius versions it works again. >> To clean up, #includesFileNamed: should be removed as well. >> >> This is really a pity: it did make a noticeable difference. >> >> I looked a bit at the code and I can't figure out why this does not work as expected. >> >> Please, Camillo, please, it would be a shame to let improvements like this get lost. >> >> Sven > >

Jan. 30, 2012

Re: [Pharo-project] small display in the image with condensed changes

by StÃ©phane Ducasse

On Jan 30, 2012, at 1:43 PM, Pavel Krivanek wrote: > Hi, > > I tried the latest image with condensed changes from the CI server > (https://ci.lille.inria.fr/pharo/view/Pharo%201.4/job/Pharo%201.4%20condense…) > and when I open the image, it has very small display size, something > like 12x12 pixels. The standard 1.4 image has normal display extent. > Can you confirm that on other systems and VMs? > > Btw. Stef or Marcus, can you separe ThreadSafeTranscript to a > standalone package. There was enough messages about Pharo-Kernel job > failures :-) yes there is a bug entry. Now I cannot integrate fix anymore :) > > Cheers, > -- Pavel >

Jan. 30, 2012

Re: [Pharo-project] PseudoContext?

by StÃ©phane Ducasse

> > > Also think of getting rid of TranslatedMethod yes we already did that one > and BlockContext if you haven't already. it is deprecated > Also, collapsing ContextPart and MethodContext onto just Context (or ActivationContext (?)) would be nice. Thanks for the suggestion I will do it. What is the best choice to avoid incompatibility? Having MethodContext I guess. Stef

Jan. 30, 2012