- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo4] Inspector View for Opal Scopes

by Clara Allende

I love it :) Thanks ^^ 2014-10-16 15:39 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > Hi, > > There is now a special view for semantic scopes in Opal: > > > > And these tools work outside of the Inspector, too: > e.g. > > GTBytecodeBrowser openOn: (OrderedCollection>>#do:) > > >

Oct. 16, 2014

[pharo-project/pharo-core]

by GitHub

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

Oct. 16, 2014

[pharo-project/pharo-core] 4a8185: 40309

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 4a818514f3a4d113aea4fd664577e71dcd21bc3d https://github.com/pharo-project/pharo-core/commit/4a818514f3a4d113aea4fd66… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-16 (Thu, 16 Oct 2014) Changed paths: M Nautilus.package/AbstractNautilusUI.class/class/menu/classesMenu_.st A Nautilus.package/AbstractNautilusUI.class/instance/menus behavior/inspectMethod.st A Nautilus.package/AbstractNautilusUI.class/instance/menus behavior/inspectMethods.st M Nautilus.package/MethodWidget.class/class/menu/elementsMenu_.st M OpalCompiler-Core.package/OCAbstractScope.class/definition.st A OpalCompiler-Core.package/OCAbstractScope.class/instance/accessing/children.st A OpalCompiler-Core.package/OCAbstractScope.class/instance/initializing/addChild_.st M OpalCompiler-Core.package/OCAbstractScope.class/instance/initializing/outerScope_.st M OpalTools.package/GTBytecodeBrowser.class/README.md M OpalTools.package/GTBytecodeBrowser.class/instance/building/sourceIn_.st A OpalTools.package/GTOpalScopeBrowser.class/README.md A OpalTools.package/GTOpalScopeBrowser.class/definition.st A OpalTools.package/GTOpalScopeBrowser.class/instance/building/compose.st A OpalTools.package/GTOpalScopeBrowser.class/instance/building/sourceIn_.st A OpalTools.package/GTOpalScopeBrowser.class/instance/building/treeIn_.st A OpalTools.package/extension/OCAbstractScope/instance/gtInspectorSourceCodeIn_.st A OpalTools.package/extension/OCAbstractScope/instance/sourceInterval.st A OpalTools.package/extension/RBProgramNode/instance/gtInspectorSymbolicBytecodeIn_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script309.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40309.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Traits.package/TClassDescription.class/instance/compiling/compile_classified_withStamp_notifying_logSource_.st Log Message: ----------- 40309 14251 Add a scope browser: shows tree of scopes, corresponding source https://pharo.fogbugz.com/f/cases/14251 14243 tiny refactoring in #compile:classified:withStamp:notifying:logSource: https://pharo.fogbugz.com/f/cases/14243 14231 add "inspect method" to method menu in browser and everywhere https://pharo.fogbugz.com/f/cases/14231 http://files.pharo.org/image/40/40309.zip

Oct. 16, 2014

[Pharo4] Inspector View for Opal Scopes

by Marcus Denker

Hi, There is now a special view for semantic scopes in Opal: And these tools work outside of the Inspector, too: e.g. GTBytecodeBrowser openOn: (OrderedCollection>>#do:)

Oct. 16, 2014

Re: [Pharo-dev] OrderedDictionary and new tools, Seaside...

by Marcus Denker

> On 16 Oct 2014, at 14:55, phil(a)highoctane.be wrote: > > I am using OrderedDictionary in quite a few places. > > Now, I have to steam a lot of extra methods from Dictionary as the GTInspector doesn't display things properly, nor the WAInspector and its subclasses out of the box. > NeoJSON same story, as Ston etc. > > OrderPreservingDictionary is quite useful. > Yes, there is GRSmallDictionary but it also has the same issues. > > OrderPreservingDictionary is at least a Collection where GRSmallDictionary is a GRObject. > > What would be the best strategy here? > > We need such an ordered map all the time, it deserves a bit better. > > Opinions? > In Pharo4, I copied OrderPreservingDictionary to OrderedDictionary. (to have a default one in the image without disturbing clients of OrderPreservingDictionary) This should be improved if it something is missing. Marcus

Oct. 16, 2014

OrderedDictionary and new tools, Seaside...

by phil＠highoctane.be

I am using OrderedDictionary in quite a few places. Now, I have to steam a lot of extra methods from Dictionary as the GTInspector doesn't display things properly, nor the WAInspector and its subclasses out of the box. NeoJSON same story, as Ston etc. OrderPreservingDictionary is quite useful. Yes, there is GRSmallDictionary but it also has the same issues. OrderPreservingDictionary is at least a Collection where GRSmallDictionary is a GRObject. What would be the best strategy here? We need such an ordered map all the time, it deserves a bit better. Opinions? Phil

Oct. 16, 2014

Re: [Pharo-dev] compiled method inspector

by Marcus Denker

> On 16 Oct 2014, at 12:13, Nicolai Hess <nicolaihess(a)web.de> wrote: > > The new inspector extensions for compiled methods are GREAT. > :-) More to come. I have one for IR->Text and one for Opal Compiler Scopes. > I noticed some of them are in package GT-Inspector-Extensions-Core > and some are in OpalTools. > Yes, the reason is that GTTools has to run on Pharo3 for now, it follows the Moose release/develipment cycle (for now). This means that when moose goes to Pharo4 (in a week or three), this will be merged back. > With the symbolic bytecode tab the other bytecode tab is not needed anymore, right? > Yes! I will remove it when merging. Marcus

Oct. 16, 2014

compiled method inspector

by Nicolai Hess

The new inspector extensions for compiled methods are GREAT. I noticed some of them are in package GT-Inspector-Extensions-Core and some are in OpalTools. With the symbolic bytecode tab the other bytecode tab is not needed anymore, right? nicolai

Oct. 16, 2014

Playground and its current usability in Pharo4.0 Latest update: #40307

by Torsten Bergmann

While I like that GTTools are in Pharo 4 now (thanks!!!) and allow all kind of neat things I basically ask myself if we forgot to remember usability on a few places: 1. the world menu item "Workspace" opens a window "Playground" including also a tab with the same name "Playground". => CONFUSING I would suggest that we rename the window "Workspace" and keep "Playground" for the initial tab. This is easy to fix and would also fulfill the expectation when a beginner grabbed an existing Smalltalk or Pharo book. 2. While in all UI interfaces (Windows, Linux, Mac) the order in the context menu is "Cut", "Copy", "Paste" the playground menu uses a different order "Copy", "Cut" "Paste". => CONFUSING again I would suggest to use the well known order "Cut","Copy","Paste". 3. When one uses "Inspect it" from the context menu it means - to run the code - and the resulting object is then "inspectable" in a new window On the other side "Do it and go" from the context menu means - to run the code - and the resulting object is then "inspectable" in a new pane (but same window) The intention of both menu items and also the result is the same, but the naming is different ("go" vs. "inspect"). But the only notable difference is that in one case the inspectable object is opening right to the existing pane in the other case a new window is opened. => CONFUSING and inconsistent This is harder to solve. Possible solutions are: 3a. We keep the "inspect" concept and name the menu items "Do and Inspect it" and "Inspect in new window" 3b. We keep "Do it" as before to run the code, also "Inspect it" which opens the new pane to the left in the same window. If someone wants to open a new inspector window he should keep SHIFT key pressed while running "Inspect it". This is a concept known from web browsers and other tools today, clicking on a link while pressing SHIFT opens a new window. 4. The icons in the context menu of Playground are not the same as the ones in the Pharo browsers. => CONFUSING and inconsistent They are just black and if one switches to the Pharo dark theme they stay black and therefore looking ugly and make nearly no sense on the dark grey menu background. For now we should use the known icons that we already have. Maybe currently they are hardcoded and may conflict with Moose vs. Pharo icons - but this could be solved with the Icon Theming. (In the long term I would like to see scalable icons in Pharo menues (instead of bitmaps) similar to "Fontawesome" in web browsers (two colors) or SVG based ones (more colors) as currently the icon does not scale when changing the menue font size). Sorry if it sound like a rant - but the intention of this mail is that we discuss (and hopefully fix) in order to improve. Maybe it is written too early after the initial integration, but I think the mentioned points should be easy to address. Unfortunately I'm additionally confused with the changed contribution process that has exceptions for specific packages like GT to fix it myself with the usualy bugs/slice cycle. Thanks T.

Oct. 16, 2014

Re: [Pharo-dev] Context variables?

by J.F. Rick

Thanks. Will do. Jeff On Wed, Oct 15, 2014 at 11:34 AM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > Hi Jeff, > > I think you should look at DynamicVariable and ProcessSpecificVariable > classes. The first one is a read-only while the second is writable. > You have to subclass these class for each variable you want. > > Ex: > DynamicVariable subclass: #MyVar. > MyVar value: 4 during: [ MyVar value ] > > HTH, > Camiile > > > On 15 oct. 2014, at 17:09, J.F. Rick <self(a)je77.com> wrote: > > I remember there was some discussion on the list about support for > variables tied to the context rather than to the instance or class. This > seems particularly useful for a web application where you might want to > access the request and response from the context. What is the proper name > for these kind of variables and where can I read about how to use them? > > Cheers, > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > > > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Oct. 16, 2014