- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3501 in pharo: Remove 1.1 deprecated methods and publish them in a separate package

by pharo＠googlecode.com

Updates: Status: Closed Comment #5 on issue 3501 by stephane...(a)gmail.com: Remove 1.1 deprecated methods and publish them in a separate package http://code.google.com/p/pharo/issues/detail?id=3501 (No comment was entered for this change.)

Jan. 21, 2011

[Pharo-project] [update 1.3] #13013

by StÃ©phane Ducasse

13013 ----- - Categorization of deprecated methods.

Jan. 21, 2011

[Pharo-project] Issue 3569 in pharo: Error logging cleanup

by pharo＠googlecode.com

Status: Started Owner: siguc...(a)gmail.com New issue 3569 by siguc...(a)gmail.com: Error logging cleanup http://code.google.com/p/pharo/issues/detail?id=3569 Not best, but little better than before. - remove repetitive use of 'PharoDebug.log' all over the places. Now Debugger have #logFileName and keeps name in class var (should expose it in settings later). - deprecated #logError:inContext:to: , one should use #logError:inContext: instead. Attachments: DebuggerLog.3.cs 12.1 KB

Jan. 21, 2011

[Pharo-project] PharoSound

by Henrik Sperre Johansen

Hi Mariano & all! About the changes in 3489 and 3566 earlier today, I think there were some misunderstandings. The changes I made in 3566 is to PharoCore, and are intended to work with the Sound package in http://www.squeaksource.com/PharoSound. It moves the settings stored in SoundSettings to SoundService + ThemeSounds, which are more localized places for them. This makes sense by itself, but also because that's where they (well, only soundEnabled) are likely to be found if refactored to use preference pragmas in Squeak. Because the package in PharoSound has the Squeak trunk Sound package as ancestor as well, it's easy to synch up changes from it. (AFAIK the one in NonCorePackages does not). I feel this is important, since Sound does not really receive a lot of attention in Pharo, and efforts in Squeak should be as easy to integrate as possible. Thus, I'd really appreciate it if the ConfigurationOfSound could be changed to use this repository as the primary source. Cheers, Henry

Jan. 21, 2011

Re: [Pharo-project] Adding settings to an existing group

by Henrik Sperre Johansen

On 21.01.2011 17:33, Alain Plantec wrote: > ----------------- > quickStartSoundSettingOn: aBuilder > <systemsettings> > (aBuilder setting: #soundQuickStart) > parent: #soundEnabled; > label: 'Play sounds immediately if possible' translated; > target: SoundPlayer > -------------- > > should do it if you have > SoundPlayer class>>soundQuickStart > SoundPlayer class>>soundQuickStart: aBoolean > Yeah, I found parent: after awhile :D Must have added it to instance side, and that's why it didn't show up in the settings browser... *blush* > btw: > why this setting ? > If sound is enabled, why would I set this setting to false ? > I guess one always want the sound to start as quick as possible. > > Cheers > Alain Eeeeh, well... I'm not too familiar with the sound package, but it ends up calling a primitive instead of scheduling the sound. There's code there to schedule instead if the primitive fails, so my guess is it caused crashes some time in the past and a manual method was needed to disable it. I'll could update the comment to "Turn this off if your VM crashes when playing sound", but I have no idea if that's actually the intended case. :) Cheers, Henry

Jan. 21, 2011

Re: [Pharo-project] Issue 3566 in pharo: Changes needed to update Sound for 1.2

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.2-DevImage Milestone-1.2 Milestone-1.3 Comment #6 on issue 3566 by ryd...(a)gmail.com: Changes needed to update Sound for 1.2 http://code.google.com/p/pharo/issues/detail?id=3566 These are core changes needed for the external package, not DevImage specific changes.

Jan. 21, 2011

Re: [Pharo-project] Adding settings to an existing group

by Alain Plantec

----------------- quickStartSoundSettingOn: aBuilder <systemsettings> (aBuilder setting: #soundQuickStart) parent: #soundEnabled; label: 'Play sounds immediately if possible' translated; target: SoundPlayer -------------- should do it if you have SoundPlayer class>>soundQuickStart SoundPlayer class>>soundQuickStart: aBoolean btw: why this setting ? If sound is enabled, why would I set this setting to false ? I guess one always want the sound to start as quick as possible. Cheers Alain Le 21/01/2011 16:06, Henrik Sperre Johansen a Ã©crit : > Sorry I haven't really had time to learn the settings framework yet, > does anyone know how to do this? > > Updating the Sound package, I'd like to add a few to the existing > category Appearance -> sound (strange place for it, btw...) in a package > one can load from the repository. > > I tried code like: > > quickStartSoundSettingOn: aBuilder > <systemsettings> > (aBuilder group: #appearance) with: [ > (aBuilder setting: #soundEnabled) with: [ > (aBuilder setting: #soundQuickStart) > label: 'Play sounds immediately if possible'; > target: SoundPlayer; > targetSelector: #soundQuickStart]] > > but that's apparently far off the mark... > > Cheers, > Henry > >

Jan. 21, 2011

Re: [Pharo-project] Issue 3440 in pharo: Cycle in Monticello removed

by pharo＠googlecode.com

Updates: Status: Closed Comment #4 on issue 3440 by stephane...(a)gmail.com: Cycle in Monticello removed http://code.google.com/p/pharo/issues/detail?id=3440 integrated in 13012

Jan. 21, 2011

Re: [Pharo-project] OB failing tests in Pharo 1.2

by Lukas Renggli

On Friday, 21 January 2011, Tudor Girba <tudor.girba(a)gmail.com> wrote: > That is not very encouraging :) Indeed. Probably somebody can figure out a patch that fixes some more of the regressions. But this will never fix the problem that the code builds on top of the old infrastructure delegating to the new infrastructure. Some time ago I started to reimplement the OB editor on top of the new editor, but that is just the first day of work of the estimated week: source.lukas-renggli.ch/pharo12. Lukas > > Cheers, > Doru > > > On 21 Jan 2011, at 15:43, Lukas Renggli wrote: > >>> Hi Lukas. I was checking the 4 failing tests in Pharo 1.2: >>> http://code.google.com/p/pharo/issues/detail?id=3470 >>> >>> The problem seems related to the changes with the >>> SmalltalkEditor/ParagraphEditor and friends. The tests fails because the >>> instVar "message" is nil, because nobody call OBKeyBindingsTest >> browseIt: >>> aSelector >>> nor its friends. This was called in Pharo 1.1 from OBTextMorphEditor >>> because it was a subclass of ParagraphEditor. >>> >>> Now, I have no idea how to make it work in Pharo 1.2 >> >> Yeah, me neither. OB-Morphic is totally broken and it cannot be >> quickly fixed. The editor support has to be completely rewritten on >> top of the new infrastructure to get a browser that properly works. >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > -- > www.tudorgirba.com > > "Next time you see your life passing by, say 'hi' and get to know her." > > > > > -- Lukas Renggli www.lukas-renggli.ch

Jan. 21, 2011

Re: [Pharo-project] Issue 3440 in pharo: Cycle in Monticello removed

by pharo＠googlecode.com

Comment #3 on issue 3440 by stephane...(a)gmail.com: Cycle in Monticello removed http://code.google.com/p/pharo/issues/detail?id=3440 the version you used does not contain the changes made in October!!!!! Please always used the latest version to propose fix

Jan. 21, 2011