- Pharo-users - lists.pharo.org

Re: [Pharo-users] How to subclass Float class

by Hilaire

Le 11/01/2015 09:06, stepharo a Ã©crit : > Hilaire > > what is your requirement? > > Stef I want to create a currency object, basically a Float with an attribute to specify the currency unit. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Jan. 11, 2015

Re: [Pharo-users] Problem due to deprecation of class Url in Pharo 3 and Moose 5.0

by stepharo

>> Yes change the code of the Parser not to use old code. > As I pointed out, the Parser is a large and complex package, and I am not > the author, so this is easier said than done. I'm dealing daily with code having the same characteristics. > It seems a bit odd to dismiss > code which worked OK in Moose 4.9, but not in Moose 5.0, as 'old code.' I do not know what happened between 4.9 and 5.0 but if this is between pharo30 and pharo40 => one full year of efforts (you know many people improving things and putting energy in the system). And be ready because we will remove URL old class. Now the good aspect is that you are lucky (we are all lucky) that sven is improving constantly Zinc. But there is no such world were unmaintained packages would indefinitively work while the world is changing. > It > is code which has no functional equivalent in the new code, as Sven has > confirmed. Then it means that you have to cooperate with sven to get Zinc improved. And feel lucky you can. The overall process may look frustrating but a system that is not changing is See law of software evolution (1974) "Continuing Change" â an E-type system must be continually adapted or it becomes progressively less satisfactory[3] http://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution > > Thanks again > > Peter Kenny > > -----Original Message----- > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of > Sven Van Caekenberghe > Sent: 10 January 2015 16:36 > To: Any question about pharo is welcome > Subject: Re: [Pharo-users] Problem due to deprecation of class Url in Pharo > 3 and Moose 5.0 > > >> On 10 Jan 2015, at 16:45, stepharo <stepharo(a)free.fr> wrote: >> >> >> Le 10/1/15 11:41, PBKResearch a Ã©crit : >>> Hello >>> >>> I have run into a problem in moving some existing work from earlier > versions of Pharo/Moose. I have found a work around, but I wonder if there > is a tidier way of handling it. >>> >>> I make frequent use of Todd Blanchardâs HTML parser and validator, HTMCSS > (http://smalltalkhub.com/#!/~ToddBlanchard/HTMCSSValidatingParser) which > was originally written for Squeak but has performed without trouble on > earlier versions of Pharo. When I try to use it on Moose 5.0, I get frequent > warning messages about Url being deprecated. I have made the problem go away > by commenting out the deprecation warning in Url class>>new, but I wonder > what should be done on a more permanent basis. >> Yes change the code of the Parser not to use old code. >>> The problem arises because HTMCSS does not just parse the original HTML > file; it also loads and parses any referenced CSS files. (This is a function > I could do without, but I donât fancy trying surgery on a complex package > where I only partly understand the workings!) It constructs the full address > of the CSS file by combining the root address of the HTML with the relative > address of the CSS, using Url class>>combine:withRelative:, and in the > course of this it invokes Url class>>new; hence the deprecation message. >> use ZnURL >>> The deprecation message says Url has been replaced by ZnUrl, but this is > clearly not a simple replacement of one message by an equivalent; there is > no ZnUrl class>>combine:withRelative:, for instance. >> Sven will certainly comment but I guess that there is certainly the same > behavior. > > ZnUrl>>#inContextOf: is the selector you are looking for, but path merging > is not supported (yet). > > 'readme.txt' asZnUrl inContextOf: 'http://www.host.com:8080' asZnUrl. > > Maybe we should add path merging, I'll think about it. > >>> The tidiest solution would no doubt be to find an equivalent method in > Zinc, which I am sure exists, and then modify the HTMCSS code to use it. I > have tried to find an equivalent, but Zinc is a large and complex system and > I rapidly got lost. >> It should be in ZnURL >> >> is it not addPathSegment:? >> >> >> from class comment >> >> ZnUrl new >> scheme: #https; >> host: 'encrypted.google.com'; >> addPathSegment: 'search'; >> queryAt: 'q' put: 'Smalltalk'; >> yourself. >> >> host: looks like the root >> addPathSegment: looks like https://encrypted.google.com/search >> >>> >>> I wonder more broadly about the strategy of deprecating functions which > are required by legacy packages, as in this case. Should there at least be a > way of overriding deprecations? (I suppose that is what I have done by > commenting it out, but it seems crude.) > > This is how you can work around Deprecation warnings: > > [ Url combine: 'http://www.foo.com/one/two/' withRelative: 'bar/readme.txt' > ] > on: Deprecation do: [ :exception | exception resume ] > > but that is a temporary hack. > >>> Thanks in advance for any help or suggestions. >>> >>> Peter Kenny > Sven > > > > >

