February 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ZnUrl>>#withRelativeReference:
by Sven Van Caekenberghe Feb. 5, 2015

Feb. 5, 2015

Peter, Thanks for the feedback. (CC-ing the list) > On 05 Feb 2015, at 18:16, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > > Sven > > Thanks for your efforts. I have tried ZnUrl>>#withRelativeReference: on the > examples I gave in my e-mail of 11 Jan. Unfortunately it gives the same > incorrect result as ZnUrl>>#inContextOf: in the case where the relative > address begins with '//'. Admittedly this is a rather weird case, but RFC > 3986 does acknowledge its existence (see para 4.2) and it is dealt with > correctly by the old Url class>># combine:withRelative: (in fact there is > special coding for this case in HierarchicalUrl>># > privateInitializeFromText:). (I am not sure whether the pseudo-code in RFC > 3986 sec 5 deals correctly with an initial '//'; it is not considered > explicitly, but I could not follow all the ramifications of the case with > initial '/'.) I would like to understand why you need it, it seems very weird to me, it was one of the few cases that I decided not to implement: In ZnUrlTests>>#testReferenceResolution " '//g' -> 'http://g'. " "we do not support relative network path references (4.2)" In the RFC they say (page 26) << A relative reference that begins with two slash characters is termed a network-path reference; such references are rarely used. >> Could you please give a concrete example of how/why this is useful ? Thx, Sven > I feel rather guilty that you have gone to so much trouble because, thanks > to Monty, I now have two alternatives to the Blanchard parser (XMLHTMLParser > and Soup). I shall pretty certainly be using one or other of these in > future, in place of the Blanchard parser, because they provide more flexible > ways of interrogating the resulting DOM - and also because they are actively > maintained. So from my point of view there is now no need for you to pursue > this any further - unless you see this as a loose end to be tidied up. Not problem, I am trying to make it right. > Thanks again > > Peter Kenny > > PS I can't post to the Pharo Development List, so I left that out of the > addressee list. > > -----Original Message----- > From: Sven Van Caekenberghe [mailto:sven@stfx.eu] > Sent: 05 February 2015 10:30 > To: Pharo Development List > Cc: monty; peter(a)pbkresearch.co.uk > Subject: ZnUrl>>#withRelativeReference: > > Hi, > > I added ZnUrl>>#withRelativeReference: which implements the process > described in section 5 of RFC 3986. > > https://pharo.fogbugz.com/f/cases/14855/Add-reference-resolution-to-ZnUrl > > Summary: > > In certain contexts (like links on a webpage) partial URLs are used that > must be interpreted relative to a base URL (like the URL of the webpage > itself). > > Example: > > 'http://www.site.com/static/html/home.html' asZnUrl > withRelativeReference: '../js/menu.js' > > => http://www.site.com/static/js/menu.js > > This was previously not possible with ZnUrl. > > If you know this stuff, please have a look. > > Monty ? Peter ? > > Sven > > PS: this is in #bleedingEdge for now >

3 7

Re: [Pharo-dev] ZnUrl>>#withRelativeReference:
by Sven Van Caekenberghe Feb. 5, 2015

Feb. 5, 2015

