March 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3820 in pharo: TextConstants change to SharedPool breaks external code using at: message

by pharo＠googlecode.com

Status: Accepted Owner: miguel.c...(a)gmail.com Labels: Milestone-1.2.1 Milestone-1.3 New issue 3820 by miguel.c...(a)gmail.com: TextConstants change to SharedPool breaks external code using at: message http://code.google.com/p/pharo/issues/detail?id=3820 If you fill an issue for the first time, please read "How to report bugs" at http://www.pharo-project.org/community/issue-tracking Pharo image: Core 1.2, Hudson build 228 Pharo core version: #12341 Virtual machine used: 4.0.3-2202 #1 XShm Tue Apr 13 11:56:47 PDT 2010 gcc 4.3.2 The change of TextConstants from a Dictionary to a SharedPool in #3247 breaks external code like Magma that uses the message at: to access the values stored in it and that SharedPool doesn't implement. Henrik Sperre Johansen proposed the followin fix for backwards compatibility: category: 'backwards compatability' at: aSymbol ^self classPool at: aSymbol at: aSymbol put: aValue ^self deprecated: 'TextConstants is not a place to store your stuff' on: '15 March 2011' in: 'Pharo1.2' Attached the changeset with the code for integration in 1.2.1 and 1.3 Attachments: TextConstants.1.cs 1.2 KB

March 15, 2011

Re: [Pharo-project] Pharogenesis anew

by Lukas Renggli

> I'll defenitely try to come up with something to access github soon. It will probably not use OB though because that's just too much of a hack. Especially because it effectively disables the version browser for changes files. You really don't need to hack OB: Why don't you just add a completely new command (the complete refactoring infrastructure was added that way and can be optionally loaded and unloaded) and let the Git history live aside of the traditional versioning functionality? Lukas -- Lukas Renggli www.lukas-renggli.ch

March 15, 2011

Re: [Pharo-project] Issue 958 in pharo: Adding Iterable to Pharo

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #10 on issue 958 by marcus.d...(a)gmail.com: Adding Iterable to Pharo http://code.google.com/p/pharo/issues/detail?id=958 (No comment was entered for this change.)

March 15, 2011

Re: [Pharo-project] Issue 825 in pharo: Some changes are not save to the changes file

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #8 on issue 825 by marcus.d...(a)gmail.com: Some changes are not save to the changes file http://code.google.com/p/pharo/issues/detail?id=825 (No comment was entered for this change.)

March 15, 2011

Re: [Pharo-project] Issue 709 in pharo: Debugger highlight bug

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #18 on issue 709 by marcus.d...(a)gmail.com: Debugger highlight bug http://code.google.com/p/pharo/issues/detail?id=709 (No comment was entered for this change.)

March 15, 2011

Re: [Pharo-project] Issue 3629 in pharo: [Hudson] Update Hudson

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3629 by marcus.d...(a)gmail.com: [Hudson] Update Hudson http://code.google.com/p/pharo/issues/detail?id=3629 will be done by admins soon... (I hope)

March 15, 2011

Re: [Pharo-project] Issue 1386 in pharo: moving methods from one category to another has trouble on the last item

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 1386 by marcus.d...(a)gmail.com: moving methods from one category to another has trouble on the last item http://code.google.com/p/pharo/issues/detail?id=1386 Seems to work on 1.2. Please check and add a new report if this is still a problem

March 15, 2011

Re: [Pharo-project] Issue 1427 in pharo: relative FileUrl's don't work on OSX and Linux

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 1427 by marcus.d...(a)gmail.com: relative FileUrl's don't work on OSX and Linux http://code.google.com/p/pharo/issues/detail?id=1427 This was fixed some time ago.

March 15, 2011

Re: [Pharo-project] Issue 3247 breaks external packages

by StÃ©phane Ducasse

