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

Re: [Pharo-dev] Mysteries of the compiler

by Marcus Denker

> On 12 Oct 2014, at 11:49, Nicolai Hess <nicolaihess(a)web.de> wrote: > > I tried to solve issues > "13260 inspecting variables in the debugger fails in some cases" and > "14058 Inconsistent information in debugger" > and found some oddities in the way opal (compiler and the debuggermap) > handles tempory variables. > I am not sure if these are bugs. > > 1. order of temporaries: > Evaluating this method > |a b c| > a:=1. > b:=2. > c:=3. > thisContext tempNames logCr. > ["in a block ! " thisContext tempNames logCr . a+b+c ] value. > > prints in the transcript > #(#a #b #c) > #(#a #b #c) > > - ok, both contexts, the method and block context, use the same > ordering for the tempories > > writing on one variable in the block context require an indirection vector for > the variable > > |a b c| > a:=1. > b:=2. > c:=3. > thisContext tempNames logCr. > [b:=1. thisContext tempNames logCr. a+b+c ] value. > > here the variable b is written within the block context. This method prints > #(#b #a #c) > #(#a #c #b) > > - strange the variable order has changed and is not the same in both contexts. > Yes, but behind the scenes a lot is going onâ¦ when you assign a variable in a block, this variable can not be allocated like a normal temp. There is instead an array (temp vector) allocated where this variable lives. Then *this array* has a âtempâ and is accessed in the block like the variables in the case of no assignment. This means that there can not be an order: some variables live in arrays, others in the context. The only thing that you have is a scope that nows how a name maps to a specific offset or two (offset of temp of the âtemp vector + offset inside this temp vector). One could beautify it a bit by sorting the names according to the original definition order, though. (we should look onto that). But even if we do, this does not mean that b has offset 2 in the example, as it lives in an array... > 2. OCOptimizedBlockScope > > Consider a whileTrue: call > ["A-Block"] whileTrue:["B-Block"] > or an ifTrue: > ("some boolean value") ifTrue:["C-Block"] > stepping into the blocks with the debugger and reading the > values for a tempoariy variable shows that every block has > an OCOpotimizedBlockScope as its scope. > Are all 3 blocks the same kind of "optimized blocks"? because -> > Yes, we tried two ideas The first move only real existing scopes, that means, instead of an optimised scope point to the scope that all these optimized blocks are flattened into. But that was not nice and we could not get it to work. Instead, we opted into modelling the concept of the optimised scope: on the AST level, the block has a scope (like all blocks), but when you add an entry (or query), it will forward to the ârealâ existing scope. I still like it, it makes things very explicit. > 3. Blocks within optimized blocks > This method prints the number of tempories on the Transcript > (the on:do: call is just a dummy for an "block within a block" > but the important part is the usage of the three variables > in the do-block) > > |a b c| > a:=1. > b:=2. > c:=3. > (c>0) ifTrue:[ > [ a asString ] on:Error do:[:ex | a value:a value:b value:c]. > ]. > thisContext method numTemps logCr. > a > > The output on the transcript is "3" > - ok > > This method is like the one above, but the nested block > is in the receiver of the whileTrue:[] call (again, an optimized block, right?) > > |a b c| > a:=1. > b:=2. > c:=3. > > [ > [ a asString ] on:Error do:[:ex | a value:a value:b value:c]. > c <0 ] whileTrue:[]. > thisContext method numTemps logCr. > a > > The output on the Transcript is "1" > And it depends on the number of used variables in the do-Block > The same method but with the do-Block > do:[:ex | a value:a value:b] > would print 2 as number of temporaries. > Hmmâ¦ I need to think about this one. It looks strange, yes. Marcus

Oct. 14, 2014

[pharo-project/pharo-core]

by GitHub

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

Oct. 14, 2014

