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

[pharo-project/pharo-core] f5c399: 30758

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: f5c3990c6c272b4e1aa18f513985cd6a5130bfd9 https://github.com/pharo-project/pharo-core/commit/f5c3990c6c272b4e1aa18f51… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-02-14 (Fri, 14 Feb 2014) Changed paths: A Keymapping-KeyCombinations.package/KMCommandModifier.class/README.md A Keymapping-KeyCombinations.package/KMCommandModifier.class/definition.st A Keymapping-KeyCombinations.package/KMCommandModifier.class/instance/comparing/=.st A Keymapping-KeyCombinations.package/KMCommandModifier.class/instance/comparing/hash.st A Keymapping-KeyCombinations.package/KMCommandModifier.class/instance/initialization/initialize.st A Keymapping-KeyCombinations.package/KMCommandModifier.class/instance/matching/matchesEvent_.st A Keymapping-KeyCombinations.package/KMCommandModifier.class/instance/private/delegatedModifier.st M Keymapping-KeyCombinations.package/KMMetaModifier.class/instance/initialization/initialize.st M Keymapping-KeyCombinations.package/KMModifiedKeyCombination.class/instance/comparing/=.st M Keymapping-KeyCombinations.package/KMModifier.class/class/instance creation/command.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script411.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30758.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30758 11573 CTRL shortcuts missing / not working under linux https://pharo.fogbugz.com/f/cases/11573 http://files.pharo.org/image/30/30758.zip

Feb. 14, 2014

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

by Johan Brichau

On 14 Feb 2014, at 11:06, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Is there a standard functional Seaside Ajax test that I can use to see this for myself ? localhost:8080/tests/functional-ajaxified WAUrlEncodingFunctionalTest enter a + in the form

Feb. 14, 2014

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

by Sven Van Caekenberghe

On 14 Feb 2014, at 10:53, Johan Brichau <johan(a)inceptive.be> wrote: > > On 14 Feb 2014, at 10:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 14 Feb 2014, at 10:34, Johan Brichau <johan(a)inceptive.be> wrote: >> >>> No, because the original request was 'foo%20%2B%20' >>> >>> If it prints it, the + should be encoded again. >> >> Why ? > > The + character in a url is decoded as a space: > > self assert: (ZnPercentEncoder new decode: '+' = ' ') Hmm, but like I said before, there are different safe sets, depending on the situation. That is was recently added. > So, because I notice that the incoming url is decoded when parsing to a ZnUrl's path segments, recoded when printed and then again decoded, the following happens: > - '%2B' (encoding of +) gets decoded to '+' (correct) > - '+' gets encoded as '+' (incorrect) > - '+' gets decoded as ' ' (correct) Where/why/how is it re-encoded and decoded ? Maybe it should happen differently in that particular case. >> How exactly is this creating problems ? > > In Seaside, when you serialize an input form using a jquery ajax request and you enter a '+' in the input form, the browser correctly encodes the '+' character to a '%2B' in the request url. > However, because the Zinc server performs the above transformation, the '+' becomes a ' ' in the incoming value of the Seaside callback. > > The + is not a safe character because it is an encoding of a space. Is there a standard functional Seaside Ajax test that I can use to see this for myself ? Sven

Feb. 14, 2014

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

by Johan Brichau

On 14 Feb 2014, at 10:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > On 14 Feb 2014, at 10:34, Johan Brichau <johan(a)inceptive.be> wrote: > >> No, because the original request was 'foo%20%2B%20' >> >> If it prints it, the + should be encoded again. > > Why ? The + character in a url is decoded as a space: self assert: (ZnPercentEncoder new decode: '+' = ' ') So, because I notice that the incoming url is decoded when parsing to a ZnUrl's path segments, recoded when printed and then again decoded, the following happens: - '%2B' (encoding of +) gets decoded to '+' (correct) - '+' gets encoded as '+' (incorrect) - '+' gets decoded as ' ' (correct) > How exactly is this creating problems ? In Seaside, when you serialize an input form using a jquery ajax request and you enter a '+' in the input form, the browser correctly encodes the '+' character to a '%2B' in the request url. However, because the Zinc server performs the above transformation, the '+' becomes a ' ' in the incoming value of the Seaside callback. The + is not a safe character because it is an encoding of a space. Johan

