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

Re: [Pharo-dev] roundTo: strange behavior

by werner kassens

Hi Stephan, definitely no. after the test is run, the seed has changed, perhaps you did not reset the seed. ill look into this this night, have to work now, ok? werner On 11/04/2016 03:29 PM, stepharo wrote: > Hi guys > > I loaded the slice 15471 of werner and I run > > https://pharo.fogbugz.com/f/cases/15471/Can-t-round-Float-fmax-to-2-decimal… > > > > testIfCompletelyBroken > > "If the results are not these values (accounting for precision of > printing) > then something is horribly wrong" > > gen seed: 2345678901. > self assert: (((1 to: 10) collect: [:i | gen next round: 15]) = > #(0.149243269650845 0.331633021743797 0.75619644800024 > 0.393701540023881 0.941783181364547 0.549929193942775 > 0.659962596213428 0.991354559078512 0.696074432551896 > 0.922987899707159 )). > > I get the following. Is it correct? > > #(0.220388752510952 0.073763451573329 0.74233059293699 > 0.350275491993071 0.080193927548916 0.819340314631974 > 0.652668019594936 0.391405332084468 0.349416343657959 0.640487859323848) > >

Nov. 4, 2016

Re: [Pharo-dev] some little static analysis with great impact

by Peter Uhnak

I'm always applying the autoformatting before I save the method, which helps me a lot in detecting those problems, because I immediately see that the code is formatted strangely. But of course analysis would be nice for people that don't use autoformatting, or for better (and automated) detection. Peter On Thu, Nov 03, 2016 at 05:47:51PM +0100, stepharo wrote: > > > Le 3/11/16 Ã 15:52, Esteban Lorenzano a Ã©crit : > >wouldnât this be better to solve this with QA? > but QA needs the analysis first. > > > >>On 3 Nov 2016, at 15:17, stepharo <stepharo(a)free.fr> wrote: > >> > >>Hi > >> > >>I often end up forgetting a period. > >> > >>printOn: aStream > >> super printOn: aStream. > >> aStream nextPutAll: ' "' > >> aStream nextPutAll: contents. > >> aStream nextPutAll: '" '. > >> > >> > >>And statically the system could see it with a simple heuristics: > >> > >> if the message as the same name as self, super, a tmp or an argument > >> > >>May be there is a missing period. > >> > >>Could the compiler get this analysis? > >> > >>Stef > >> > >> > > > > > >

Nov. 4, 2016

Re: [Pharo-dev] some little static analysis with great impact

by Denis Kudriashov

2016-11-03 22:05 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > Hi Uko, > I often write things like > | abs | > abs := self abs. > so I would not like the temp/args rule... > But for args it could be not bad

Nov. 4, 2016

Re: [Pharo-dev] some little static analysis with great impact

by Nicolas Cellier

2016-11-03 23:39 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > On 3 Nov 2016, at 22:05, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > > Can we have rules about indentation? > > > Yes, we can. I think that even easier heuristic would be to check if a > unary is separated from the receiver by a line break. > +1, I guess such formatting is pretty unusual indeed...

Nov. 4, 2016

[pharo-project/pharo-core]

by GitHub

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

Nov. 4, 2016

Re: [Pharo-dev] roundTo: strange behavior

by stepharo

Hi guys I loaded the slice 15471 of werner and I run https://pharo.fogbugz.com/f/cases/15471/Can-t-round-Float-fmax-to-2-decimal… testIfCompletelyBroken "If the results are not these values (accounting for precision of printing) then something is horribly wrong" gen seed: 2345678901. self assert: (((1 to: 10) collect: [:i | gen next round: 15]) = #(0.149243269650845 0.331633021743797 0.75619644800024 0.393701540023881 0.941783181364547 0.549929193942775 0.659962596213428 0.991354559078512 0.696074432551896 0.922987899707159 )). I get the following. Is it correct? #(0.220388752510952 0.073763451573329 0.74233059293699 0.350275491993071 0.080193927548916 0.819340314631974 0.652668019594936 0.391405332084468 0.349416343657959 0.640487859323848)

Nov. 4, 2016

[pharo-project/pharo-core]

by GitHub

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

Nov. 4, 2016

