- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.3] #13131

by StÃ©phane Ducasse

13131 ----- - Issue 3949: Coverage for Cog. Thanks Lukas Renggli. - Issue 3947: remove #floodFill:. Thanks Marcus Denker. - Issue 3946: remove some more uniclasses/player related code. Thanks Marcus Denker. - Issue 3945: Remove squeakland plugin methods from SystemVersion. Thanks Marcus Denker. - Issue 3944: ClassHierarchyTest needs to be moved to KernelTests package. Thanks Marcus Denker. - Removed SoftSqueak Theme. Repackage GLMTheme - Rename them. Stef

April 3, 2011

Re: [Pharo-project] Issue 3944 in pharo: ClassHierarchyTest needs to be moved to KernelTests package

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3944 by stephane...(a)gmail.com: ClassHierarchyTest needs to be moved to KernelTests package http://code.google.com/p/pharo/issues/detail?id=3944 in 13131

April 3, 2011

Re: [Pharo-project] Issue 3945 in pharo: Remove squeakland plugin methods from SystemVersion

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3945 by stephane...(a)gmail.com: Remove squeakland plugin methods from SystemVersion http://code.google.com/p/pharo/issues/detail?id=3945 in 13131

April 3, 2011

Re: [Pharo-project] Issue 3946 in pharo: remove some more uniclasses/player related code

by pharo＠googlecode.com

Updates: Status: closed Comment #3 on issue 3946 by stephane...(a)gmail.com: remove some more uniclasses/player related code http://code.google.com/p/pharo/issues/detail?id=3946 (No comment was entered for this change.)

April 3, 2011

Re: [Pharo-project] Issue 3946 in pharo: remove some more uniclasses/player related code

by pharo＠googlecode.com

Comment #2 on issue 3946 by stephane...(a)gmail.com: remove some more uniclasses/player related code http://code.google.com/p/pharo/issues/detail?id=3946 in 13131

April 3, 2011

Re: [Pharo-project] Issue 3946 in pharo: remove some more uniclasses/player related code

by pharo＠googlecode.com

Comment #1 on issue 3946 by stephane...(a)gmail.com: remove some more uniclasses/player related code http://code.google.com/p/pharo/issues/detail?id=3946 Argh! Terrible design.... "add yours to the list" no comment.

April 3, 2011

Re: [Pharo-project] Issue 3947 in pharo: remove #floodFill:

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3947 by stephane...(a)gmail.com: remove #floodFill: http://code.google.com/p/pharo/issues/detail?id=3947 in 13131

April 3, 2011

Re: [Pharo-project] Issue 3949 in pharo: Coverage for Cog

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3949 by stephane...(a)gmail.com: Coverage for Cog http://code.google.com/p/pharo/issues/detail?id=3949 Tx lukas in 12131

April 3, 2011

Re: [Pharo-project] Let's get rid of Core vs. Full

by StÃ©phane Ducasse

On Apr 3, 2011, at 9:34 PM, HernÃ¡n Morales Durand wrote: > I really agree with you Marcus. It sounds to me that core/dev is a > black and white approach. > > I know there are no resources, but what do you think of starting with > a minimum image and the build over more sophisticated images? > > -Kernel image > -Core image > -Image with really basic browsing/scm tools (OB, Script Manager, > Shout, etc) - or "developer basic" > -developer standard (the current dev) > -developer scientific > -developer web > ... > etc. > > that wouldn't result in more easier integrations? I'm not sure that you want a lot of different setups because it means checking problems due to interactions. So far we cannot maintain 2 so I do not see why more would help. a core + packages + a dsitribution browser to load certified distributions we want a mini-core + a set of maintained pharo packages + a configuration files When we work on them -> new mini core + automatic publication of new packages + new configuration files Right now this process does not work so this is a ***pain*** I spent 2 hours one sunday to fix some stupid problem with shout in OB just because we do not have good tools on top of metacello and because loading packages is slow. Stef

April 3, 2011

Re: [Pharo-project] Announcement real problems - please read and comment.

by Henrik Sperre Johansen

On 03.04.2011 10:35, StÃ©phane Ducasse wrote: > On Apr 2, 2011, at 5:14 PM, Henrik Sperre Johansen wrote: > >> On 02.04.2011 09:16, StÃ©phane Ducasse wrote: >>> Henrik what is your answer to problem 1 >>> >>> Problem 1 >>> - the second announcement was never sent, because the first one broke the second was blocked. >>> >> we should make sure that if an announcement leads to an error, other annoucements on the same emit should pass >>> >>> Because we can get the system down just because one guy can register a bug. >> http://forum.world.st/Another-finalization-concern-error-handling-td2989615… >> >> It's basically the same. > ?? Same basic problem, same solutions apply. I'd rather not repeat the exact same discussion. Just exchange "finalization" with "announcement delivery" when reading the thread. Cheers, Henry

April 3, 2011