Jan. 11, 2015

Re: [Pharo-users] How to subclass Float class

by stepharo

Hilaire what is your requirement? Stef Le 10/1/15 22:52, Hilaire a Ã©crit : > It looks like when I want to create a subclass of Float, I have this odd > class creation message. Moreoever, I can add instance variable to this > new class: when compiling there are wipe out: argument > instanceVariableNames: '' remain empty. > > If I change Float to Object, all get back to normal. > > Why is it like this ? > > > Float variableWordSubclass: #MyClass > instanceVariableNames: '' > classVariableNames: '' > category: 'Cofigest-Financial' > > > Thanks > > Hilaire >

Jan. 11, 2015

Re: [Pharo-users] Problem due to deprecation of class Url in Pharo 3 and Moose 5.0

by Sven Van Caekenberghe

Peter, > On 10 Jan 2015, at 23:30, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > >> Yes change the code of the Parser not to use old code. > As I pointed out, the Parser is a large and complex package, and I am not > the author, so this is easier said than done. It seems a bit odd to dismiss > code which worked OK in Moose 4.9, but not in Moose 5.0, as 'old code.' It > is code which has no functional equivalent in the new code, as Sven has > confirmed. Could you explain what arguments were given to the combine and what the expected output was/should be ? How does it use path merging ? Thx, Sven

Jan. 10, 2015

Re: [Pharo-users] Problem due to deprecation of class Url in Pharo 3 and Moose 5.0

by PBKResearch

Sven: Thanks for the suggestions. I have tried ZnUrl>>#inContextOf:, but it does not produce the correct address; evidently I shall have to wait until you have full path merging implemented. Meanwhile, I have used your 'temporary hack' to ignore the deprecation; it is at least not as hackish as my approach. Stepharo: > Yes change the code of the Parser not to use old code. As I pointed out, the Parser is a large and complex package, and I am not the author, so this is easier said than done. It seems a bit odd to dismiss code which worked OK in Moose 4.9, but not in Moose 5.0, as 'old code.' It is code which has no functional equivalent in the new code, as Sven has confirmed. Thanks again Peter Kenny -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe Sent: 10 January 2015 16:36 To: Any question about pharo is welcome Subject: Re: [Pharo-users] Problem due to deprecation of class Url in Pharo 3 and Moose 5.0 > On 10 Jan 2015, at 16:45, stepharo <stepharo(a)free.fr> wrote: > > > Le 10/1/15 11:41, PBKResearch a Ã©crit : >> Hello >> >> I have run into a problem in moving some existing work from earlier versions of Pharo/Moose. I have found a work around, but I wonder if there is a tidier way of handling it. >> >> I make frequent use of Todd BlanchardÂs HTML parser and validator, HTMCSS (http://smalltalkhub.com/#!/~ToddBlanchard/HTMCSSValidatingParser) which was originally written for Squeak but has performed without trouble on earlier versions of Pharo. When I try to use it on Moose 5.0, I get frequent warning messages about Url being deprecated. I have made the problem go away by commenting out the deprecation warning in Url class>>new, but I wonder what should be done on a more permanent basis. > Yes change the code of the Parser not to use old code. >> >> The problem arises because HTMCSS does not just parse the original HTML file; it also loads and parses any referenced CSS files. (This is a function I could do without, but I donÂt fancy trying surgery on a complex package where I only partly understand the workings!) It constructs the full address of the CSS file by combining the root address of the HTML with the relative address of the CSS, using Url class>>combine:withRelative:, and in the course of this it invokes Url class>>new; hence the deprecation message. > > use ZnURL >> >> The deprecation message says Url has been replaced by ZnUrl, but this is clearly not a simple replacement of one message by an equivalent; there is no ZnUrl class>>combine:withRelative:, for instance. > Sven will certainly comment but I guess that there is certainly the same behavior. ZnUrl>>#inContextOf: is the selector you are looking for, but path merging is not supported (yet). 'readme.txt' asZnUrl inContextOf: 'http://www.host.com:8080' asZnUrl. Maybe we should add path merging, I'll think about it. >> The tidiest solution would no doubt be to find an equivalent method in Zinc, which I am sure exists, and then modify the HTMCSS code to use it. I have tried to find an equivalent, but Zinc is a large and complex system and I rapidly got lost. > It should be in ZnURL > > is it not addPathSegment:? > > > from class comment > > ZnUrl new > scheme: #https; > host: 'encrypted.google.com'; > addPathSegment: 'search'; > queryAt: 'q' put: 'Smalltalk'; > yourself. > > host: looks like the root > addPathSegment: looks like https://encrypted.google.com/search > >> >> I wonder more broadly about the strategy of deprecating functions which are required by legacy packages, as in this case. Should there at least be a way of overriding deprecations? (I suppose that is what I have done by commenting it out, but it seems crude.) This is how you can work around Deprecation warnings: [ Url combine: 'http://www.foo.com/one/two/' withRelative: 'bar/readme.txt' ] on: Deprecation do: [ :exception | exception resume ] but that is a temporary hack. >> Thanks in advance for any help or suggestions. >> >> Peter Kenny > Sven