[pharo-project/pharo-core] 76df96: 40302

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 76df96847be893c7edd4a03da2500c37f7a68530 https://github.com/pharo-project/pharo-core/commit/76df96847be893c7edd4a03d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-14 (Tue, 14 Oct 2014) Changed paths: A ConfigurationOfGTInspector.package/ConfigurationOfGTInspector.class/instance/versions/version107_.st A ConfigurationOfGTPlayground.package/ConfigurationOfGTPlayground.class/instance/versions/version107_.st A ConfigurationOfGlamour.package/ConfigurationOfGlamour.class/instance/versions/version276_.st A GT-Inspector.package/GTInspector.class/instance/as yet unclassified/closeActionFor_.st R GT-Inspector.package/GTInspector.class/instance/as yet unclassified/globalActionsFor_.st M GT-Inspector.package/GTInspector.class/instance/building/compose.st M GT-Inspector.package/GTInspector.class/instance/private/printObjectAsAnItem_.st A GT-Inspector.package/GTObjectVariablesBrowser.class/instance/private building/updateInstanceVariable_from_basedOn_.st M GT-Inspector.package/GTObjectVariablesBrowser.class/instance/private building/variablesIn_.st M GT-InspectorExtensions-Core.package/extension/Dictionary/instance/gtInspectorItemsIn_.st R GT-InspectorExtensions-Core.package/extension/Dictionary/instance/gtInspectorVariableValuePairs.st M GT-InspectorExtensions-Core.package/extension/SmallDictionary/instance/gtInspectorItemsIn_.st A GT-InspectorExtensions-Core.package/extension/ZnHeaders/instance/gtInspectorHeadersIn_.st A GT-InspectorExtensions-Core.package/extension/ZnMessage/instance/gtInspectorContentsIn_.st M GT-InspectorExtensions-Core.package/extension/ZnMessage/instance/gtInspectorHeadersIn_.st A GT-InspectorExtensions-Core.package/extension/ZnMimePart/instance/gtInspectorContentsIn_.st A GT-InspectorExtensions-Core.package/extension/ZnMimePart/instance/gtInspectorHeadersIn_.st A GT-InspectorExtensions-Core.package/extension/ZnRequest/instance/gtInspectorRequestIn_.st A GT-InspectorExtensions-Core.package/extension/ZnRequestLine/instance/gtInspectorTextIn_.st A GT-InspectorExtensions-Core.package/extension/ZnResponse/instance/gtInspectorResponseIn_.st A GT-InspectorExtensions-Core.package/extension/ZnStatusLine/instance/gtInspectorTextIn_.st A GT-InspectorExtensions-Core.package/extension/ZnStringEntity/instance/gtInspectorTextIn_.st M Glamour-Core.package/GLMPresentation.class/definition.st A Glamour-Core.package/GLMPresentation.class/instance/accessing/titleAction.st A Glamour-Core.package/GLMPresentation.class/instance/accessing/titleActionBlock.st A Glamour-Core.package/GLMPresentation.class/instance/scripting/titleAction_.st A Glamour-Morphic-Renderer.package/GLMMorphicListingRenderer.class/instance/private/newTreeMorph.st M Glamour-Morphic-Renderer.package/GLMMorphicListingRenderer.class/instance/private/treeMorphFor_and_.st M Glamour-Morphic-Renderer.package/GLMMorphicPaneRenderer.class/instance/rendering/actOnPresentationToolbarUpdated_.st M Glamour-Morphic-Renderer.package/GLMMorphicRubricTextRenderer.class/instance/rendering/morph.st M Glamour-Morphic-Renderer.package/GLMMorphicTabbedRenderer.class/instance/rendering/actOnPresentationToolbarUpdated_.st M Glamour-Morphic-Renderer.package/GLMMorphicTabbedRenderer.class/instance/rendering/actOnPresentationUpdated_.st M Glamour-Morphic-Renderer.package/GLMMorphicTabbedRenderer.class/instance/rendering/render_.st A Glamour-Morphic-Renderer.package/GLMMorphicTableRenderer.class/instance/as yet unclassified/newTreeMorph.st M Glamour-Morphic-Renderer.package/GLMMorphicTableRenderer.class/instance/as yet unclassified/render_.st M Glamour-Morphic-Renderer.package/GLMMorphicValidatorPaneRenderer.class/instance/rendering/buttonRowFrom_.st A Glamour-Morphic-Renderer.package/GLMMorphicWidgetRenderer.class/instance/private/labelActionMorphFor_.st M Glamour-Morphic-Renderer.package/GLMMorphicWidgetRenderer.class/instance/private/morph_withTitleOf_.st M Glamour-Morphic-Renderer.package/GLMMorphicWindowRenderer.class/instance/rendering/setLabelOf_for_.st M Glamour-Morphic-Widgets.package/GLMMorphTreeColumn.class/instance/column drawing/rowMorphFor_.st A Glamour-Morphic-Widgets.package/GLMPaginatedResizableMorphTreeMorph.class/README.md A Glamour-Morphic-Widgets.package/GLMPaginatedResizableMorphTreeMorph.class/definition.st A Glamour-Morphic-Widgets.package/GLMPaginatedResizableMorphTreeMorph.class/instance/as yet unclassified/resizeColumns.st A Glamour-Morphic-Widgets.package/GLMPaginatedResizableMorphTreeMorph.class/instance/as yet unclassified/toggleExpandedState_event_.st A Glamour-Morphic-Widgets.package/GLMPaginatedResizableMorphTreeMorph.class/instance/as yet unclassified/updateColumnMorphs.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldArea.class/README.md A Glamour-Morphic-Widgets.package/GLMRubricTextFieldArea.class/definition.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldArea.class/instance/defaults/defaultMargins.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldArea.class/instance/editing/privateReplaceFrom_to_with_.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldArea.class/instance/event handling/click.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldArea.class/instance/event handling/doubleClick_.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldArea.class/instance/event handling/focusChanged.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldArea.class/instance/event handling/handlesMouseOver_.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldArea.class/instance/event handling/keyStroke_.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldArea.class/instance/event handling/mouseDown_.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldArea.class/instance/event handling/singleClick_.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldArea.class/instance/initialize/initialize.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldArea.class/instance/private/newParagraph.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldArea.class/instance/protocol/disable.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldArea.class/instance/protocol/enable.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldArea.class/instance/settings/walkAlongDisplayedLine.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldArea.class/instance/testing/isEnabled.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldMorph.class/README.md A Glamour-Morphic-Widgets.package/GLMRubricTextFieldMorph.class/definition.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldMorph.class/instance/accessing/container_.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldMorph.class/instance/accessing/font_.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldMorph.class/instance/as yet unclassified/whenGotForcus_.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldMorph.class/instance/as yet unclassified/whenLostForcus_.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldMorph.class/instance/event handling/handlesMouseWheel_.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldMorph.class/instance/initialize-release/newScrollPane.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldMorph.class/instance/initialize-release/textAreaClass.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldScrollPane.class/README.md A Glamour-Morphic-Widgets.package/GLMRubricTextFieldScrollPane.class/definition.st A Glamour-Morphic-Widgets.package/GLMRubricTextFieldScrollPane.class/instance/as yet unclassified/handlesMouseWheel_.st M Glamour-Morphic-Widgets.package/GLMTreeMorphNodeModel.class/instance/callbacks/rowMorphForColumn_.st A Glamour-Morphic-Widgets.package/GLMTreeMorphNodeModel.class/instance/callbacks/textFieldMorphFor_.st A Glamour-Morphic-Widgets.package/LazyTabGroupMorph.class/instance/adding/addLazyPage_label_toolbar_action_.st M Glamour-Morphic-Widgets.package/LazyTabGroupMorph.class/instance/adding/addLazyPage_label_toolbar_collapsable_.st M Glamour-Morphic-Widgets.package/LazyTabGroupMorph.class/instance/as yet unclassified/fitLabelsIn_.st M Glamour-Morphic-Widgets.package/LazyTabGroupMorph.class/instance/as yet unclassified/measureWidth.st A Glamour-Morphic-Widgets.package/LazyTabGroupMorph.class/instance/as yet unclassified/updatePageAtIndex_withLabel_toolbar_action_.st A Glamour-Morphic-Widgets.package/LazyTabGroupMorph.class/instance/private/buildLabelFrom_withAction_.st M Glamour-Morphic-Widgets.package/LazyTabGroupMorph.class/instance/private/updatePageIndex_.st A Glamour-Morphic-Widgets.package/extension/MorphTreeNodeMorph/instance/container.st M Glamour-Presentations.package/GLMTableColumn.class/definition.st A Glamour-Presentations.package/GLMTableColumn.class/instance/accessing/modifiedBlock.st A Glamour-Presentations.package/GLMTableColumn.class/instance/accessing/modifiedBlock_.st A Glamour-Presentations.package/GLMTablePresentation.class/instance/as yet unclassified/column_evaluated_modified_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script302.st M ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40301.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40302.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40302 14217 GTTools version 1.0.7 https://pharo.fogbugz.com/f/cases/14217 http://files.pharo.org/image/40/40302.zip