[pharo-project/pharo-core] 6dc7ee: 60279

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 6dc7eeb214230eaa644337ba3d96123e447284bf https://github.com/pharo-project/pharo-core/commit/6dc7eeb214230eaa644337ba… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-11-04 (Fri, 04 Nov 2016) Changed paths: M FreeType.package/FreeTypeSystemSettings.class/class/settings/freeTypeSettingsOn_.st M GT-Debugger.package/GTDebuggerSystemSettings.class/class/settings/debugSettingsOn_.st M Growl.package/GrowlMorph.class/class/settings/growlSettingsOn_.st M NECompletion.package/NECPreferences.class/class/settings/settingsOn_.st M OSWindow-Core.package/OSTouchGestureDetector.class/class/settings/touchGestureSettingsOn_.st M OSWindow-Core.package/OSTouchHoldDetector.class/class/settings/touchHoldSettingsOn_.st M OSWindow-Core.package/OSTouchOneFingerDoubleTapDetector.class/class/settings/touchDoubleTapSettingsOn_.st M OSWindow-Core.package/OSTouchPinchDetector.class/class/settings/touchPinchSettingsOn_.st M OSWindow-Core.package/OSTouchRotationDetector.class/class/settings/touchRotationSettingsOn_.st M OSWindow-Core.package/OSTouchScrollDetector.class/class/settings/touchScrollSettingsOn_.st M OSWindow-Core.package/OSTouchSwipeDetector.class/class/settings/touchSwipeSettingsOn_.st M QualityAssistant.package/QASettings.class/class/settings-definition/qaGroupSettingsOn_.st M QualityAssistant.package/QASettings.class/class/settings-definition/qaNautilusPlugginSettingOn_.st M Renraku.package/ReSettings.class/class/settings-definition/inspectorPlugginSettingsOn_.st M Rubric.package/RubCursor.class/class/settings/rubricSettingsOn_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60278.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60279.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60278.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60279.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Settings-Graphics.package/GraphicFontSettings.class/class/fonts/standardFontsSettingsOn_.st M Settings-Polymorph.package/PolymorphSystemSettings.class/class/morphic/windowPositionStrategySettingsOn_.st M ShoreLine-Report-Settings.package/ShoreLineReportSettings.class/class/settings/reportSettingsOn_.st M System-Settings.package/MultipleSettingDeclaration.class/instance/user interface/fixedDomainValueNodeForAssociation_.st M System-Settings.package/PragmaSetting.class/instance/accessing/description.st M System-Settings.package/PragmaSetting.class/instance/accessing/description_.st M System-Settings.package/PragmaSetting.class/instance/accessing/label.st M System-Settings.package/PragmaSetting.class/instance/accessing/label_.st M System-Settings.package/PragmaSetting.class/instance/accessing/name.st M System-Settings.package/PragmaSetting.class/instance/accessing/name_.st M System-Settings.package/SettingNodeBuilder.class/instance/public declaration accessing/label_.st M System-Settings.package/SettingNodeBuilder.class/instance/public declaration accessing/name_.st M Text-Edition.package/Editor.class/class/settings/editingSettingsOn_.st M Tool-Base.package/AbstractTool.class/class/private/requestProtocolNameFor_initialAnswer_.st M UIManager.package/CommandLineUIManager.class/class/settings/uiSettingsOn_.st Log Message: ----------- 60279 19287 Sending translated should not be the responsibility of the client of a Setting - label: case https://pharo.fogbugz.com/f/cases/19287 http://files.pharo.org/image/60/60279.zip

Nov. 4, 2016

Re: [Pharo-dev] why RBComment is not called RBCommentNode

by John Brant

On 11/04/2016 03:50 AM, Norbert Hartl wrote: > >> Am 04.11.2016 um 07:53 schrieb Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com >> <mailto:nicolas.cellier.aka.nice@gmail.com>>: >> >> >> >> 2016-11-04 1:54 GMT+01:00 John Brant <brant(a)refactoryworkers.com >> <mailto:brant@refactoryworkers.com>>: >> >> >> > On Nov 3, 2016, at 4:03 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >> >>>> Furthermore, if comments are nodes, how do they affect all of the code rewriting and validation that is part of the RB and its rewrite tools >> >>> With comments cannot act as nullobjects for such operation? >> >> Yes, someone could spend time making all of this work with the existing code. However, why not fix the real problem in that comments and methods should not be a single string, but rather objects. >> > >> > Marcus did that during his phd and he blew up memory. So after we got a guy that worked on tree compression but he never finished. >> > Because this is the part that makes all these ideas flying or not. >> >> From what I remember, ASTs are roughly 10x the size of the code >> string. Iâm not suggesting holding on to them in the image when >> they can be loaded/built from a file like the method sources >> currently are. Instead, we can associate a comment/annotation to a >> particular node in the AST without having to keep the AST around. >> For example, we could say that some comment is associated to the >> 4th node visited from the standard AST traversal. We donât need to >> keep the AST around since we can recreate it and the 4th node >> visited will be the same. >> >> >> John Brant >> >> >> But this vision is a bit static. Code is living. Shall these >> annotations be lost on next refactoring? Or are we going to diff the >> two AST and salvage as many annotations as we can? Or are we going to >> keep an history of these comments in the versioning system? > > +1 It's only static if you do a poor implementation. The refactorings already operate on the AST level so we don't need any AST diffing for them. We would need to update the rewriter to update this information for nodes that get replaced. This updating would likely need the help of the annotation objects since some annotations might not want to be copied to the replaced node, and others (e.g., comments) would need to be copied. The editor will need to be changed to display these annotations/comments so we can also change it to keep track of the rearrangement of the nodes. That leaves custom tools that use the compile:* methods. These will need to be updated if they want to generate code with proper annotations/comments. Of course, all of these will need to be stored where they can be versioned. Currently, we store some of the method properties outside of a method body: !SomeClass methodsFor: 'some category' stamp: 'SomeAuthor 1/1/1111 11:11:11'! The additional properties could be store similarly. The ANSI standard already defines the SIF format which contains annotations that can be added to filed-out objects. John Brant

Nov. 4, 2016

[pharo-project/pharo-core]

by GitHub

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

Nov. 4, 2016