Feb. 14, 2014

Re: [Pharo-dev] ARM, Raspbian: Good new everyone, Raspbian display is now fixed

by Jean Baptiste Arnaud

I just fix a bug in atomic operation for arm processor virtual machine. In fact event launch a semaphore that never end (because the atomic operation never update predecessor). So I guess the answer is no, because I do not change anything else. On 13 Feb 2014, at 19:21, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Just a question: did you switch back to bitmap fonts? > > > 2014-02-13 19:01 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Very nice, I will try it over the weekend ! > Thanks! > > On 13 Feb 2014, at 18:38, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: > > > Small picture for you: > > > > <photo.jpeg> > > On 13 Feb 2014, at 18:27, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: > > > Best Regards Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

Feb. 14, 2014

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

by Sven Van Caekenberghe

On 14 Feb 2014, at 10:34, Johan Brichau <johan(a)inceptive.be> wrote: > No, because the original request was 'foo%20%2B%20' > > If it prints it, the + should be encoded again. Why ? Here, but also in most of my other packages, the parsers are more lenient than the specs, to support common practice, but stricter when generating output. So any percent-encoded character is accepted [ but being encoded means that its meaning as structuring element is lost, consider $/ ], not necessarily encoded on output. WAUrl does it indeed, but that is because it considers $+ unsafe, which is not correct (Zn did that as well before, in the 'better safe than sorry' philosophy). How exactly is this creating problems ? > On 14 Feb 2014, at 10:31, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 14 Feb 2014, at 10:25, Johan Brichau <johan(a)inceptive.be> wrote: >> >>> 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' >> >> But that is correct, no ? >> >> ZnResourceMetaUtils urlPathSafeSet includes: $+ >> >> + is a normal URL path character, Character space is not. >> >> It is possible that Zn did something else earlier, but now it is (more) correct ;-) >> >>> 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

[pharo-project/pharo-core]

by GitHub

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

Feb. 14, 2014

