Moose-dev March 2014

moose-dev@list.inf.unibe.ch

44 participants
104 discussions

by Ben Coman

I wonder if this is a minor demonstration opportunity for Moose refactoring tools... "Neovim is a major overhaul of the vim editor to provide better scripting, cleaner support for plugins and integration with modern graphical interfaces. Modernising the large and complex codebase of Vim is a formidable task, but the developer has a clear plan, and has already begun work http://news-beta.slashdot.org/story/14/03/22/147222/neovim-rebuilding-vim-f… http://neovim.org/ cheers -ben

10 years, 9 months

popup view in Roassal 2

by Usman Bhatti

Hello, Is it possible to do popup views in Roassal 2 as we could do with ROPopupView? I didn't find any example related to this in Roassal 2. tx, Usman

10 years, 9 months

Issue 1016 in moose-technology: PNG Export is not clean (example EyeSee charts)

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 1016 by usman.bh...(a)gmail.com: PNG Export is not clean (example EyeSee charts) http://code.google.com/p/moose-technology/issues/detail?id=1016 See the attached screenshot, it seems that the export is not clean. The diagram export is correct but the labels seem to be superimposed. The problem might be coming from Pharo but I dont know how to reproduce it in there. Attachments: EyeSee-2013-11-25-1506.png 5.9 KB -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

10 years, 9 months

Troubles with loading ConfigurationOfODBC

by Friedrich Dominicus

Well downloaded the newst Moosse and lates Pharo VM from here: http://www.moosetechnology.org/download/5.0 Loading ConfigurationOfODBC from: MCSqueaksourceRepository location: 'http://squeaksource.com/ODBC' user: '' password: '' Now in a workspace just type: ConfigurationOfODBC load. After a while I get an backtrace. which points to ExternalClass class initialize initialize "ExternalObject initialize" Smalltalk addToStartUpList: self after: ShortRunArray. Yes ShortRunArray, is not there any more (that is known) but, just removing it give the following Error ffiPrintString: aString "FFITestLibrary ffiPrintString: 'Hello'" <cdecl: char'>' expected -> * 'ffiPrintString' (char *) module:'SqueakFFIPrims'> ^self externalCallFailed And that's it. Now where's the bug, in the VM in the image or where else? Regards Friedrich

10 years, 9 months

Issue 1047 in moose-technology: Moose-on-Moose job in jenkins failing

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 1047 by usman.bh...(a)gmail.com: Moose-on-Moose job in jenkins failing http://code.google.com/p/moose-technology/issues/detail?id=1047 The job Moose-on-moose is failing in Jenkins probably because output file does not have the correct format. We launched the rules report on a moose image with: OnMooseReport importAndExportAsHudsonTests And it succeeded. Currently, the job is disabled. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

10 years, 9 months

Issue 1057 in moose-technology: DSM in MoosePanel without the name of the entities

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium Component-MooseTools Component-DSM New issue 1057 by anne.et...(a)gmail.com: DSM in MoosePanel without the name of the entities http://code.google.com/p/moose-technology/issues/detail?id=1057 In the MoosePanel, when right clicking on Package or Namespace, there is the possibility to get various DSM. However, we can't do nothing with it, since the name of the involved entities are not present. It could be nice that at least when mouse over, the name of the involved entities appears. Please fill in the labels with the following information: * Type-Defect, Type-Enhancement, Type-Engineering, Type-Review, Type-Other * Component-XXX -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

10 years, 9 months

Metaceller improvements

by Diego Lont

Hi all, When I ran into trouble with the configurations again, I decided I needed a better tool. Metaceller is nice now, but not good enough. So I started working on a new version. During my tests I stumbled on the configurationOfNewDebugger. This is the output it produces: (colors are missing). 0.2-baseline Author: Status: somethingLoaded Imported versions: #() DebuggerActions Assuming version DebuggerActions-AndreiChis.69 is the correct version. DebuggerModel Assuming version DebuggerModel-AndreiChis.82 is the correct version. DebuggerModel-Tests No valid repository for self DebuggerModel-Tests. Expected this package in one of the following repostories: spec repository: 'http://www.smalltalkhub.com/mc/Pharo/Debugger/main' DebuggerFilters Assuming version DebuggerFilters-AndreiChis.2 is the correct version. DebuggerFilters-Tests No valid repository for self DebuggerFilters-Tests. Expected this package in one of the following repostories: spec repository: 'http://www.smalltalkhub.com/mc/Pharo/Debugger/main' DebuggerExtensions Assuming version DebuggerExtensions-AndreiChis.6 is the correct version. default Core Spec-Debugger Assuming version Spec-Debugger-AndreiChis.188 is the correct version. Core-Tests UI But as you can see: this configuration does not load at the moment, because some of the packages are simply not there in the repositories. Cheers, Diego

10 years, 9 months

Issue 1055 in moose-technology: Can't inspect instances variables in debugger by the ALT+i command

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 1055 by v.blonde...(a)gmail.com: Can't inspect instances variables in debugger by the ALT+i command http://code.google.com/p/moose-technology/issues/detail?id=1055 Describe the problem: what do you get? what do you expect? When you try to inspect a instance variable in the debugger by the ALT+i shortcut, you get a DNU : MessageNotUnderstood: receiver of ""cull:cull:"" is nil In the method: GLMSmalltalkCodeModel>>bindingOf: aSymbol ^ bindingsStrategy cull: self variableBindings cull: aSymbol The IV bindingsStrategy is nil. How to reproduce the problem: step by step if necessary Debug: | temp | temp := { 1 . 2 } asSet. temp add: 3. And go into the add: method and try to inspect array in the method source Additional information: platform, context which may impact the problem Moose 5.0 - W7 Please fill in the labels with the following information: * Type-Defect * Component-GT -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