Oct. 14, 2014

Re: [Pharo-dev] Tests around Pharo

by stepharo

You should sign the license agreements else we will not accept your code. You can print sign and give to damien the printed version: http://files.pharo.org/media/PharoSoftwareDistributionAgreement.pdf And yes this is part of the exercise: understanding how a community works. Stef On 13/10/14 11:44, mschepens wrote: > Hello, > > We opened some issues on fogbugz (14220, 14221 and 14222) and created slices > from our pharo images. > Can anyone confirm us that these slices are automatically sent when they are > created under a pharo image ? > > Again thanks to all of you for your advices and your time ! > We're still available if there is any comment around our tests. > > > > -- > View this message in context: http://forum.world.st/Tests-around-Pharo-tp4777295p4784279.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Oct. 14, 2014

Re: [Pharo-dev] Tests around Pharo

by stepharo

Why don;t you work with hilaire. Hilaire said: Based on Pharo, you may also consider developing tests for Dr.Geo[1][2]. It is an interactive geometry framework for Pharo and it comes with a complete API, helpful to write tests. There is already a test package ready to be completed. Thanks Hilaire [1] http://drgeo.eu [2] http://smalltalkhub.com/#!/~HilaireFernandes/DrGeo So load the code and go On 11/9/14 20:57, mschepens wrote: > First of all, thank you for your answers, your precious advices and for > having taken time to answer us. > Answers to Ben Coman : > It's our first experience with Pharo, but we'll take more time to learn this > project if it's necessary. > We're a little comfortable with the tool, we already took the time to > discover it, to do the first tutorial which is proposed when pharo is > launched, and to develop first classes and tests for learning about pharo. > We never used the TestRunner previously, we just ran our tests for our > classes yesterday. > We never submitted a code Slice for Intergration before. > > We're still waiting propositions of Test or code to cover, and again thank > you for your attention. > > > > > -- > View this message in context: http://forum.world.st/Tests-around-Pharo-tp4777295p4777496.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Oct. 14, 2014

