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

Re: [Pharo-dev] ZnUrl: Constructing without Scheme

by Sven Van Caekenberghe

I know you mean well, but you cannot confuse things. Without some context, not much can be done. #asZnUrl has totally no context. I recently added ZnUrl>>#withRelativeReference: reference "Return a new URL by parsing & resolving the relative reference using myself as base URL. This implements the process described in RFC 3986 Section 5" See also #testReferenceResolution The specs (RFCs) do count, the rest is often wishful thinking that does not take all use cases into account. Of course, ZnUrl is not the final answer to this broad problem, just some answer that started in the HTTP world. I don't want to change its parsing unless there is a very clear reason and explanation why/how. > On 13 Mar 2015, at 19:18, Norbert Hartl <norbert(a)hartl.name> wrote: > > >> Am 13.03.2015 um 17:29 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> >>> On 13 Mar 2015, at 17:20, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> My concern is more that >>> >>> 'urn:foo:bar' asUrl >>> >>> doesn't do what it should :) >> >> That is because #urn is not in #schemesNotUsingDoubleSlash, it should probably be added. >> >> But then I have to read more about it first. >> >> https://en.wikipedia.org/wiki/Uniform_resource_name > > I need to dig into it, too. I just wondered why > > 'abc' asUrl > > prints '/abc' > > That doesn't appear right. What do you think? It is just a URI path or a relative URL (depending how you like to put it). A relative URL resolved by a base URI will work because 'http://foo.com/foo//abc' (<â double slash) is still valid. > > I think that scheme is supposed to be a class and the parsing of the remaining string is delegated to that scheme. That would make it more easy to have URL (the locator part) as specialization to plain URI. But then it will make the code base a lot more complex and performance wise it probably has its cost. But then there would be a scheme registry that can easily extended by custom schemes. > > Just some quick thoughts, > > Norbert

March 13, 2015

Re: [Pharo-dev] ZnUrl: Constructing without Scheme

by Norbert Hartl

> Am 13.03.2015 um 17:29 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > >> On 13 Mar 2015, at 17:20, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> My concern is more that >> >> 'urn:foo:bar' asUrl >> >> doesn't do what it should :) > > That is because #urn is not in #schemesNotUsingDoubleSlash, it should probably be added. > > But then I have to read more about it first. > > https://en.wikipedia.org/wiki/Uniform_resource_name I need to dig into it, too. I just wondered why 'abc' asUrl prints '/abc' That doesn't appear right. What do you think? It is just a URI path or a relative URL (depending how you like to put it). A relative URL resolved by a base URI will work because 'http://foo.com/foo//abc' <http://foo.com/foo//abc'> (<â double slash) is still valid. I think that scheme is supposed to be a class and the parsing of the remaining string is delegated to that scheme. That would make it more easy to have URL (the locator part) as specialization to plain URI. But then it will make the code base a lot more complex and performance wise it probably has its cost. But then there would be a scheme registry that can easily extended by custom schemes. Just some quick thoughts, Norbert

March 13, 2015

Re: [Pharo-dev] #milliseconds versus #milliSeconds

by stepharo

Le 3/3/15 22:37, Stephan Eggermont a Ã©crit : > On 03/03/15 14:37, Sean P. DeNigris wrote: >> I definitely recall feeling "lots of pain" with the subStringXyz -> >> substringXyz that we're still dealing with in recent updates (I think I >> started that push as a naive newbie), but I'm not sure about the "little >> gain" part. It's hard to quantify the negative effect of >> inconsistency in >> the system, or the empowering effect of uniformity. > > These kind of changes should be accompanied by a rewrite script, b.t.w. > Upgrading is much easier if you can just select the rewrites you want > to apply. I do not know if you know but there is a support for automatically rewriting deprecated methods :) It is there but is not used. > > Stephan > > > >

March 13, 2015

Re: [Pharo-dev] ZnUrl: Constructing without Scheme

by Sven Van Caekenberghe

> On 13 Mar 2015, at 17:20, Norbert Hartl <norbert(a)hartl.name> wrote: > > My concern is more that > > 'urn:foo:bar' asUrl > > doesn't do what it should :) That is because #urn is not in #schemesNotUsingDoubleSlash, it should probably be added. But then I have to read more about it first. https://en.wikipedia.org/wiki/Uniform_resource_name

March 13, 2015

Re: [Pharo-dev] ZnUrl: Constructing without Scheme

by Norbert Hartl

> Am 12.03.2015 um 22:20 schrieb Sean P. DeNigris <sean(a)clipperadams.com>: > > On Mar 12, 2015, at 4:54 PM, Sven Van Caekenberghe-2 [via Smalltalk] <[hidden email] <x-msg://25/user/SendEmail.jtp?type=node&node=4811589&i=0>> wrote: >> The scheme is not optional, it defines what (kind) the URL is. You are expecting behaviour such as in a browser's address bar. But there, there is context (you are expecting an HTTP URL). > > I did see the defaultScheme: variant. Iâm not saying we should necessarily assume HTTP. Iâm just saying if someone gives us a string like 'www.hm.com <http://www.hm.com/>â (which I agree is incompletely defined), why set #segments and not #host? Even with scheme = nil, the following would be more useful: > 'www.hm.com <http://www.hm.com/>' asUrl host = 'www.hm.com <http://www.hm.com/>'. > 'www.hm.com <http://www.hm.com/>' asUrl segments = m <http://www.hm.com/>') an OrderedCollection() To me it is a discussion what is the real interpretation of ZnUrl. It behaves mostly like URI but the name implies URL. Without a colon you are in URI land. It is just a path. Starting with /, // or without slash determines the kind of path. So www.hm.com <http://www.hm.com/> ist perfectly valid path. Just create a file named www.hm.com <http://www.hm.com/> on your filesystem and you can luckily reference it with that URI. Having a URI/URL object in mind there is nothing to assume. From a text block point of view that might be different. Text display in apps use something like linkify. There you scan the content for patterns like www.*.* or even *.*.* (matching domains for the last part) and if you find some you assume it to be a URL with the host you've found. But then you create the URLs out of that given context. Maybe you need another selector like asHttpUrl? My concern is more that 'urn:foo:bar' asUrl doesn't do what it should :) Norbert

