- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.3] #13027

by StÃ©phane Ducasse

13027 ----- - Deprecate Object>>notifyWithLabel: - Issue 3618: logError: aString inContext: aContext to: is used and it is deprecated Stef

Jan. 29, 2011

Re: [Pharo-project] Issue 3618 in pharo: logError: aString inContext: aContext to: is used and it is deprecated

by pharo＠googlecode.com

Comment #3 on issue 3618 by stephane...(a)gmail.com: logError: aString inContext: aContext to: is used and it is deprecated http://code.google.com/p/pharo/issues/detail?id=3618 in fact it did not make it in. So fixed in 12027 (strange). Too many people talking around probably.

Jan. 29, 2011

Re: [Pharo-project] Issue 3618 in pharo: logError: aString inContext: aContext to: is used and it is deprecated

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3618 by stephane...(a)gmail.com: logError: aString inContext: aContext to: is used and it is deprecated http://code.google.com/p/pharo/issues/detail?id=3618 Normally we fixed that yesterday in 13025 Let us know if this is not the case

Jan. 29, 2011

Re: [Pharo-project] Issue 3620 in pharo: Settings: OCompletion settings appear twice

by StÃ©phane Ducasse

But why the UI collects the squeak preferences? >> Comment #1 on issue 3620 by laurent....(a)gmail.com: Settings: OCompletion settings appear twice >> http://code.google.com/p/pharo/issues/detail?id=3620 >> >> Fix (naive) here: SLICE-Issue-3620-Settings-OCompletion-settings-appear-twice-LaurentLaffont.1 >> >> > > The actual problem is that SettingsBrowser is showing Squeak's pragma preferences as Pharo's system settings. See SettingTreeBuilder >> #preference:category:description:type: for the implementation. > > I see three possible scenarios to resolve this issue: > 1. Your fix will be accepted (which implies that OCompletion will be forked). > 2. We remove ECPreferences class >> #settingsOn: from OCompletion. > 3. You remove SettingTreeBuilder >> #preference:category:description:type: from Pharo. > > > Levente >

Jan. 29, 2011

Re: [Pharo-project] Uri vs. Url

by StÃ©phane Ducasse

I started to go over all the methods and tests + added comments. Now I would like to see URI really used. But I need also help. Stef On Jan 29, 2011, at 9:37 AM, Marcus Denker wrote: > > On Jan 29, 2011, at 9:17 AM, DeNigris Sean wrote: > >> It confuses me that the URI and Url class hierarchies are separate, given that a URL is a subset of URI (http://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Relationship_to_UR…) Does it make sense to unify these? >> > > Hi, > > The history behind is the following. > > Impara implemented URI and used it for all their products and Sophie later. The idea was in 3.9 to integrate URI and then remove > Url later in another step. But sadly, already the first step was never really done: we integrated the URI package, but the (for 3.9)planed > second pass did never happen. (to replace Urls and just keep them for compatibility, together with syncing with sophie fixes). > > Wo should do another pass, yes. > > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

Jan. 29, 2011

Re: [Pharo-project] Issue 3536 in pharo: ZipArchive>>extractAllTo: leaves temporary directory on Mac

by pharo＠googlecode.com

Comment #1 on issue 3536 by sean.p.d...(a)gmail.com: ZipArchive>>extractAllTo: leaves temporary directory on Mac http://code.google.com/p/pharo/issues/detail?id=3536 Fix attached "Issue-3536-ZipArchive-leaves-temporary-directory-on-Mac-SeanDeNigris.cs". The problem was that Mac OS X adds metadata to archives. ZipArchive now skips those files and directories when extracting. Sean Attachments: Issue-3536-ZipArchive-leaves-temporary-directory-on-Mac-SeanDeNigris.cs 1.5 KB

Jan. 29, 2011

Re: [Pharo-project] Uri vs. Url

by Marcus Denker

On Jan 29, 2011, at 9:17 AM, DeNigris Sean wrote: > It confuses me that the URI and Url class hierarchies are separate, given that a URL is a subset of URI (http://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Relationship_to_UR…) Does it make sense to unify these? > Hi, The history behind is the following. Impara implemented URI and used it for all their products and Sophie later. The idea was in 3.9 to integrate URI and then remove Url later in another step. But sadly, already the first step was never really done: we integrated the URI package, but the (for 3.9)planed second pass did never happen. (to replace Urls and just keep them for compatibility, together with syncing with sophie fixes). Wo should do another pass, yes. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 29, 2011

Re: [Pharo-project] Issue 3612 in pharo: Full Image uses wrong Theme

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3612 by marcus.d...(a)gmail.com: Full Image uses wrong Theme http://code.google.com/p/pharo/issues/detail?id=3612 (No comment was entered for this change.)

Jan. 29, 2011

[Pharo-project] Uri vs. Url

by DeNigris Sean

It confuses me that the URI and Url class hierarchies are separate, given that a URL is a subset of URI (http://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Relationship_to_UR…) Does it make sense to unify these? Thanks. Sean

Jan. 29, 2011

Re: [Pharo-project] Issue 3620 in pharo: Settings: OCompletion settings appear twice

by Alain Plantec

Le 29/01/2011 00:16, Levente Uzonyi a Ã©crit : > On Fri, 28 Jan 2011, pharo(a)googlecode.com wrote: > >> >> Comment #1 on issue 3620 by laurent....(a)gmail.com: Settings: >> OCompletion settings appear twice >> http://code.google.com/p/pharo/issues/detail?id=3620 >> >> Fix (naive) here: >> SLICE-Issue-3620-Settings-OCompletion-settings-appear-twice-LaurentLaffont.1 >> >> > > The actual problem is that SettingsBrowser is showing Squeak's pragma > preferences as Pharo's system settings. See SettingTreeBuilder >> > #preference:category:description:type: for the implementation. > > I see three possible scenarios to resolve this issue: > 1. Your fix will be accepted (which implies that OCompletion will be > forked). > 2. We remove ECPreferences class >> #settingsOn: from OCompletion. > 3. You remove SettingTreeBuilder >> > #preference:category:description:type: from Pharo. 4. Maybe it's also possible to remove duplicated entries (so just a UI problem). Cheers Alain > > > Levente > >

Jan. 29, 2011