September 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Author / TestRunner interaction in fresh image

by Denis Kudriashov

Hi. 2016-09-15 18:38 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > The question arises in this particular case due to... > RPackageMonticelloSynchronisationTest >> setUp > ... > Author fullName ifNil: [ Author fullName: 'Tester' ]. > > Minor point... this check actually is a bit pointless since #fullName > invokes #requestFullName that presents the dialog. And #fullName will > *never* return nil. At a minimum it returns 'Anonymous'. > > First step would seem to be wrapping TestCase>>runCase: > with Author useAuthor: 'TestRunner' during: [ .... ] > Now with introduction of ExecutionEnvironment we could delegate this behaviour to it. So DefaultExecutionEnvironment will perform regular UI request but TestExecutionEnvironment will set up special "TestRunner name". We could define CurrentExecutionEnvironment>>systemUser to hide this logic

Sept. 16, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

by Ben Coman

On Fri, Sep 16, 2016 at 3:02 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2016-09-16 8:54 GMT+02:00 stepharo <stepharo(a)free.fr>: >> >> >>> Furthermore, typical examples require more than one liners, and these >>> should be factored out separately. >> >> >> I really like the one liners that you can find im some method comments, >> like in Color class>>#wheel: >> if you are new to pharo and start exploring the system, it makes fun to >> see these little one lines and >> just execute it. (even if they aren't onelines like in some method in >> class Form). >> >> >> Me too and what I like is that there are coupled to the method. >> I find a method and I guess it will help me >> and bam I read the example and I'm sure it is or not what I'm looking for. > > > My belief is that we have an IDE able to track metadata (here, examples) > along with methods, and that there is no need to play with syntax extensions > (which are a way of adding metadata to programming languages stuck in the > file concept of the 60's). > > In short, a nice, OO way of adding information about a method / class / tag > / package that the IDE knows how to relate to the code. > > Having the class comment pane open in Nautilus is already a step towards > doing that. So another way to look at keeping example/tests close to the methods is for the Browser code pane to have tabs [Source] [Examples] [Tests] [Class Comment] where maybe [Tests] lists every test containing the selection from the method pane. Adding these same to GTDebugger (which already has a [Source] tab) would improve inter-tool consistency. Spare vertical space for the code-pane tabs might be obtained if the <claass> button is replaced by a class/instance treeview protocol-pane tree view, then <Class> button goes away, the <Hier.> button could move above the class-pane leaving a spare row for the code pane tabs to sit. Attached is a rough mockup. cheers -ben

Sept. 16, 2016

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

by Esteban Lorenzano