10 years, 9 months

Re: [Pharo-dev] How to include Moose-Finder in build

by Tudor Girba

Hi Max, I am happy you want to give these tools a try :). The tools do not install themselves automatically because I think it is not a good practice to tie code loading with installation. To setup the Moose image, we actually have a command line handler that allows you to simply trigger this from the CI job: ./pharo $JOB_NAME.image mooseimagesetup --signature=$BUILD_URL You can also trigger from the image: MooseImageSetupCommandLineHandler activateWith: (CommandLineArguments withArguments: {}) This installs the theme, the fonts, preferences and the GToolkit playground, inspector and debugger. However, for developing in Pharo, you do not need all of Moose, and almost certainly do not need the Moose Finder. You likely only need the GToolkit. spec project: 'GToolkit' with: [ spec className: 'ConfigurationOfGToolkit'; version: #development; file: 'ConfigurationOfGToolkit'; repository: 'http://www.smalltalkhub.com/mc/Moose/GToolkit/main' ]. To install the tools, you have to install them manually at the moment - but I will create a command line handler for that soon: GTPlayground registerToolsOn: Smalltalk tools. GTInspector registerToolsOn: Smalltalk tools. GTGenericStackDebugger registerToolsOn: Smalltalk tools. GTGenericStackDebugger registerExtraToolsOn: Smalltalk tools. "GTPPDebugger registerToolsOn: Smalltalk tools." "only if you need it for PetitParser" GTGlamourDebugger registerToolsOn: Smalltalk tools. ACGlamourDebugger registerToolsOn: Smalltalk tools. GTSUnitDebugger registerToolsOn: Smalltalk tools. GTMoldableDebugger enableDebuggerWindowDistinctColor: true To install the white theme: GLMWhitespaceTheme defaultSettings: nil; setPreferredWorldBackground; beCurrent To install the fonts, you can just do this: #('SourceCodeProRegular' 'SourceCodeProBold' 'SourceSansProRegular' 'SourceSansProBold') do: [ :each | Smalltalk globals at: each asSymbol ifAbsent: [ Gofer new smalltalkhubUser: 'girba' project: 'FreeFonts'; package: each; load ]. (Smalltalk at: each asSymbol) new install ]. FreeTypeSystemSettings loadFt2Library: true. FreeTypeFontProvider current updateFromSystem Let me know how it goes. Cheers, Doru On Wed, Mar 19, 2014 at 8:24 AM, Max Leske <maxleske(a)gmail.com> wrote: > Hi > > I want to use the Moose UI tools for development and since I have a CI job > for the project I thought I could just load Moose and be done with it. That > doesn't seem to work however. > > I tried loading #development but when I do that I get the FallbackMenu > instead of the world menu and no new inspectors / browsers. Here are the > conditions of my build: > - I want to start my build from a fresh Pharo3 image > - I only want the Moose UI tools (I don't need any of the parsers etc.) > - it would be nice if, when I open a built image, the default tools are > already set to the Moose ones > > I know that there is a development Moose build for Pharo3, so I'm a bit > surprised that I can't just load the configuration... > > BTW: this is how I tried to load Moose (maybe I just screwed up the > configuration): > > baseline02: spec > <version: '0.2-baseline'> > > spec for: #common do: [ > spec blessing: #baseline. > > spec package: 'LibGit2Bindings' with: [ > spec repository: ' > http://smalltalkhub.com/mc/MaxLeske/LibGit2Bindings/main' ]. > > spec project: 'Moose' with: [ > spec > className: 'ConfigurationOfMoose'; > file: 'ConfigurationOfMoose'; > version: #development; > loads: #(Core UI); > repository: ' > http://smalltalkhub.com/mc/Moose/Moose/main' ]. > > spec package: 'Phexample' with: [ > spec repository: ' > http://smalltalkhub.com/mc/Phexample/Phexample/main' ]. > > spec repository: ' > http://smalltalkhub.com/mc/StefanMarr/LibGit/main'. > spec package: 'LibGit-Core' with: [ > spec > requires: #(Phexample LibGit2Bindings > Moose); > postLoadDoIt: #postLoadRecompile ] > ]. > > I'd appreciate any help (and if nobody helps me Doru will probably kick my > ass for still not using Moose :p) > > Cheers, > Max > -- www.tudorgirba.com "Every thing has its own flow"

10 years, 9 months

Using Moose => Questions

by Gabriela Arevalo (gmail)

Hi guys, I started to play with Moose, because I need to analyze some code to detect some bad smells. As I used Moose ** a long time ago ** I am bit confused (and also lost) with the way of using and manipulating the objects in the Moose panel. Just an example to explain what I need is that: 1- I loaded a package of Pharo (let's say Collections-Sequenceable) I can see all the information offered by the panel, but I would like to do is the following: a) How can I access to the information of the model, for example, to manipulate the methods of the analyzed classes? In previous versions of Moose, we could do something like MooseManager currentModel, but I see that the design has changed drastically, and now I can not see how I can do it. I need specifically access to the info stored in the model. b) I see that you are using pragmas to define how we calculate properties in each source code entity. For example in: FAMIXMethod numberOfInvokedMethods <MSEProperty: #numberOfInvokedMethods type: #Number> <MSEComment: 'Return a number corresponding to the number of invoked methods'> <derived> ^ self privateState propertyAt: #numberOfInvokedMethods ifAbsentPut: [self invokedMethods size] I added a new property with the same structure, but when I analyzed again a previous application, my new property is not appearing in the list of properties for a method in Moose. Should I call a special message, or make a class invoke another method to update the properties used to analyze the application? I will appreciate a lot your help. Cheers, Gabi

10 years, 9 months

← Newer
1
...
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev March 2014