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

Re: [Pharo-dev] Bugfix to '/foo:bar' asUrl

by Johan Brichau

Hey Sven, >From what I traced already, the path segments are correctly stored. The parsing works fine. It's the printing of a ZnUrl that seems to ignore it and produce a 'foo%20+%20bar' Diving into it... Johan On 14 Feb 2014, at 10:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Again, I think this can be simplified to URL parsing. > > 'http://localhost/foo+%2B+bar' asZnUrl. > > => 'http://localhost/foo%20+%20bar' > > 'http://localhost/foo+%2B+bar' asZnUrl firstPathSegment. > > => 'foo + bar' > > But I think it is correct, unless you read the specs differently. There were indeed some recent , under the hood changes to which characters are allowed in which part of URLs, I did that together with Jan van de Sandt, and we thought we had everything covered, but it is hard to be sure. See > > ZnUrl>>#encodePath:on: > ZnUrl>>#encodeQuery:on: > > to get started.

Feb. 14, 2014

Re: [Pharo-dev] Bugfix to '/foo:bar' asUrl

by Sven Van Caekenberghe

Johan, On 14 Feb 2014, at 09:43, Johan Brichau <johan(a)inceptive.be> wrote: > Hey Sven, > > Thanks for fixing that. We're close to getting Yesplan working on Pharo3 now. That is very good to hear, keep on pushing ! It would be a super cool reference for Pharo 3. I am working with the latest Seaside (Bootstrap) on Pharo 3 this week and I am quite pleased as well, thanks for all the hard working getting the codebase and configs working. > However, yesterday I stumbled upon another problem. It seems that a percent-encoded '+' (i.e. %2B) get eaten by Zinc and converted into a space (ie. %20). > The following test fails in latest Zinc but works in a Zinc on Pharo 1.4: > > | input request | > > input := 'GET http://localhost/foo+%2B+bar HTTP/1.1', String crlf, > String crlf. > request := ZnRequest readFrom: input readStream. > self assert: (request url pathSegments hasEqualElements: #('foo%20%2B%20bar')). > > > I'm tracing if I can find the actual source of the problem. Again, I think this can be simplified to URL parsing. 'http://localhost/foo+%2B+bar' asZnUrl. => 'http://localhost/foo%20+%20bar' 'http://localhost/foo+%2B+bar' asZnUrl firstPathSegment. => 'foo + bar' But I think it is correct, unless you read the specs differently. There were indeed some recent , under the hood changes to which characters are allowed in which part of URLs, I did that together with Jan van de Sandt, and we thought we had everything covered, but it is hard to be sure. See ZnUrl>>#encodePath:on: ZnUrl>>#encodeQuery:on: to get started. Sven > regards > Johan > > > On 13 Feb 2014, at 22:47, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Hi Kris, >> >> I fixed the problem that you reported. It was a regression caused when adding support for parsing mailto: URLs which don't have a // in them. There is now a new explicit test for parsing '/foo:bar' asZnUrl. >> >> Thanks again for reporting this problem! >> >> Sven >> >> In #bleedingEdge: >> >> === >> Name: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.31 >> Author: SvenVanCaekenberghe >> Time: 13 February 2014, 10:41:58.821615 pm >> UUID: dee515f8-aff3-4930-8b90-da2b01e1ee33 >> Ancestors: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.30 >> >> Patch ZnUrl>>#parseFrom:defaultScheme: to parse schemes more carefully so that a colon in a path does not mess things up - see also the regression test ZnUrlTests>>#testNoSchemeColonInPath parsing /foo:bar (thanks Kris Gijbels) >> === >> Name: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.19 >> Author: SvenVanCaekenberghe >> Time: 13 February 2014, 10:42:42.63619 pm >> UUID: 264c99fe-52ef-4f4a-8a25-fc870f34cfb2 >> Ancestors: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.18 >> >> Patch ZnUrl>>#parseFrom:defaultScheme: to parse schemes more carefully so that a colon in a path does not mess things up - see also the regression test ZnUrlTests>>#testNoSchemeColonInPath parsing /foo:bar (thanks Kris Gijbels) >> === >> > >

Feb. 14, 2014

Re: [Pharo-dev] Bugfix to '/foo:bar' asUrl

by Johan Brichau