> On 16 Sep 2016, at 10:02, Guille Polito <guillermopolito(a)gmail.com> wrote: > > Hi, > > I was thinking on the metro way to work, and I also saw that this discussion is actually split in multiple threads, so it was not easy to follow :). > > Some of my feelings about this: > > - Pragmas are nice because they are easy to "interpret". Parsing them is already provided. However, putting expressions or long examples into them starts to be awkward. It seems it's pushin the syntax too much, isn't it? > > - Comments are nice because they are ignored! But right now comments are simple plain text. This thread is to convert *some* comments into executable examples. But this should be just some comments and not all of them, am I right? So what happens when we want to have comments written in Pillar for example? What I mean is that having examples is just an example of something we would like to do with comments. > > But we can also imagine having comment interpreters. Something like this: > > ">>>PillarDoc > !This is a Pillar title > And I'm just a paragraph > And I can link a class like @Object. > " > > > ">>>ExampleDoc > self assert: '/foo/gloops.taz' asFileReference basename equals: 'gloops.taz' > " > > What I like from this is that: > - comments that do not specify an interpreter are just plain old text. Thus backward compatible. > - comments that specify an interpreter that is not present, are just plain old text. A decoupling as it happens with the settings. > - an ExampleDoc interpreter can be just a test case instance, thus we could use assertions instead of special >>> messages. > > Things that would require more thought: > - there is an overlap between these interpreted comments and pragmas... There are for sure cases that solutions can be imagined with both. > - there is an overlap between examples and test cases. I saw many people that argued that already. I am not against examples, but I think we should (whichever implementation is chosen) draw a line and set some guidelines. Stef, probably you have already in mind when you want a test case and when an example and what's the distance. It would be good if we can transform that implicit thought in something explicit (maybe even a lint rule in the future?) +1 to all :) Esteban > > Guille > > -------- Original Message -------- >> Hi nicolai >> >> >> I was thinking that I would prefer to have >> >> "` '/foo/gloops.taz' asFileReference basename -> 'gloops.taz'.`" >> >> >> instead of >> ` '/foo/gloops.taz' asFileReference basename -> 'gloops.taz'.` <- suceeds, no output >> >> So that we can use ` in the future in plain code. >> Also it has the advantage that it is backward compatible. >> >> Else we could have >> >> `` >> But I do not know. >> >> Tell me what you think. >> >> I would love to browse the complete system to convert existing one liner with such >> >> Stef >> >>> >>> Ok, this is a quick hack ( do not look at the code :), yes using regex here is a bit fragil) >>> >>> You can add code in comments between backticks (`) >>> The formatter will highlight the text like smalltalk code (or not if it is not valid code). >>> + an icon styler with an icon showing a warning icon for faulty code or an information icon otherwise >>> you can click on the icon, >>> >>> if the code is an association >>> >>> expression -> result >>> >>> it executes the expression and compares it with the result, (with assert:equals: ) opens debugger if it fails and does >>> nothing otherwise >>> >>> if the code is just an expression, it opens an inspector. >>> >>> This is just one way to do some tests and experiments with this idea, don 't yet know if this is a good idea or if >>> we can / should find a better way to connect code with examples. >>> >>> first result, I find expressions in comments, highlighted as code, confusing :) >>> >>> (file in attached cs in a recent pharo 6.0 and look at the method AbstractFileReference>>#baseName . Or >>> add an expression with backticks in a method comment >>> ` your code here ` >>> >>> >>> >>> >>> Stef >>> >>> >>> >> >

Sept. 16, 2016

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

by Serge Stinckwich

On Thu, Sep 15, 2016 at 10:09 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I think this is an interesting idea. > > However, one thing to keep in mind is that one reason why these solutions exist is because they assume no UI environment. Thus, the only thing they have is text and the solution is built around it. > > In Pharo, we can think of concatenating information in the environment. If we have a casual connection between examples and the code they exemplify, the interface can provide all this information at the same time. The advantage here is that the syntax remains simple. > > At the same time, we also want to have Pillar more thoroughly supported in our tools. Could it be that we could extend Pillar to support literate programming? Just I backup this idea. You should have a look to http://orgmode.org/ with babel mode that allows to mix different programming languages in the same document: http://orgmode.org/worg/org-contrib/babel/ Lot of ideas should be borrowed for doing a better Pillar I guess. The only problem of org-mode is that you don't have the link to the live environment that we are used to. Having a org-mode clone in Pharo (i.e Pillar+++) would be great. At the same time, this is a long term solution. We also need an immediate solution like the one proposed by StÃ©phane. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Sept. 16, 2016

Re: [Pharo-dev] 60224 TestRunner warning Collections-Arithmetic manually resolved dependency not detected as a dependency!

by Guille Polito

Some dependendies cannot be easily detected in a static way. For example, when you use reflection, or when you send a polymorphic message that has implementations over many packages. In such cases, it is not obvious for the tool to see what is the actual dependency. Then, the user can resolve it manually => this goes to the manuallyResolvedDependencies. In general terms, the dependency analyzer does this: - it checks all dependencies of the package (all classes it depends, all messages sent that are not defined in the package itself) - then it checks if it can find a package for each of them. Classes are easy. Messages not so. - At the end, the intersection between the dependent packages and the manually resolved ones should be the manually resolved packages. Otherwise it means that you have manually resolved packages that are obsolete and need to be updated. Hope this clarifies a bit. If not keep asking ^^. Guille -------- Original Message -------- > This curious warning appeared when running TestRunner in a fresh > 60224.image... Collections-Abstract: Collections-Arithmetic dependency > declared in the package Manifest as manuallyResolvedDependencies not > detected as a dependency! > > There is... > ManifestCollectionsArithmetic class >> dependencies > ^ #(#'Collections-Native' #'Collections-Unordered' > #'Collections-Sequenceable' #Kernel #'Collections-Abstract') > > and removing the last element makes the error go away, but I was > wondering if that was the RightThing or the warning was a symptom for > something else? > > btw, was is "manually resolved" ? Is it just adding elements to #dependencies? > > cheers -ben >

Sept. 16, 2016

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

by Guille Polito

Hi, I was thinking on the metro way to work, and I also saw that this discussion is actually split in multiple threads, so it was not easy to follow :). Some of my feelings about this: - Pragmas are nice because they are easy to "interpret". Parsing them is already provided. However, putting expressions or long examples into them starts to be awkward. It seems it's pushin the syntax too much, isn't it? - Comments are nice because they are ignored! But right now comments are simple plain text. This thread is to convert *some* comments into executable examples. But this should be just some comments and not all of them, am I right? So what happens when we want to have comments written in Pillar for example? What I mean is that having examples is just an example of something we would like to do with comments. But we can also imagine having comment interpreters. Something like this: ">>>PillarDoc !This is a Pillar title And I'm just a paragraph And I can link a class like @Object. " ">>>ExampleDoc self assert: '/foo/gloops.taz' asFileReference basename equals: 'gloops.taz' " What I like from this is that: - comments that do not specify an interpreter are just plain old text. Thus backward compatible. - comments that specify an interpreter that is not present, are just plain old text. A decoupling as it happens with the settings. - an ExampleDoc interpreter can be just a test case instance, thus we could use assertions instead of special >>> messages. Things that would require more thought: - there is an overlap between these interpreted comments and pragmas... There are for sure cases that solutions can be imagined with both. - there is an overlap between examples and test cases. I saw many people that argued that already. I am not against examples, but I think we should (whichever implementation is chosen) draw a line and set some guidelines. Stef, probably you have already in mind when you want a test case and when an example and what's the distance. It would be good if we can transform that implicit thought in something explicit (maybe even a lint rule in the future?) Guille -------- Original Message -------- > > Hi nicolai > > > I was thinking that I would prefer to have > > > "` '/foo/gloops.taz' asFileReference basename -> 'gloops.taz'.`" > > > instead of > ` '/foo/gloops.taz' asFileReference basename -> 'gloops.taz'.` <- > suceeds, no output > > So that we can use ` in the future in plain code. > Also it has the advantage that it is backward compatible. > > Else we could have > > `` > But I do not know. > > Tell me what you think. > > I would love to browse the complete system to convert existing one > liner with such > > Stef > >> >> Ok, this is a quick hack ( do not look at the code :), yes using >> regex here is a bit fragil) >> >> You can add code in comments between backticks (`) >> The formatter will highlight the text like smalltalk code (or not if >> it is not valid code). >> + an icon styler with an icon showing a warning icon for faulty code >> or an information icon otherwise >> you can click on the icon, >> >> if the code is an association >> >> expression -> result >> >> it executes the expression and compares it with the result, (with >> assert:equals: ) opens debugger if it fails and does >> nothing otherwise >> >> if the code is just an expression, it opens an inspector. >> >> This is just one way to do some tests and experiments with this idea, >> don 't yet know if this is a good idea or if >> we can / should find a better way to connect code with examples. >> >> first result, I find expressions in comments, highlighted as code, >> confusing :) >> >> (file in attached cs in a recent pharo 6.0 and look at the method >> AbstractFileReference>>#baseName . Or >> add an expression with backticks in a method comment >> ` your code here ` >> >> >> >> Stef >> >> >> >

Sept. 16, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 4d8aa6: 60226

by Pavel Krivanek

error not related, build works well after restart -- Pavel 2016-09-15 22:11 GMT+02:00 stepharo <stepharo(a)free.fr>: > This change break the miniimage. I will check with pavel. > > Stef > > > Le 15/9/16 Ã 22:05, GitHub a Ã©crit : > > Branch: refs/heads/6.0 >> Home: https://github.com/pharo-project/pharo-core >> Commit: 4d8aa66f6cb150f6aef66a9d807106bb89404cf5 >> https://github.com/pharo-project/pharo-core/commit/4d8aa66f >> 6cb150f6aef66a9d807106bb89404cf5 >> Author: Jenkins Build Server <board(a)pharo-project.org> >> Date: 2016-09-15 (Thu, 15 Sep 2016) >> >> Changed paths: >> M FontChooser.package/AbstractFontSelectorDialogWindow.class/ >> class/icons/taskbarIcon.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousAccept.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousAdd.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousAlarm.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousBookmark.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousBrowse.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousBug.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousCancel.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousClose.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousDown.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousDropDown.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousEdit.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousExample.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousFolder.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousGo.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousGrayCircle.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousGrayCircleEmpty.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousGreenCircle.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousHelp.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousInspect.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousInto.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousLargeGrayCircleEmphasized.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousLeft.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousLeftSide.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousMore.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousOpen.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousOpenFromUrl.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousOver.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousPlay.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousRedCircle.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousRedo.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousRefresh.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousRemove.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousRestart.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousRight.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousRightSide.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousSave.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousSaveToUrl.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousSearch.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousSpawn.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousThrough.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousTrash.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousUndo.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousUp.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousZoomIn.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousZoomOut.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamorousZoomToFit.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamourousNextFailure.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamourousNextParser.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla >> ss/icons/glamourousNextProduction.st >> M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/def >> inition.st >> M HelpSystem-Core.package/ClassAPIHelpBuilder.class/instance/private >> building/buildSubnodesForMethods.st >> M HelpSystem-Core.package/ClassAPIHelpBuilder.class/instance/private >> building/buildSubnodesForSubclasses.st >> M MonticelloGUI.package/MCSaveVersionDialog.class/class/icons/ >> taskbarIcon.st >> M MonticelloGUI.package/MCVersionInspector.class/class/icons/ >> taskbarIcon.st >> M MonticelloGUI.package/MCWorkingCopyBrowser.class/class/ >> icons/taskbarIcon.st >> A Morphic-Base.package/MenuMorph.class/class/icons/iconNamed_.st >> M Morphic-Base.package/MenuMorph.class/class/private - >> utilities/confirm_trueChoice_falseChoice_.st >> A Morphic-Core.package/Morph.class/class/icons/iconNamed_.st >> A Morphic-Core.package/Morph.class/instance/icons/iconNamed_.st >> M Morphic-Examples.package/WidgetExamples.class/class/examples >> /exampleGroups.st >> M Morphic-Examples.package/WidgetExamples.class/class/examples >> /exampleWindowWithToolbars.st >> M Morphic-Examples.package/WidgetExamples.class/definition.st >> M Morphic-Widgets-Basic.package/ThreePhaseButtonMorph.class/class/instance >> creation/checkBox.st >> M Morphic-Widgets-Basic.package/ThreePhaseButtonMorph.class/class/instance >> creation/radioButton.st >> M Morphic-Widgets-PolyTabs.package/TabGroupMorph.class/class/ >> example/example.st >> M Morphic-Widgets-Windows.package/SystemWindow.class/class/ >> icons/taskbarIcon.st >> M Morphic-Widgets-Windows.package/SystemWindow.class/class/menu >> items/windowMenuOn_.st >> M Nautilus.package/CategoryWidget.class/instance/icon/ >> categoryIconFor_.st >> M Nautilus.package/NautilusMonticello.class/class/monticello >> menus/packagesChangesMenu_.st >> M Nautilus.package/NautilusMonticello.class/class/monticello >> menus/packagesCommitsMenu_.st >> M Nautilus.package/NautilusMonticello.class/class/monticello >> menus/packagesCreateMenu_.st >> M Nautilus.package/NautilusMonticello.class/class/monticello >> menus/packagesOpenMenu_.st >> M Nautilus.package/NautilusMonticello.class/definition.st >> M Polymorph-Widgets.package/AboutDialogWindow.class/class/instance >> creation/openForPharo.st >> M Polymorph-Widgets.package/AlertDialogWindow.class/class/icon >> s/taskbarIcon.st >> M Polymorph-Widgets.package/ChooseDropListDialogWindow.class/ >> class/icons/taskbarIcon.st >> M Polymorph-Widgets.package/DenyDialogWindow.class/class/icons >> /taskbarIcon.st >> M Polymorph-Widgets.package/ErrorDialogWindow.class/class/icon >> s/taskbarIcon.st >> M Polymorph-Widgets.package/MessageDialogWindow.class/class/ >> icons/taskbarIcon.st >> M Polymorph-Widgets.package/PopupChoiceDialogWindow.class/clas >> s/icons/taskbarIcon.st >> M Polymorph-Widgets.package/ProceedDialogWindow.class/class/ >> icons/taskbarIcon.st >> M Polymorph-Widgets.package/TextEditorDialogWindow.class/class >> /icons/taskbarIcon.st >> M ProfStef-Core.package/ProfStef.class/class/zen/menuCommandOn_.st >> M ProfStef-Core.package/ProfStef.class/definition.st >> M RecentSubmissions.package/RecentMessageList.class/class/icons/ >> icon.st >> M SUnit-UI.package/TestRunner.class/class/icons/taskbarIcon.st >> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - >> scripts/script60225.st >> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - >> scripts/script60226.st >> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - >> updates/update60225.st >> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - >> updates/update60226.st >> M ScriptLoader60.package/ScriptLoader.class/instance/public/co >> mmentForCurrentUpdate.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> assignment/createInlineTemporary.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> class-var/createAccessors.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> class-var/createRenameClassVariable.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> class-var/createUseAccessorToVar.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> class/createBrowseReferences.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> class/createRenameClass.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> inst-var/createAccesorsFor.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> inst-var/createAccessesToVariable.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> inst-var/createRenameVariable.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> inst-var/createVariableStoresInto.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> messages/createFindImplementors.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> messages/createFindSenders.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> messages/createInline.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> methods/createAddParameter.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> methods/createBreakCommand.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> methods/createBreakConditionCommand.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> methods/createBreakOnceCommand.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> methods/createCounterCommand.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> methods/createDeprecateMethod.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> methods/createMoveMethod.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> methods/createPullUp.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> methods/createPushDown.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> methods/createRemoveMethod.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> methods/createRemoveParameter.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> methods/createRenameMethod.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> methods/createSwapMethod.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> methods/createWatchpointCommand.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> source/createExtractMethod.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> source/createExtractSentences.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> source/createExtractToLocalVariable.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> source/createFormatSourceCode.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> temp-var/createRenameTemporaryVariable.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/class/ >> unknown-var/createVariableCorrection.st >> M SmartSuggestions.package/SugsSuggestionFactory.class/definition.st >> M Spec-Core.package/TreeModel.class/class/examples/exampleWith >> CustomColumnsAndNodes.st >> M Spec-Inspector.package/AbstractEyeElement.class/definition.st >> R Spec-Inspector.package/AbstractEyeElement.class/instance/ >> icon/iconNamed_.st >> R Tool-Base.package/AbstractTool.class/instance/icon/iconNamed_.st >> M Tool-Base.package/AbstractTool.class/instance/icon/icon_.st >> R Tool-CriticBrowser.package/SingleCodeCriticResultList.class/ >> instance/initialization/setTextModelForTransformationRule_.st >> M Tool-FileList.package/FileDialogWindow.class/class/icons/ >> taskbarIcon.st >> M Tool-ProcessBrowser.package/ProcessBrowser.class/class/icons >> /taskbarIcon.st >> M Tool-Profilers.package/TimeProfiler.class/class/icons/ >> taskbarIcon.st >> M Tool-Profilers.package/TimeProfiler.class/class/opening/ >> fullReportMenuOn_.st >> M Tool-Workspace.package/Workspace.class/class/icons/taskbarIcon.st >> M Transcript.package/ThreadSafeTranscript.class/class/icons/ >> taskbarIcon.st >> M Versionner-Spec-Browser.package/VersionnerSpecBrowser.class/ >> class/icons/configurationChangedIcon.st >> M Versionner-Spec-Browser.package/VersionnerSpecBrowser.class/ >> class/icons/configurationLoadedIcon.st >> M Versionner-Spec-Browser.package/VersionnerSpecBrowser.class/ >> class/ui/menuCommandOn_.st >> M Versionner-Spec-Browser.package/VersionnerToolBar.class/ >> class/icons/loadIcon.st >> M Versionner-Spec-Browser.package/VersionnerToolBar.class/ >> class/icons/newIcon.st >> M Versionner-Spec-Browser.package/VersionnerToolBar.class/ >> class/icons/openIcon.st >> >> Log Message: >> ----------- >> 60226 >> 19094 cleaning iconNamed: >> https://pharo.fogbugz.com/f/cases/19094 >> >> http://files.pharo.org/image/60/60226.zip >> >> >> > >

Sept. 16, 2016

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

by stepharo

Hi nicolai I was thinking that I would prefer to have "` '/foo/gloops.taz' asFileReference basename -> 'gloops.taz'.`" instead of ` '/foo/gloops.taz' asFileReference basename -> 'gloops.taz'.` <- suceeds, no output So that we can use ` in the future in plain code. Also it has the advantage that it is backward compatible. Else we could have `` But I do not know. Tell me what you think. I would love to browse the complete system to convert existing one liner with such Stef > > Ok, this is a quick hack ( do not look at the code :), yes using regex > here is a bit fragil) > > You can add code in comments between backticks (`) > The formatter will highlight the text like smalltalk code (or not if > it is not valid code). > + an icon styler with an icon showing a warning icon for faulty code > or an information icon otherwise > you can click on the icon, > > if the code is an association > > expression -> result > > it executes the expression and compares it with the result, (with > assert:equals: ) opens debugger if it fails and does > nothing otherwise > > if the code is just an expression, it opens an inspector. > > This is just one way to do some tests and experiments with this idea, > don 't yet know if this is a good idea or if > we can / should find a better way to connect code with examples. > > first result, I find expressions in comments, highlighted as code, > confusing :) > > (file in attached cs in a recent pharo 6.0 and look at the method > AbstractFileReference>>#baseName . Or > add an expression with backticks in a method comment > ` your code here ` > > > > Stef > > >

