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

Re: [Pharo-dev] ZnUrl and closePath

by Sven Van Caekenberghe

Norbert, > On 29 Apr 2015, at 13:07, Norbert Hartl <norbert(a)hartl.name> wrote: > > I'm not sure the behaviour of ZnUrl>>#closePath is the desired one. > > 'http://foo/a/b/c/' asZnUrl closePath > > gives > > http://foo/a/b/c// > > It adds a slash if the #isSlash returns false. #isSlash indicated only the server root and not (what I was thinking) it returns true on trailing slash. > IMHO #isSlash should be a test for trailing slash and #isRootPath should be a test for a non-existing or / path. > > Norbert #isSlash was/is intended to be what it is, but indeed #closePath could maybe be improved. What about closePath self isDirectoryPath ifFalse: [ self addPathSegment: #/ ] ? Would that work for your use case ? Sven

April 29, 2015

Re: [Pharo-dev] http redirect with post

by Sven Van Caekenberghe

Yes of course, === Name: Zinc-HTTP-SvenVanCaekenberghe.427 Author: SvenVanCaekenberghe Time: 29 April 2015, 1:48:34.126253 pm UUID: 9b1a2aff-3a0b-4373-b081-dcc3b99b2665 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.426 Treat 308 the same as 307 in ZnClient>>#prepareRedirect - duh. (Thx Norbert Hartl) === Thanks for the feedback. > On 29 Apr 2015, at 11:59, Norbert Hartl <norbert(a)hartl.name> wrote: > > Btw. same goes for 308 :) > > Norbert > >> Am 29.04.2015 um 11:44 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> Hi Norbert, >> >>> On 28 Apr 2015, at 22:55, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> Hi Sven, >>> >>> I have a topic for your todo list :) If an http client encounters a redirect with status code 307 it should redirect using the same method and entity as it got in the initial request. Now the client turns the request into a GET request. >>> >>> What do you think? >>> >>> Norbert >> >> You are right, this should be added. >> >> There is only one way to keep a todo list short (in #bleedingEdge): >> >> === >> Name: Zinc-HTTP-SvenVanCaekenberghe.426 >> Author: SvenVanCaekenberghe >> Time: 29 April 2015, 11:42:28.173752 am >> UUID: ae602342-e209-4a88-bf07-8a87776cc095 >> Ancestors: Zinc-HTTP-SvenVanCaekenberghe.425 >> >> Modify ZnClient>>#prepareRedirect to implement 307 behavior (keep method and entity as is) >> >> Add ZnClientTests>>#testRelativeRedirect307 >> === >> Name: Zinc-Tests-SvenVanCaekenberghe.225 >> Author: SvenVanCaekenberghe >> Time: 29 April 2015, 11:42:46.710579 am >> UUID: f9f4164f-0885-4aaf-89db-84f0aa24cde3 >> Ancestors: Zinc-Tests-SvenVanCaekenberghe.224 >> >> Modify ZnClient>>#prepareRedirect to implement 307 behavior (keep method and entity as is) >> >> Add ZnClientTests>>#testRelativeRedirect307 >> === >> >> Does this work for you ? >> >> Sven >> >

April 29, 2015

Re: [Pharo-dev] [Review] Issue 14080: Nuke remaining subStringXyz's

by Sean P. DeNigris

Luc Fabresse wrote > Congrats Sean for this one! > It impacts on a lot of external packages... Thanks, Luc! The whole time I was working on this, I was thinking "there is not enough value in a simple rename to be worth all this work". But now, I'm really glad I finished it for one reason - now I know it can be done! What I mean is that IIRC it would have been way more complicated and scary to do that change a few years ago without Jenkins, Penelope, slices, a group of immediately available reviewers/integrators, etc. I clearly experienced the compounded value of all of the infrastructure we have built. Now that I know we have the structures necessary to support broad changes to the system, I am dreaming about what to do next... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Review-Issue-14080-Nuke-remaining-subStringXyz-s-tp48… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 29, 2015

Re: [Pharo-dev] Collecting user data

by roberto.minelli＠usi.ch