Hey Sven, Thanks for fixing that. We're close to getting Yesplan working on Pharo3 now. However, yesterday I stumbled upon another problem. It seems that a percent-encoded '+' (i.e. %2B) get eaten by Zinc and converted into a space (ie. %20). The following test fails in latest Zinc but works in a Zinc on Pharo 1.4: | input request | input := 'GET http://localhost/foo+%2B+bar HTTP/1.1', String crlf, String crlf. request := ZnRequest readFrom: input readStream. self assert: (request url pathSegments hasEqualElements: #('foo%20%2B%20bar')). I'm tracing if I can find the actual source of the problem. regards Johan On 13 Feb 2014, at 22:47, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Kris, > > I fixed the problem that you reported. It was a regression caused when adding support for parsing mailto: URLs which don't have a // in them. There is now a new explicit test for parsing '/foo:bar' asZnUrl. > > Thanks again for reporting this problem! > > Sven > > In #bleedingEdge: > > === > Name: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.31 > Author: SvenVanCaekenberghe > Time: 13 February 2014, 10:41:58.821615 pm > UUID: dee515f8-aff3-4930-8b90-da2b01e1ee33 > Ancestors: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.30 > > Patch ZnUrl>>#parseFrom:defaultScheme: to parse schemes more carefully so that a colon in a path does not mess things up - see also the regression test ZnUrlTests>>#testNoSchemeColonInPath parsing /foo:bar (thanks Kris Gijbels) > === > Name: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.19 > Author: SvenVanCaekenberghe > Time: 13 February 2014, 10:42:42.63619 pm > UUID: 264c99fe-52ef-4f4a-8a25-fc870f34cfb2 > Ancestors: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.18 > > Patch ZnUrl>>#parseFrom:defaultScheme: to parse schemes more carefully so that a colon in a path does not mess things up - see also the regression test ZnUrlTests>>#testNoSchemeColonInPath parsing /foo:bar (thanks Kris Gijbels) > === >

Feb. 14, 2014

Re: [Pharo-dev] Smalltalkhub is Down

by GÃ¶ran Krampe

On 02/14/2014 08:25 AM, Marcus Denker wrote: > I think there where some network problems at Inria the nightâ¦ > my watchdog told my that lots of services randomly where unavailable for > some time. Sounds right because I actually pinged it, and it did not reply. Now it does. regards, GÃ¶ran

Feb. 14, 2014

[pharo-project/pharo-core] 61c1c7: 30756

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 61c1c7978d7118b21f1bdd6530c85dafe3867afc https://github.com/pharo-project/pharo-core/commit/61c1c7978d7118b21f1bdd65… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-02-13 (Thu, 13 Feb 2014) Changed paths: M Compression.package/ZipArchive.class/class/fileIn%2FOut/extractAllIn_.st M Nautilus.package/PackageTreeModel.class/instance/drag and drop/wantsDroppedMorph_event_inMorph_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script409.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30756.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Settings-Compiler.package/CompilerSystemSettings.class/README.md M Settings-Display.package/DisplaySettings.class/README.md M Settings-FreeType.package/FreeTypeSystemSettings.class/README.md M Settings-Graphics.package/GraphicFontSettings.class/README.md M Settings-Kernel.package/InputEventSensorSystemSettings.class/README.md M Settings-Monticello.package/MCSystemSettings.class/README.md M Settings-Polymorph.package/PSMCSystemSettings.class/README.md M Settings-Polymorph.package/TaskListSystemSettings.class/README.md M Settings-Polymorph.package/TaskbarSystemSettings.class/README.md M Settings-System.package/SystemSystemSettings.class/README.md M Settings-Tools.package/CodeHolderSystemSettings.class/README.md M Settings-Tools.package/DebugSystemSettings.class/README.md Log Message: ----------- 30756 12871 Class comments missing for Settings-... packages https://pharo.fogbugz.com/f/cases/12871 12024 ExtractAll does not work for a .mcz in a FileList https://pharo.fogbugz.com/f/cases/12024 12829 Dragging a morph to system browser results in DNU >> #passenger https://pharo.fogbugz.com/f/cases/12829 http://files.pharo.org/image/30/30756.zip

Feb. 14, 2014

[pharo-project/pharo-core]

by GitHub

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

Feb. 14, 2014

Re: [Pharo-dev] Smalltalkhub is Down

by Marcus Denker

I think there where some network problems at Inria the nightâ¦ my watchdog told my that lots of services randomly where unavailable for some time. On 14 Feb 2014, at 03:04, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Smalltalkhub-is-Down-tp4743444.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Feb. 14, 2014

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/Run=run%201,VM=vm,label=linux… 1 regressions found. NetworkTests.Kernel.NetNameResolverTest.testLocalHostName

Feb. 14, 2014

Jenkins build became unstable: Pharo-2.0-Tests Â» run 1,vm,linux #283

by no-reply＠ci.inria.fr

See <https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/Run=run%201,VM=vm,label=linux…>

Feb. 14, 2014

Re: [Pharo-dev] Smalltalkhub is Down

by Tudor Girba

Indeed. Doru On Fri, Feb 14, 2014 at 3:03 AM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Smalltalkhub-is-Down-tp4743444.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 14, 2014