[pharo-project/pharo-core] 4ee8c1: 30757

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 4ee8c19ec9cfb20bd82837a85da8a507ccf55121 https://github.com/pharo-project/pharo-core/commit/4ee8c19ec9cfb20bd82837a8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-02-14 (Fri, 14 Feb 2014) Changed paths: M Graphics-Transformations.package/IdentityTransform.class/README.md M HudsonBuildTools20.package/HDChangeReport.class/README.md M HudsonBuildTools20.package/HDCoverageReport.class/README.md M HudsonBuildTools20.package/HDLintReport.class/README.md M HudsonBuildTools20.package/HDReport.class/README.md M HudsonBuildTools20.package/HDTestCoverage.class/README.md M HudsonBuildTools20.package/HDTestReport.class/README.md M OpalCompiler-Core.package/OCUndeclaredVariableWarning.class/instance/correcting/openMenuIn_.st A OpalCompiler-Core.package/OCUndeclaredVariableWarning.class/instance/correcting/substituteVariableNamed_.st R OpalCompiler-Core.package/OCUndeclaredVariableWarning.class/instance/correcting/substituteVariable_atInterval_.st A OpalCompiler-Core.package/extension/RBVariableNode/instance/substituteVariableNamed_.st M ProfStef-Tests.package/AbstractTutorialTest.class/README.md M ProfStef-Tests.package/HowToMakeYourOwnTutorialTest.class/README.md R ProfStef-Tests.package/HowToMakeYourOwnTutorialTest.class/instance/as yet unclassified/testEachSelectorExists.st R ProfStef-Tests.package/HowToMakeYourOwnTutorialTest.class/instance/as yet unclassified/testedTutorial.st A ProfStef-Tests.package/HowToMakeYourOwnTutorialTest.class/instance/tests/testEachSelectorExists.st A ProfStef-Tests.package/HowToMakeYourOwnTutorialTest.class/instance/tests/testedTutorial.st M ProfStef-Tests.package/LessonTestInstanciation.class/README.md M ProfStef-Tests.package/MockLessonView.class/README.md M ProfStef-Tests.package/MockTutorial.class/README.md M ProfStef-Tests.package/MockTutorial2.class/README.md M ProfStef-Tests.package/ProfStefHelpTest.class/README.md M ProfStef-Tests.package/ProfStefHelpTutorialBuilderTest.class/README.md M ProfStef-Tests.package/ProfStefTestGo.class/README.md M ProfStef-Tests.package/ProfStefTestGoOnMockTutorial.class/README.md M ProfStef-Tests.package/ProfStefTestNavigation.class/README.md M ProfStef-Tests.package/SmalltalkSyntaxTutorialTest.class/README.md M ProfStef-Tests.package/TTutorialTest.class/README.md M ProfStef-Tests.package/TutorialPlayerTestTutorialAccessor.class/README.md M ProfStef-Tests.package/TutorialPlayerTestWithMockTutorial.class/README.md M RPackage-Core.package/RPackageAnnouncement.class/README.md M RPackage-SystemIntegration.package/ClassRepackaged.class/README.md M RPackage-SystemIntegration.package/MethodRepackaged.class/README.md M RPackage-SystemIntegration.package/PackageChecker.class/README.md M RPackage-Tests.package/RPackageCategorySynchronisationTest.class/README.md M RPackage-Tests.package/RPackageClassesSynchronisationTest.class/README.md M RPackage-Tests.package/RPackageCompleteSetupButForModificationTest.class/README.md M RPackage-Tests.package/RPackageExtensionMethodsSynchronisationTest.class/README.md M RPackage-Tests.package/RPackageImportFromPackageInfoTest.class/README.md M RPackage-Tests.package/RPackageMethodsSynchronisationTest.class/README.md M RPackage-Tests.package/RPackageMonticelloSynchronisationTest.class/README.md M RPackage-Tests.package/RPackageObsoleteTest.class/README.md M RPackage-Tests.package/RPackageTagTest.class/README.md M RPackage-Tests.package/RPackageTest.class/README.md M RPackage-Tests.package/RPackageTestCase.class/README.md M RPackage-Tests.package/RPackageTraitSynchronisationTest.class/README.md M RPackage-Tests.package/RPackageTraitTest.class/README.md M RPackage-Tests.package/RPackageWithDoTest.class/README.md M RPackage-Tests.package/TestRPackagePrequisites.class/README.md A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script410.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30757.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30757 12662 "Unknown Variable" name correction doesnt work properly in Nautilus https://pharo.fogbugz.com/f/cases/12662 12864 Class comments missing in package Hudson https://pharo.fogbugz.com/f/cases/12864 12866 Class comments missing in package ProfStef https://pharo.fogbugz.com/f/cases/12866 12867 Class comments missing for RPackage package https://pharo.fogbugz.com/f/cases/12867 12863 Class comments missing in Graphics-Transformations package https://pharo.fogbugz.com/f/cases/12863 http://files.pharo.org/image/30/30757.zip

Feb. 14, 2014

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

by Johan Brichau

No, because the original request was 'foo%20%2B%20' If it prints it, the + should be encoded again. On 14 Feb 2014, at 10:31, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 14 Feb 2014, at 10:25, Johan Brichau <johan(a)inceptive.be> wrote: > >> 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' > > But that is correct, no ? > > ZnResourceMetaUtils urlPathSafeSet includes: $+ > > + is a normal URL path character, Character space is not. > > It is possible that Zn did something else earlier, but now it is (more) correct ;-) > >> 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

On 14 Feb 2014, at 10:25, Johan Brichau <johan(a)inceptive.be> wrote: > 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' But that is correct, no ? ZnResourceMetaUtils urlPathSafeSet includes: $+ + is a normal URL path character, Character space is not. It is possible that Zn did something else earlier, but now it is (more) correct ;-) > 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