Sept. 16, 2016

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

by stepharo

I will play with it :) I was thinking to have >>> instead of association to make sure that we can disambiguate from -> Thanks for the protoype. This kind of little action can change completely the face of Pharo library. I always ***LOVED*** little examples inside method when I discovered Smalltalk. This plus examples at the class side and link with nautilus execution -> gt inspector will really improve the situation. Stef Le 15/9/16 Ã 22:35, Nicolai Hess a Ã©crit : > > > 2016-09-15 20:45 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Hi all > > I want something similar in the spirit to PythonDocTest > https://docs.python.org/2/library/doctest.html > <https://docs.python.org/2/library/doctest.html> > > I'm talking about > > basename > "Returns the base of the basename, > i.e. > /foo/gloops.taz basename is 'gloops.taz' > / basename is '/'" > > Pragmas do not work well i.e., > basename > "Returns the base of the basename" > <expr: '''/foo/gloops.taz'' asFileReference basename' result: > 'gloops.taz'> > > > We should invent a syntax to be put inside comments and that we > can easily parse because we need to improve > the use and discovery of the library. > > I was thinking about > > basename > "Returns the base of the basename" > " > '/foo/gloops.taz' asFileReference basename > >>> 'gloops.taz' > " > > Do you have any idea? > > I cannot not do anything and just complain that our methods are > not that well documented. > We as a community should take this and build an super cool system. > > I tried and defined >>> on Object to see if it works! > > Object >>> aResultingObject > "If the method comment contains >>> then it is a pharo > documentated test. We can check that it is true." > > " > '/foo/gloops.taz' asFileReference basename > >>> 'gloops.taz' > " > > ^ self = aResultingObject > > > Ok, this is a quick hack ( do not look at the code :), yes using regex > here is a bit fragil) > > You can add code in comments between backticks (`) > The formatter will highlight the text like smalltalk code (or not if > it is not valid code). > + an icon styler with an icon showing a warning icon for faulty code > or an information icon otherwise > you can click on the icon, > > if the code is an association > > expression -> result > > it executes the expression and compares it with the result, (with > assert:equals: ) opens debugger if it fails and does > nothing otherwise > > if the code is just an expression, it opens an inspector. > > This is just one way to do some tests and experiments with this idea, > don 't yet know if this is a good idea or if > we can / should find a better way to connect code with examples. > > first result, I find expressions in comments, highlighted as code, > confusing :) > > (file in attached cs in a recent pharo 6.0 and look at the method > AbstractFileReference>>#baseName . Or > add an expression with backticks in a method comment > ` your code here ` > > > > Stef > > >