Peter, OK, thanks for the concrete example. So these are out there in the wild, I'll add a special case to handle these. Thanks, Sven > On 05 Feb 2015, at 20:03, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > > Sven > > I agree the '//' case is weird, I would never use it myself. However, my > requirement is to be able to parse and dissect web pages, particularly > Wikipedia and Wiktionary pages, and they use this construction all the time. > Mostly it occurs in link tags in page headers. I think the reason is that > the individual pages are in, for example, en.wiktionary.org, but shared > resources are in bits.wikimedia.org; hence the 'relative' address is in > effect a complete path (in which case why not put 'http:' in front and make > it an absolute address?). > > The problem arises in parsing with the Blanchard parser because it is > designed as a validator, hence it follows up the links in the page header to > make sure the resources exist. This is of no interest to me, I just want to > get at the body of the page, but I carried on using it because it is very > good at parsing the body. I had considered mutilating the parser by cutting > out all the processing it does on link nodes. However, before that happened > Monty pointed me to XMLHTMLParser and then Soup; these are just parsers, not > validators, so as far as they are concerned the link addresses are just > text. > > As I said, I am pretty sure I shall abandon the Blanchard parser and use one > of the two that Monty identified - probably Soup. Hence I can ignore this > problem from now on. Whether you think '//' worth including is for you to > decide. The only argument I can see is that it was handled by the now > deprecated Url class, so in theory it could be used by someone still using > Pharo 2 or earlier, who would find problems on updating to Pharo 3 or later. > > Hope this helps > > Peter Kenny > > -----Original Message----- > From: Sven Van Caekenberghe [mailto:sven@stfx.eu] > Sent: 05 February 2015 17:28 > To: PBKResearch > Cc: monty; Pharo Development List > Subject: Re: ZnUrl>>#withRelativeReference: > > Peter, > > Thanks for the feedback. (CC-ing the list) > >> On 05 Feb 2015, at 18:16, PBKResearch <peter(a)pbkresearch.co.uk> wrote: >> >> Sven >> >> Thanks for your efforts. I have tried ZnUrl>>#withRelativeReference: >> on the examples I gave in my e-mail of 11 Jan. Unfortunately it gives >> the same incorrect result as ZnUrl>>#inContextOf: in the case where >> the relative address begins with '//'. Admittedly this is a rather >> weird case, but RFC >> 3986 does acknowledge its existence (see para 4.2) and it is dealt >> with correctly by the old Url class>># combine:withRelative: (in fact >> there is special coding for this case in HierarchicalUrl>># >> privateInitializeFromText:). (I am not sure whether the pseudo-code in >> RFC >> 3986 sec 5 deals correctly with an initial '//'; it is not considered >> explicitly, but I could not follow all the ramifications of the case >> with initial '/'.) > > I would like to understand why you need it, it seems very weird to me, it > was one of the few cases that I decided not to implement: > > In ZnUrlTests>>#testReferenceResolution > > " '//g' -> 'http://g'. " "we do not support relative network path > references (4.2)" > > In the RFC they say (page 26) > > << > A relative reference that begins with two slash characters is termed > a network-path reference; such references are rarely used. >>> > > Could you please give a concrete example of how/why this is useful ? > > Thx, > > Sven > >> I feel rather guilty that you have gone to so much trouble because, >> thanks to Monty, I now have two alternatives to the Blanchard parser >> (XMLHTMLParser and Soup). I shall pretty certainly be using one or >> other of these in future, in place of the Blanchard parser, because >> they provide more flexible ways of interrogating the resulting DOM - >> and also because they are actively maintained. So from my point of >> view there is now no need for you to pursue this any further - unless you > see this as a loose end to be tidied up. > > Not problem, I am trying to make it right. > >> Thanks again >> >> Peter Kenny >> >> PS I can't post to the Pharo Development List, so I left that out of >> the addressee list. >> >> -----Original Message----- >> From: Sven Van Caekenberghe [mailto:sven@stfx.eu] >> Sent: 05 February 2015 10:30 >> To: Pharo Development List >> Cc: monty; peter(a)pbkresearch.co.uk >> Subject: ZnUrl>>#withRelativeReference: >> >> Hi, >> >> I added ZnUrl>>#withRelativeReference: which implements the process >> described in section 5 of RFC 3986. >> >> https://pharo.fogbugz.com/f/cases/14855/Add-reference-resolution-to-Zn >> Url >> >> Summary: >> >> In certain contexts (like links on a webpage) partial URLs are used >> that must be interpreted relative to a base URL (like the URL of the >> webpage itself). >> >> Example: >> >> 'http://www.site.com/static/html/home.html' asZnUrl >> withRelativeReference: '../js/menu.js' >> >> => http://www.site.com/static/js/menu.js >> >> This was previously not possible with ZnUrl. >> >> If you know this stuff, please have a look. >> >> Monty ? Peter ? >> >> Sven >> >> PS: this is in #bleedingEdge for now >> >

1 0

[pharo-project/pharo-core]
by GitHub Feb. 5, 2015

Feb. 5, 2015

Branch: refs/tags/40478 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core] 6c62c7: 40478
by GitHub Feb. 5, 2015