Jan. 10, 2015

How to subclass Float class

by Hilaire

It looks like when I want to create a subclass of Float, I have this odd class creation message. Moreoever, I can add instance variable to this new class: when compiling there are wipe out: argument instanceVariableNames: '' remain empty. If I change Float to Object, all get back to normal. Why is it like this ? Float variableWordSubclass: #MyClass instanceVariableNames: '' classVariableNames: '' category: 'Cofigest-Financial' Thanks Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Jan. 10, 2015

[OT] Things people built with Smalltalk on Twitter: #thingsPeopleBuiltWithSmalltalk

by Torsten Bergmann

If you know something built in Smalltalk then twitter it: https://twitter.com/hashtag/thingsPeopleBuiltWithSmalltalk?src=hash Lets make 2015 the "Anybody knows about Smalltalk" year ;)

Jan. 10, 2015

Re: [Pharo-users] Problem due to deprecation of class Url in Pharo 3 and Moose 5.0

by Sven Van Caekenberghe

> On 10 Jan 2015, at 16:45, stepharo <stepharo(a)free.fr> wrote: > > > Le 10/1/15 11:41, PBKResearch a Ã©crit : >> Hello >> >> I have run into a problem in moving some existing work from earlier versions of Pharo/Moose. I have found a work around, but I wonder if there is a tidier way of handling it. >> >> I make frequent use of Todd Blanchardâs HTML parser and validator, HTMCSS (http://smalltalkhub.com/#!/~ToddBlanchard/HTMCSSValidatingParser) which was originally written for Squeak but has performed without trouble on earlier versions of Pharo. When I try to use it on Moose 5.0, I get frequent warning messages about Url being deprecated. I have made the problem go away by commenting out the deprecation warning in Url class>>new, but I wonder what should be done on a more permanent basis. > Yes change the code of the Parser not to use old code. >> >> The problem arises because HTMCSS does not just parse the original HTML file; it also loads and parses any referenced CSS files. (This is a function I could do without, but I donât fancy trying surgery on a complex package where I only partly understand the workings!) It constructs the full address of the CSS file by combining the root address of the HTML with the relative address of the CSS, using Url class>>combine:withRelative:, and in the course of this it invokes Url class>>new; hence the deprecation message. > > use ZnURL >> >> The deprecation message says Url has been replaced by ZnUrl, but this is clearly not a simple replacement of one message by an equivalent; there is no ZnUrl class>>combine:withRelative:, for instance. > Sven will certainly comment but I guess that there is certainly the same behavior. ZnUrl>>#inContextOf: is the selector you are looking for, but path merging is not supported (yet). 'readme.txt' asZnUrl inContextOf: 'http://www.host.com:8080' asZnUrl. Maybe we should add path merging, I'll think about it. >> The tidiest solution would no doubt be to find an equivalent method in Zinc, which I am sure exists, and then modify the HTMCSS code to use it. I have tried to find an equivalent, but Zinc is a large and complex system and I rapidly got lost. > It should be in ZnURL > > is it not addPathSegment:? > > > from class comment > > ZnUrl new > scheme: #https; > host: 'encrypted.google.com'; > addPathSegment: 'search'; > queryAt: 'q' put: 'Smalltalk'; > yourself. > > host: looks like the root > addPathSegment: looks like https://encrypted.google.com/search > >> >> I wonder more broadly about the strategy of deprecating functions which are required by legacy packages, as in this case. Should there at least be a way of overriding deprecations? (I suppose that is what I have done by commenting it out, but it seems crude.) This is how you can work around Deprecation warnings: [ Url combine: 'http://www.foo.com/one/two/' withRelative: 'bar/readme.txt' ] on: Deprecation do: [ :exception | exception resume ] but that is a temporary hack. >> Thanks in advance for any help or suggestions. >> >> Peter Kenny > Sven

Jan. 10, 2015

Re: [Pharo-users] Metacello does not load the expected version from ConfigOf

by Dale Henrichs

Usman, Thanks for supplying the image ... with that I could diagnose the problem. In the final analysis, the onDowngrade: feature just does not work[1]. I haven't had a `downgrade` use case in my own work flow, so I did not notice that it wasn't working and the test cases that I do have are obviously faulty. Along the way, I discovered that in the Moose image, there is a custom MetacelloPlatform class installed (GTMetacelloPlatform) that is not compatible with the Scripting API. With that class installed, the scripting API will not work. I was able to install the proper platform class myself, but it requires manual intervention ... Also, it turns out the PetitParser 1.10 is the version that is installed and your new version 1.51 is not technically a downgrade ... I think that the version needs to be named 1.5.1 to be a downgrade ... I changed that as well and that's when I was able determine that onDowngrade: wasn't functioning correctly. Basically, the code said "go ahead and downgrade" but when it came time to actually load the packages, Metacello went ahead with it's standard algorithm of only loading newer versions of each package. I plan to take a crack at fixing this bug this weekend ... and will let you when I have a fix. Dale [1] https://github.com/dalehenrich/metacello-work/issues/317 On 1/8/15 12:32 AM, Usman Bhatti wrote: > > > On Wed, Jan 7, 2015 at 8:25 PM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > Usman, > > No, I appreciate your patience:) If creating your own > configuration works for you then that is a good route to go... > > > Sharing your image will make it much easier for me to get the > bottom of this (on my own schedule:), so please send me a link for > accessing your image and I'll dig into this in more detail when I > have time ... > > > Here is the image. > https://dl.dropboxusercontent.com/u/11804892/downgrade-with-metacello.zip > > You just need to execute the script in the workspace/playground to > reproduce the problem (i.e. launching the directive to load PP 1.51 > and that not happening). > > > If you find yourself stuck and needing the `downgrade directive` > again, I'll bump up the priority ... > > > I can still wait till next week. If you could have a look by then, > it'll be great. > tx. > Usman > > > > Dale > > > On 01/07/2015 09:19 AM, Usman Bhatti wrote: >> >> >> On Tue, Jan 6, 2015 at 6:56 PM, Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com >> <mailto:dale.henrichs@gemtalksystems.com>> wrote: >> >> >> On 1/6/15 7:16 AM, Usman Bhatti wrote: >>> Dale, >>> >>> I couldn't make it work with the upgraded Metacello and the >>> script you provided. >>> >>> Steps I did: >>> >>> 1. Download moose image: >>> https://ci.inria.fr/moose/job/moose-5.0/ >>> >>> 2. Update my Metacello to the 'full' version: >>> Metacello new >>> baseline: 'Metacello'; >>> repository: >>> 'github://dalehenrich/metacello-work:master/repository'; >>> get. >>> Metacello new >>> baseline: 'Metacello'; >>> repository: >>> 'github://dalehenrich/metacello-work:master/repository'; >>> onConflict: [:ex | ex allow]; >>> load >>> >>> 3. File in the ConfigurationOfDummyParser (see the first >>> message in the thread). >>> >>> 4. Run this script to downgrade to PetitParser version 1.51 >>> >>> Metacello new >>> configuration: 'DummyParser'; >>> version: '1.0'; >>> repository: '???'; >>> onDowngradeUseIncoming: #('PetitParser'); >>> load. >>> >>> The desired version is still not loaded, am I missing >>> something here? >> Good question, I don't have a lot of time today to spend time >> trying to reproduce your problem, but if you send me a copy >> of the Transcript produced while doing the load I might be >> able to spot the problem ... >> >> >> It looks to me that the downgrade command is not working. >> Whenever I point to the version preceding the one loaded, the >> packages are not fetched. >> >> I am attaching here two files. >> >> The first (Transcript-PP151) is the output of the transcript as >> you asked. You can see that PetitParser packages as defined by >> the version 1.51 are not fetched. All that is loaded is Glamour >> because the version 1.51 of PetitParser loads the latest packages >> of Glamour. The load works because it is an upgrade from the >> current version of Glamour which is a stable. >> >> When I saw that only Glamour packages are loaded, I thought of >> testing Glamour downgrade too to see if the problem is specific >> to PetitParser. You can see the result in the second file >> (Transcript-downgrade-glamour). No packages of Glamour are >> fetched because the configuration tries to downgrade it (stable >> is more recent than 3.0.0 which I try to load). >> >> In my opinion, downgrade is not working as required. If you want >> I can share my image thru dropbox so that you can have a look to >> see what might be wrong. >> >> >>> >>> regards, >>> >>> A question: I always use Metacello with ConfigOf and have >>> never used the scripting API myself or saw it being used >>> elsewhere. >>> Can you provide a link that describes the use cases for >>> both: ConfigOf vs. Scripting API? >> I've noticed the same thing:) >> >> My "elevator pitch" for the script api goes like this: >> 1. The scripting api maintains a registry of the actual >> project versions loaded into the image, >> making #currentVersion obsolete. #currentVersion is bad >> because it does a calculation of >> the current version that can be very slow and sometimes >> completely incorrect. >> 2. The old api has rules that it follows when loading >> projects (i.e., newer projects always win) and >> there is no mechanism for altering those rules. The >> scripting api provides mechanisms for >> for bending those rules to fit your needs ... like >> allowing a downgrade of a project. >> >> Part of the reason that people haven't changed has to do with >> how incredibly difficult it is to change the existing >> inertia. Another part of it is that I continue to support the >> old way of doing things, so there is no explicit motivation >> to change. >> >> If you look back 2-3 years in the archives of the Metacello >> mailing list[1] you should be able to find a number of posts >> where I make a more detailed cases for the scripting api:) >> >> At the end of the day, it isn't important to me to "get >> people to use the scripting api," as I said, I continue to >> support using the old api. I figure that when enough people >> start asking questions about how to "bend the Metacello >> rules" that folks will begin to use the "new" scripting api:) >> >> >> So, what I learn is that I am trying to bend the rules of >> Metacello which is a rare use case :). I am thinking of avoiding >> this downgrading altogether by forking to create my own ConfigOf >> that loads the correct versions. Downgrading might be an >> anti-pattern. >> >> Thank you for your patient so far :) >> >> regards. >> >> >> Dale >> [1] https://groups.google.com/forum/#!forum/metacello >> <https://groups.google.com/forum/#%21forum/metacello> >> >> > >

Jan. 10, 2015

Re: [Pharo-users] Problem due to deprecation of class Url in Pharo 3 and Moose 5.0

by stepharo

Le 10/1/15 11:41, PBKResearch a Ã©crit : > > Hello > > I have run into a problem in moving some existing work from earlier > versions of Pharo/Moose. I have found a work around, but I wonder if > there is a tidier way of handling it. > > I make frequent use of Todd Blanchardâs HTML parser and validator, > HTMCSS > (http://smalltalkhub.com/#!/~ToddBlanchard/HTMCSSValidatingParser) > which was originally written for Squeak but has performed without > trouble on earlier versions of Pharo. When I try to use it on Moose > 5.0, I get frequent warning messages about Url being deprecated. I > have made the problem go away by commenting out the deprecation > warning in Url class>>new, but I wonder what should be done on a more > permanent basis. > Yes change the code of the Parser not to use old code. > > > The problem arises because HTMCSS does not just parse the original > HTML file; it also loads and parses any referenced CSS files. (This is > a function I could do without, but I donât fancy trying surgery on a > complex package where I only partly understand the workings!) It > constructs the full address of the CSS file by combining the root > address of the HTML with the relative address of the CSS, using Url > class>>combine:withRelative:, and in the course of this it invokes Url > class>>new; hence the deprecation message. > use ZnURL > > > The deprecation message says Url has been replaced by ZnUrl, but this > is clearly not a simple replacement of one message by an equivalent; > there is no ZnUrl class>>combine:withRelative:, for instance. > Sven will certainly comment but I guess that there is certainly the same behavior. > The tidiest solution would no doubt be to find an equivalent method in > Zinc, which I am sure exists, and then modify the HTMCSS code to use > it. I have tried to find an equivalent, but Zinc is a large and > complex system and I rapidly got lost. > It should be in ZnURL is it not addPathSegment:? from class comment ZnUrl new scheme: #https; host: 'encrypted.google.com'; addPathSegment: 'search'; queryAt: 'q' put: 'Smalltalk'; yourself. host: looks like the root addPathSegment: looks like https://encrypted.google.com/search > I wonder more broadly about the strategy of deprecating functions > which are required by legacy packages, as in this case. Should there > at least be a way of overriding deprecations? (I suppose that is what > I have done by commenting it out, but it seems crude.) > > Thanks in advance for any help or suggestions. > > Peter Kenny >

Jan. 10, 2015