Sept. 16, 2016

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

by stepharo

Le 16/9/16 Ã 00:19, phil(a)highoctane.be a Ã©crit : > I'd be more interested with a package level doc than a class doc or test. It is at another level and it will come. The manisfest is here and we should update Nautilus to show other information. Now I'm curious to see how many people will use that when I see the level of description in configuration of. > Package level doc is quite useful to outline how some things are > working together, something which is quite hard to figure out except > by reading external doc or inferring things by walking through the > code or a running test. I'm the guy that propose SmallUML to embed description of UML diagram as package level 5 years ago and before that I tried to add png of diagram so I'm convinced about that. > > Having the ability to read about a package would be very useful. > Basically, this is what Java provides. > > http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/javadoc.html#p… > > Phil > > > On Thu, Sep 15, 2016 at 8:45 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi all > > I want something similar in the spirit to PythonDocTest > https://docs.python.org/2/library/doctest.html > <https://docs.python.org/2/library/doctest.html> > > I'm talking about > > basename > "Returns the base of the basename, > i.e. > /foo/gloops.taz basename is 'gloops.taz' > / basename is '/'" > > Pragmas do not work well i.e., > basename > "Returns the base of the basename" > <expr: '''/foo/gloops.taz'' asFileReference basename' result: > 'gloops.taz'> > > > We should invent a syntax to be put inside comments and that we > can easily parse because we need to improve > the use and discovery of the library. > > I was thinking about > > basename > "Returns the base of the basename" > " > '/foo/gloops.taz' asFileReference basename > >>> 'gloops.taz' > " > > Do you have any idea? > > I cannot not do anything and just complain that our methods are > not that well documented. > We as a community should take this and build an super cool system. > > I tried and defined >>> on Object to see if it works! > > Object >>> aResultingObject > "If the method comment contains >>> then it is a pharo > documentated test. We can check that it is true." > > " > '/foo/gloops.taz' asFileReference basename > >>> 'gloops.taz' > " > > ^ self = aResultingObject > > > Stef > > >

Sept. 16, 2016