[pharo-project/pharo-core]

by GitHub

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

Oct. 14, 2014

[pharo-project/pharo-core] 3376e4: 40301

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 3376e49aedf197caf1bb9ec85e21d6ac01377cd6 https://github.com/pharo-project/pharo-core/commit/3376e49aedf197caf1bb9ec8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-14 (Tue, 14 Oct 2014) Changed paths: M Manifest-Core.package/extension/RBSelectorEnvironment/instance/smallLintCritics.st M Monticello-Tests.package/MCPackageTest.class/instance/tests/testUnloadWithAdditionalTracking.st M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/initialization/registerToAnnouncer.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script301.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40301.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40301 14229 Replace Announcer>>#on:send:to:s senders in MonticelloGUI https://pharo.fogbugz.com/f/cases/14229 14226 smallLintCritics optimisation is slow https://pharo.fogbugz.com/f/cases/14226 14227 Replace Announcer>>#on:send:to:s senders in Monticello-Tests https://pharo.fogbugz.com/f/cases/14227 http://files.pharo.org/image/40/40301.zip

Oct. 14, 2014

Re: [Pharo-dev] OSProcess in 3.0

by Thierry Goubier

Hi Dave, took me a while to do some testing. It seems there is an issue, but I couldn't find out where. First, the data: Loading a package from a local gitfiletree repository (get from the command a zipped git archive containing the package) : 4.5.11, 4.6.8: 2132 msec. 4.5.12, 4.6.9: 50847 msec. I tried to rewrite the main command, remove the closePipes, etc... No change in the runtime, so your right. Profiling doesn't help much: execution time is mostly idle time (but with a significant increase on PipeableOSProcess commands: goes from invisible to 2700 ms. A user break in the middle shows it delay waiting on output of the external process). Only hint I could see is that it seems to be linked with the size of the output of the command. Thierry Le 11/10/2014 15:34, David T. Lewis a Ã©crit : > On Fri, Oct 10, 2014 at 01:32:27PM -0400, David T. Lewis wrote: >>> Le 10/10/2014 17:52, David T. Lewis a ?crit : >>>>> 2014-10-10 14:09 GMT+02:00 David T. Lewis <lewis(a)mail.msen.com>: >>>>> >>>>>> >>>>>> Right. But please do test it in your applications to be sure, I really >>>>>> only >>>>>> did simple testing and I am sure there may still chances for problems >>>>>> in >>>>>> this area. >>>>>> >>>>> >>>>> Hi Dave, >>>>> >>>>> Would it has a chance of slowing down things a lot? >>>>> >>>>> There is apparently something going very very slow compared to >>>>> OSProcess >>>>> 4.5.11 when used from GitFileTree. So slow that I killed the image >>>>> building >>>>> script before it was over. Reverting GitFileTree to 4.5.11 solved it. >>>>> >>>> >>>> I don't this so, but I am not certain. The update for PipeableOSProcess >>>> affects only the methods in PipeableOSProcess class>>command: and >>>> closely >>>> related methods. If GitFileTree is using that idiom, then it is >>>> certainly >>>> possible that I have introduced a bug that does not show up in my unit >>>> tests. >>> >>> Typical code in GitFileTree is this: >>> >>> [ >>> c := PipeableOSProcess command: ''. >>> output := c output. >>> ... >>> ] ensure: [c closePipes] >>> >>> Maybe it's triggering something. >>> >>> Thierry >>> >> >> Hmmm... I wonder if the #closePipes is causing a problem now. I don't know >> if I ever tested to see if sending closePipes works after the pipes are >> already closed, and my recent change closes the pipes after #output is >> evaluated. I'll check it when I get home. >> > > I tried this in both Squeak trunk and Pharo 3.0: > > (1 to: 100) collect: [:e | | c output | > [c := PipeableOSProcess command: 'ls -lt'. > output := c output. > ] ensure: [c closePipes]. > output ]. > > I get the expected results, and no open file handles left over. > > The #closePipes is no longer needed, so this can now be simplified as follows, > which also leaves no open file handles: > > (1 to: 100) collect: [:e | (PipeableOSProcess command: 'ls -lt') output]. > > I am not sure what the issue is when used with GitFileTree, but it does not > look like the change to PipeableOSProcess class>> command: is directly involved. > But ... I'm probably missing something. > > If you are fairly sure the that problem is related to the the PipeableOSProcess > change, then the only other thing I can think of right now is that there may > be some other places in GitFileTree where PipeableOSProcess is being used in > a different way, and maybe I caused a problem there due the the change in the > #command: methods. But this a a complete guess, I really do not know. > > Dave > > >