+1 I couldnât agree more with Andrei. I believe that we should have a common infrastructure, at least, to define which level of details tools are allowed to collect/send for research purposes. I envision a settingâs panel in which the user has a list of tools collecting data with their own settings and the user can freely select which tools are allowed to collect her data. I had another idea, a âresearch imageâ. Let me explain, people are struggling to install tools that are not part of the standard image. On the other hand, having your research tool part of the standard image, is not easy for a number of reasons. So what about having a âresearch imageâ that allows researcher to install and distribute their own tools? Brave developers, for their free time project, could use this image instead of the standard distribution, benefit from the innovative (but in early stage) tools and contribute to the data collection mechanisms? Cheers, Roberto > On 28 Apr 2015, at 14:35, Tommaso Dal Sasso <tommaso.dalsasso(a)gmail.com> wrote: > > +1 for me. > > Having a centralized way of managing data submission would simplify > things a lot for people collecting data, but also for users who could > check in one place all the kind of data they send. > > Tommaso > > On 28/04/15 14:31, Andrei Chis wrote: >> Yes, some level of unification would be nice, especially for the part >> about users agreeing to send usage data and persisting that setting. >> Also at least two general levels of details about what data is being >> send that tools should follow would help (full anonymous vs. include >> class names/method names ?). >> Last but not least, a single entry point for sending that data over the >> network would help. >> >> How data is collected/stored will differ from tool to tool, but agreeing >> on the previous aspects would make it much easier to collect data. >> >> Cheers, >> Andrei >> >> On Tue, Apr 28, 2015 at 1:18 PM, Marcus Denker <marcus.denker(a)inria.fr >> <mailto:marcus.denker@inria.fr>> wrote: >> >> >>> On 28 Apr 2015, at 11:42, Yuriy Tymchuk <yuriy.tymchuk(a)me.com >> <mailto:yuriy.tymchuk@me.com>> wrote: >>> >>> Hi guys, >>> >>> from time to time we have to collect a usage data in order to >> improve our tools. For example Iâd like to collect data in future >> about how do you treat code critics: do they occur, do you outfox >> them, do you mark them as false positives? If we had answers to >> these questions, we could really make good and helpful critics. >>> >>> For now I know that there are 3 projects which collect data: >>> - GTSpotter >>> - Shoreline >>> - DFlow (not in image by default). >>> >>> Should I make 4th data collection for QualityAssistant? Or maybe >> we can do some unification? >>> >> >> I would love unification! >> >> Itâs not only good for the researchers, but even for the user: I do >> not want to decide 5 times to give data to research, >> but I want to decide it onceâ¦ >> >> Marcus

April 29, 2015

[pharo-project/pharo-core] 5c2208: 50021

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 5c2208342bfd2fb5ad4c955eca5100a9f6707759 https://github.com/pharo-project/pharo-core/commit/5c2208342bfd2fb5ad4c955e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-04-29 (Wed, 29 Apr 2015) Changed paths: M ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version2013_.st M ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version212_.st M ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic versions/stable_.st A ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version122_.st M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version302_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/baselines/baseline32_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/development_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version312_.st M GT-Inspector.package/GTObjectVariablesBrowser.class/instance/private building/stringWithoutInitialCommentFrom_.st A GT-InspectorExtensions-Core.package/extension/MCRepository/instance/gtInspectorGoferReferencesIn_.st A GT-SpotterExtensions-Core.package/extension/HelpTopic/instance/spotterActDefault.st R Glamour-Morphic-Renderer.package/GLMMorphicRenderer.class/instance/rendering presentations/renderInputPresentation_.st R Glamour-Presentations.package/GLMInputPresentation.class/README.md R Glamour-Presentations.package/GLMInputPresentation.class/definition.st R Glamour-Presentations.package/GLMInputPresentation.class/instance/rendering/renderGlamorouslyOn_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script629.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script630.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50020.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50021.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50021 ConfigurationOfRubric http://files.pharo.org/image/50/50021.zip

April 29, 2015

[pharo-project/pharo-core]

by GitHub

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

April 29, 2015

Re: [Pharo-dev] [Reflectivity] tiny step: conditions for links

by Sean P. DeNigris

Marcus Denker-4 wrote > haltLink := MetaLink new > condition: false; > metaObject: Halt; > selector: #now. Pretty :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Reflectivity-tiny-step-conditions-for-links-tp4822570… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 29, 2015