On Mar 15, 2011, at 5:39 PM, Miguel CobÃ¡ wrote: > El mar, 15-03-2011 a las 09:07 +0100, StÃ©phane Ducasse escribiÃ³: >> On Mar 15, 2011, at 5:58 AM, Miguel CobÃ¡ wrote: >> >>> I am trying to run Magma and uses TextConstants at: idiom. >>> >>> Before 3247 TextConstants was a Dictionary and the at: message works ok. >>> But now that it is a SharedPool there is no way to use the external code >>> without modify it before it works in Pharo 1.2. This change doesn't even >>> tries to present the same interface to acces the Text constants as >>> before. The TextConstants>>at: message in Pharo 1.2 is the Object>>at: >>> method that obviously doesn't work. >> >> How could we do that? >> If the system badly uses a global variable in all sort of different ways then >> there is no way that we can propose the same interface. >> > > Ok, I understand that, but also it was known that it would break code. > This is also understandable. and a price to pay to have this system > going forward. My point is the change was made, and no care for the > users was made in either: > > - stating somewhere (maybe the list, a wiki, a faq) the consequences of > this change and the advantages over the old code. We are trying but it can take a lot of time to explain all the cruft that we face. > - a way to migrate old code to the new code. > > This, at least for someone that has never used shared pools, isn't > obvious. The issue tracker says something about importing the shared > pool in the class using it so it can access its values. But there are > package extensions that add methods to other classes that use > TextConstants, how is one to work out this case, adding TextConstant > sharedpool to the class (array in the case of magma that is augmented by > a couple of methods that uses TextConstants) > >> Then TextConstants had different and bad use: >> - storing constants >> - storing volatile information about fonts and all sorts of registrations for fonts!!! in textConstants >> "oh yes this is the dictionary so lets us mess there" >> instead of using adequate classVariables in adequate classes (we should still clean this part). >> TextSharedInformation below is for the moment containing all the crap. >> > > I understand. > >>> What is the reason of this change? Why is better than the dictionary (I >>> suppose that reifying it is a reason)? >> >> >> because TextConstants was the **last** global pool and it was like a jellyfish. >> In fact when SharedPool were introduced by andreas (it was a good idea BTW) >> TextConstants was left because it was touching a lot of code. >> > > Exactly, and this change let a lot of code in the cold without warning > or a migration path. So far this is the only impact with the problem reported by doru for fonts. > Yes, I now, but this means that all the code using the at: message in > TextConstants is broken in the new Pharo1.2. I do not get the previous statements. All the system got recompiled and fixed. > Maybe this hasn't been > noted (at least for me it hasn't) because PharoCore 1.2 wasn't stable > but now that is stable people will try to load code that uses > TextConstants and if uses the at: message it won't work. > > Don't get me wrong. I am for the progress of Pharo and this change is in > that direction but it appears to me that was without notice this was not without notice. it was mentioned in the log (probably not a lot but it took us some times and a lot of try and error before making it public). > and without > a deprecation warning akin to the method deprecation. This was released > to the world without time for package to catch up and prepare either a > patch to the code or a PharoCompatibility package that copes with usage > of TextConstants. There are situation where we cannot simply deprecate code. > > >> >> Now I do not really understand why a database has to change that kind of text information. >> > > I don't know either because I'm not expert on magma but that is besides > the point. > > Now what I will do is to add (after consulting with Chris) a Pharo > specific package to magma, or if that isn't possible, an add-on in > PharoTaskForces that is loaded after magma packages and overwrites the > methods using TextConstants with the Pharo specific shared pool > implementation. This I suppose will dirty the Magma package and I don't > like it so much. > > So, dear Magma on Pharo users, the ConfigurationOfMagma isn't usable > yet. Please wait a couple of days more. :/ > > > Cheers > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > >

March 15, 2011

Re: [Pharo-project] Issue 1086 in pharo: Defect in focusing morphic region

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 1086 by marcus.d...(a)gmail.com: Defect in focusing morphic region http://code.google.com/p/pharo/issues/detail?id=1086 Please check in the latest 1.2 if this problem is there, I close this report for now.

March 15, 2011