Oct. 14, 2014

New Cog VMs available

by Eliot Miranda

...at http://www.mirandabanda.org/files/Cog/VM/VM.r3104 CogVM source as per VMMaker.oscog-eem.900/r3104 Change a couple of between:and:'s that should be oop:isGreaterThanOrEqualTo: andLessThan:'s Fix signed/unsigned comparisons with freeStart in V3. Fix old V3 NewObjectMemory bug in fullGC. sweepPhaseForFullGC failed to update freeStart at the end of its sweep which could leave a partial object between the last object and freeStart, causing subsequent crashes in enumeration. This fixes an occasional crash in muO's release process: MuODeployer makeImageRelease -- best, Eliot

Oct. 14, 2014

Re: [Pharo-dev] Selecting only rules for checking methods

by Yuriy Tymchuk

Hmmâ¦ didnât know about that. But now Iâm not sure that every rule refines that. Uko > On 13 Oct 2014, at 18:13, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > > I tell them apart by looking at their #resultClass. > HTH, Jan > > On Mon, 2014-10-13 at 17:30 +0200, Yuriy Tymchuk wrote: >> Hi, >> >> In Smalllint the basic rule has two methods: #checkClass: and #checkMethod:. >> >> They do nothing, and the idea is that every rule is used to check both classes and methods, but only ones that redefine #checkClass: or #checkMethod: actually do something. This is fine, but I wonder if it is possible, to tell about the rule whether it checks method or not. Just checking is it local defines #checkMethod: doesnât work, as some rules define #checkMethod: and then their subclasses override other methods. One idea that I had is to get the CompiledMethod object of RBBasicLintRule and check if it is different from the one used in current class. But maybe there is a better way? >> >> Uko >> > > >

Oct. 13, 2014