March 13, 2015

Re: [Pharo-dev] ZnUrl: Constructing without Scheme

by Sven Van Caekenberghe

Sean, > On 12 Mar 2015, at 22:33, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > On Mar 12, 2015, at 5:30 PM, Sven Van Caekenberghe-2 [via Smalltalk] <[hidden email]> wrote: > > I think that what we have now is correct. I am willing to change my mind when you point to some RFC that supports your point ;-) > Well in that caseâ¦ > > ^ Response new > emoticon: ':-Pâ; > sound: Sound raspberry; > yourself. > Cheers, > Sean > > View this message in context: Re: ZnUrl: Constructing without Scheme > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. I do not entirely understand, but anyway, I just committed this: === Name: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.33 Author: SvenVanCaekenberghe Time: 13 March 2015, 4:38:39.625508 pm UUID: dbf5fd62-d9b2-48be-a1bb-cd22dec62852 Ancestors: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.32 Replace ZnUrlTests>>#testMissingScheme by the more extensive ZnUrlTests>>#testNoScheme - an attempt to make it more explicit using external test code why, when there is no scheme, there is no host:port interpretation, but instead the input is seen a a path Add ZnUrlTests>>#testDefaultPortUnknownScheme === Maybe this makes it easier to understand why things are the way they are. ZnUrlTests>>#testNoScheme "When there is no scheme, there is no host:port interpretation, but instead the input is seen a a path - externalize this in test code" #('foo' 'localhost' 'www.foo.com' 'foo.txt' 'foo:1') do: [ :input | | url | url := input asZnUrl. self deny: url hasScheme. self deny: url hasHost. self deny: url hasPort. self deny: url hasQuery. self deny: url hasFragment. self assert: url hasPath. self assert: url isFilePath. self assert: url firstPathSegment equals: input ]. #('/dir/foo.txt' 'dir/foo.txt') do: [ :input | | url | url := input asZnUrl. self deny: url hasScheme. self deny: url hasHost. self deny: url hasPort. self deny: url hasQuery. self deny: url hasFragment. self assert: url hasPath. self assert: url isFilePath. self assert: url pathSegments equals: #('dir' 'foo.txt') asOrderedCollection ] I think this is correct. The alternative, what you are suggesting, would make most if not all of the above be interpreted as hosts. Sven

March 13, 2015

[pharo-project/pharo-core]

by GitHub

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

March 13, 2015

[pharo-project/pharo-core] 1b4db2: 40556

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 1b4db25bc8c28fbe0b92f96752a34dc57c8edbef https://github.com/pharo-project/pharo-core/commit/1b4db25bc8c28fbe0b92f967… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-03-13 (Fri, 13 Mar 2015) Changed paths: R GTPharo4Extensions.package/extension/OrderedDictionary/instance/gtInspectorItemsIn_.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script555.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script556.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40555.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40556.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Spec-Examples.package/DynamicSpecExample.class/instance/accessing/title.st R Spec-Examples.package/DynamicSpecExample.class/instance/as yet unclassified/title.st M Spec-Examples.package/DynamicSpecExample.class/instance/initialization/initialize.st M Spec-Examples.package/DynamicSpecExample.class/instance/protocol/openOnInteger.st M Spec-Examples.package/DynamicSpecExample.class/instance/protocol/openOnNil.st M Spec-Examples.package/DynamicSpecExample.class/instance/protocol/openOnString.st M Tool-Base.package/AbstractTool.class/instance/class/showUnreferencedClassVarsOf_.st M Tool-Base.package/PharoCommonTools.class/instance/cleanup/cleanUp.st M Tool-Base.package/PharoCommonTools.class/instance/registration/recentToolsFor_.st R Tool-Base.package/PharoCommonTools.class/instance/registration/remove_.st Log Message: ----------- 40556 15064 DynamicSpecExample should use #label: instead of deprecated #text: https://pharo.fogbugz.com/f/cases/15064 15125 PharoCommonTools>>#cleanUp changes collection while iterating https://pharo.fogbugz.com/f/cases/15125 15045 GTPharo4Extensions should be merged into GT-SpotterExtensions-Core https://pharo.fogbugz.com/f/cases/15045 http://files.pharo.org/image/40/40556.zip

March 13, 2015

Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?

by Damien Cassou

Esteban Lorenzano writes: > thatâ¦ is someone using it? I think the pharo-users mailing list is more appropriate -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

March 13, 2015

Re: [Pharo-dev] #milliseconds versus #milliSeconds

by stepharo

definitively and we should have deprecated methods. Le 3/3/15 14:31, Ben Coman a Ã©crit : > Using Finder, the majority representation in the image appears to be > all-lowercase #milliseconds with only a few #milliSeconds. Googling > indicates the former is usual. Is it worth logging a ticket > for Pharo 5 to make the latter consistent? > > cheers -ben

March 13, 2015