ZnUrl and closePath

by Norbert Hartl

I'm not sure the behaviour of ZnUrl>>#closePath is the desired one. 'http://foo/a/b/c/' asZnUrl closePath gives http://foo/a/b/c// <http://foo/a/b/c//> It adds a slash if the #isSlash returns false. #isSlash indicated only the server root and not (what I was thinking) it returns true on trailing slash. IMHO #isSlash should be a test for trailing slash and #isRootPath should be a test for a non-existing or / path. Norbert

April 29, 2015

Re: [Pharo-dev] http redirect with post

by Norbert Hartl

And a big thanks of course. Sadly I need it where I can not update. But I solved it another way. Norbert > Am 29.04.2015 um 11:59 schrieb Norbert Hartl <norbert(a)hartl.name>: > > Btw. same goes for 308 :) > > Norbert > >> Am 29.04.2015 um 11:44 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> Hi Norbert, >> >>> On 28 Apr 2015, at 22:55, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> Hi Sven, >>> >>> I have a topic for your todo list :) If an http client encounters a redirect with status code 307 it should redirect using the same method and entity as it got in the initial request. Now the client turns the request into a GET request. >>> >>> What do you think? >>> >>> Norbert >> >> You are right, this should be added. >> >> There is only one way to keep a todo list short (in #bleedingEdge): >> >> === >> Name: Zinc-HTTP-SvenVanCaekenberghe.426 >> Author: SvenVanCaekenberghe >> Time: 29 April 2015, 11:42:28.173752 am >> UUID: ae602342-e209-4a88-bf07-8a87776cc095 >> Ancestors: Zinc-HTTP-SvenVanCaekenberghe.425 >> >> Modify ZnClient>>#prepareRedirect to implement 307 behavior (keep method and entity as is) >> >> Add ZnClientTests>>#testRelativeRedirect307 >> === >> Name: Zinc-Tests-SvenVanCaekenberghe.225 >> Author: SvenVanCaekenberghe >> Time: 29 April 2015, 11:42:46.710579 am >> UUID: f9f4164f-0885-4aaf-89db-84f0aa24cde3 >> Ancestors: Zinc-Tests-SvenVanCaekenberghe.224 >> >> Modify ZnClient>>#prepareRedirect to implement 307 behavior (keep method and entity as is) >> >> Add ZnClientTests>>#testRelativeRedirect307 >> === >> >> Does this work for you ? >> >> Sven >> > >

April 29, 2015

[pharo-project/pharo-core] 8695ff: 50020

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 8695ff6e3852ca96ef8ea27336d58075b884aa91 https://github.com/pharo-project/pharo-core/commit/8695ff6e3852ca96ef8ea273… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-04-29 (Wed, 29 Apr 2015) Changed paths: M ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/baselines/baseline20_.st M ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/stable_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1211_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1212_.st M Rubric.package/RubAbstractTextArea.class/README.md M Rubric.package/RubAbstractTextArea.class/instance/find-replace/findNextString_startingAt_.st M Rubric.package/RubExtraSelectionDecorator.class/instance/drawing/computeSecondarySelectionShapesFrom_to_.st M Rubric.package/RubSmalltalkEditor.class/instance/typing support/keystroke_.st M Rubric.package/RubTextEditor.class/instance/find-select/findNextString_startingAt_.st M Rubric.package/RubTextEditor.class/instance/typing support/keystroke_.st M Rubric.package/RubTextFieldArea.class/README.md M Rubric.package/RubTextFieldArea.class/instance/event handling/keyStroke_.st A Rubric.package/RubTextFieldArea.class/instance/private/handleReturnKey.st M Rubric.package/RubTextFieldArea.class/instance/private/privateReplaceFrom_to_with_.st A Rubric.package/RubTextFieldArea.class/instance/private/sanitize_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script628.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script629.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50019.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50020.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50020 15438 Update Rubric https://pharo.fogbugz.com/f/cases/15438 15440 remove deprecated references to #allRangesOfSubString: in TextMorphForEditView https://pharo.fogbugz.com/f/cases/15440 http://files.pharo.org/image/50/50020.zip

April 29, 2015