Problem due to deprecation of class Url in Pharo 3 and Moose 5.0
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. 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. 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. 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. 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
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
On 10 Jan 2015, at 16:45, stepharo <stepharo@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
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@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
Peter,
On 10 Jan 2015, at 23:30, PBKResearch <peter@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
Sven Apologies for the delay in replying. Basically, the relative argument can be anything that occurs in a LINK tag in an HTML document. This can be anything from a file name to a complete address with only the 'http:' missing. I have found a couple of examples in a document from the Wikipedia 'Wiktionary', where I show in the attached workspace file the absolute address, the two relative addresses and the effect of combining using Url class>>#combine:withRelative and ZnUrl>>#inContextOf:. In each case the output of the Url class>>#combine:withRelative is the expected result; in the first case ZnUrl>>#inContextOf: gives the expected result, in the second it does not. The relative address in the second case seems a bit odd (why not include the 'http:' and make it absolute?), but it actually occurs (quite often in Wiktionary files at least) and the code needs to be able to deal with it. Hope this helps. Peter Kenny -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe Sent: 10 January 2015 22:56 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 Peter,
On 10 Jan 2015, at 23:30, PBKResearch <peter@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
Hi Peter,
On 11 Jan 2015, at 12:47, PBKResearch <peter@pbkresearch.co.uk> wrote:
Sven
Apologies for the delay in replying.
Basically, the relative argument can be anything that occurs in a LINK tag in an HTML document. This can be anything from a file name to a complete address with only the 'http:' missing.
I have found a couple of examples in a document from the Wikipedia 'Wiktionary', where I show in the attached workspace file the absolute address, the two relative addresses and the effect of combining using Url class>>#combine:withRelative and ZnUrl>>#inContextOf:. In each case the output of the Url class>>#combine:withRelative is the expected result; in the first case ZnUrl>>#inContextOf: gives the expected result, in the second it does not.
The relative address in the second case seems a bit odd (why not include the 'http:' and make it absolute?), but it actually occurs (quite often in Wiktionary files at least) and the code needs to be able to deal with it.
The problem is that ZnUrl>>#inContextOf: works with 2 parsed URL objects. However, relative URLs are not proper URLs and cannot be parsed nor represented as such. For example, 'foo/bar/readme.txt' and '/foo/bar/readme.txt' are the same. Relative URLs only exist while parsing and must then be resolved. Section 5 of RFC 3968 explains in details how to do that. This will have to be added to ZnUrl or to a helper class, but that will take some time. Luckily there are test cases in the document. Thanks for the feedback. Sven
Hope this helps.
Peter Kenny
-----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe Sent: 10 January 2015 22:56 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
Peter,
On 10 Jan 2015, at 23:30, PBKResearch <peter@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 <CombineRelWithAbs.ws>
https://pharo.fogbugz.com/f/cases/14855/Add-reference-resolution-to-ZnUrl
On 12 Jan 2015, at 09:57, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Peter,
On 11 Jan 2015, at 12:47, PBKResearch <peter@pbkresearch.co.uk> wrote:
Sven
Apologies for the delay in replying.
Basically, the relative argument can be anything that occurs in a LINK tag in an HTML document. This can be anything from a file name to a complete address with only the 'http:' missing.
I have found a couple of examples in a document from the Wikipedia 'Wiktionary', where I show in the attached workspace file the absolute address, the two relative addresses and the effect of combining using Url class>>#combine:withRelative and ZnUrl>>#inContextOf:. In each case the output of the Url class>>#combine:withRelative is the expected result; in the first case ZnUrl>>#inContextOf: gives the expected result, in the second it does not.
The relative address in the second case seems a bit odd (why not include the 'http:' and make it absolute?), but it actually occurs (quite often in Wiktionary files at least) and the code needs to be able to deal with it.
The problem is that ZnUrl>>#inContextOf: works with 2 parsed URL objects. However, relative URLs are not proper URLs and cannot be parsed nor represented as such. For example, 'foo/bar/readme.txt' and '/foo/bar/readme.txt' are the same.
Relative URLs only exist while parsing and must then be resolved. Section 5 of RFC 3968 explains in details how to do that. This will have to be added to ZnUrl or to a helper class, but that will take some time. Luckily there are test cases in the document.
Thanks for the feedback.
Sven
Hope this helps.
Peter Kenny
-----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe Sent: 10 January 2015 22:56 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
Peter,
On 10 Jan 2015, at 23:30, PBKResearch <peter@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 <CombineRelWithAbs.ws>
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@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
participants (3)
-
PBKResearch -
stepharo -
Sven Van Caekenberghe