Feb. 5, 2015

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 6c62c7435d8edd501c5be5a33f1ef5791f86a515 https://github.com/pharo-project/pharo-core/commit/6c62c7435d8edd501c5be5a3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-02-05 (Thu, 05 Feb 2015) Changed paths: M Kernel.package/ClassDescription.class/instance/slots/slots.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script478.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40478.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot.package/AbstractLayout.class/instance/accessing/visibleSlots.st A Slot.package/HiddenInstanceVariableSlot.class/README.md A Slot.package/HiddenInstanceVariableSlot.class/definition.st A Slot.package/HiddenInstanceVariableSlot.class/instance/testing/isVisible.st Log Message: ----------- 40478 14798 Slots: add HiddenInstanceVariableSlot https://pharo.fogbugz.com/f/cases/14798 http://files.pharo.org/image/40/40478.zip

1 0

[CI] help needed: integration of Fuel changes with new version number
by Max Leske Feb. 5, 2015

Feb. 5, 2015

Hi guys ClÃ©ment asked us a while ago to update Fuel for Spur support and we did (https://pharo.fogbugz.com/f/cases/14688/Change-CompiledMethod-header-serial… <https://pharo.fogbugz.com/f/cases/14688/Change-CompiledMethod-header-serial…>). The problem now: Fuel is an integral part of the integration process and the change to the Fuel version number means that the automatic integration will not work. Hereâs why: This slice can't be automatically integrated because I changed the Fuel version number. Now, when the image worker reads the result from the validation, Fuel raises an exception because of the different version numbers in the parent and child image. We should probably add a mechanism that ensures that the original Fuel version is reloaded after the validation, such that the Fuel file is written by the same version that then reads it in the parent. Can someone please manually integrate or (which would be way cooler) adapt the integration process such that future updates to Fuel can be automatically integrated? Cheers, Max

2 2

[pharo-project/pharo-core]
by GitHub Feb. 5, 2015

Feb. 5, 2015

Branch: refs/tags/40477 Home: https://github.com/pharo-project/pharo-core

1 0

[CI] is integrator actually integrating?
by Max Leske Feb. 5, 2015

Feb. 5, 2015

Iâm subscribed to a couple of resolved (and validated) issues on fogbugz which donât seem to get integrated, although the integrator runs once a day. Is something going wrong there? Issues to integrate: https://pharo.fogbugz.com/f/cases/14669/Delay-refactoring-part-2a-avoid-UI-… <https://pharo.fogbugz.com/f/cases/14669/Delay-refactoring-part-2a-avoid-UI-…> https://pharo.fogbugz.com/f/cases/14064/Improvements-to-checking-terminatio… <https://pharo.fogbugz.com/f/cases/14064/Improvements-to-checking-terminatio…> Cheers, Max

2 2

GT + Dark Theme
by Marcus Denker Feb. 5, 2015

Feb. 5, 2015

Hi, 40 475 now integrates the fixes for making GT work nicer with the Dark Theme. Thanks to all the contributors! Marcus

5 4

[pharo-project/pharo-core]
by GitHub Feb. 5, 2015

Feb. 5, 2015

Branch: refs/tags/40476 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core] abf9e7: 40476
by GitHub Feb. 5, 2015

Feb. 5, 2015

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: abf9e7101c0106e93e50b605501671ad1362dd27 https://github.com/pharo-project/pharo-core/commit/abf9e7101c0106e93e50b605… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-02-05 (Thu, 05 Feb 2015) Changed paths: M Morphic-Base.package/TextAnchor.class/README.md A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script476.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40476.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Caching.package/AbtractCache.class/instance/accessing/at_.st A System-CachingTests.package/LRUCacheTests.class/instance/testing/testAt.st M Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/other/browseVersions.st Log Message: ----------- 40476 12597 Update TextAnchor class comment https://pharo.fogbugz.com/f/cases/12597 14853 Improve AbstractCache plain access https://pharo.fogbugz.com/f/cases/14853 14814 NewVersionBrowser api not updated in all the client packages https://pharo.fogbugz.com/f/cases/14814 http://files.pharo.org/image/40/40476.zip

1 0