Moose-dev November 2013

moose-dev@list.inf.unibe.ch

31 participants
160 discussions

by Tudor Girba

Hi, The latest Moose image comes with GTInspector and GTDebugger installed as default tools. GTDebugger is the result of the excellent work of Andrei. At the moment, the GTDebugger only replicates the behavior of the default debugger. The custom debuggers will follow soon. Both of these are part of the GToolkit. Just for reference: - GT-Debugger has 499 lines of code. - GT-Inspector has 484 lines of code. In other words, you could read the full code in the lunch break :). Here is a screenshot showing them: https://www.dropbox.com/s/hzxg82nzz163gb1/2013-11-15%2019.20.42%20-%20gtdeb… If you see issues, please report them. Cheers, Doru p.s. Unfortunately, we could not install the GTInspector alone in the Pharo image because the SpecDebugger still depends on the inspector being implemented in Spec. -- www.tudorgirba.com "Every thing has its own flow"

11 years, 1 month

New builder for Roassal: building geographical maps

by Alexandre Bergel

Hi! During our pair coding session on Friday, we worked on a new builder for Roassal. Here is short example: | builder | builder := ROFranceMapBuilder new. builder shape circle size: 15; color: Color red; withLabel. builder showCities: #('Paris' 'Lyon' 'Marseille'). builder shape circle size: 25; color: Color blue; withLabel. builder show: 'Nice'. builder open It should produce: There is no reference to external files. It runs out of the box. In case you got a sudden need to press a like button or do some retweet, here a bit of material: https://www.facebook.com/media/set/?set=a.543459092407359.1073741830.340543… https://twitter.com/objectprofile/status/401433558684008448 On our facebook account we have many more screenshots. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

11 years, 1 month

Moose releases

by Diego Lont

Hi all, I have the impression that moose releases are not very much used. I agree that our development process works great (a lot of progress), and that because of this most people working on or with moose use the development version and ignore the release version. At the moment how ever, I still use a pharo 2.0 based image and cannot take the latest development version (as this is pharo 3.0 based and moose 4.9 is frozen). So I tried to revert to using the releases. And there I ran into problems. Both release 4.8 and 4.9 don't work for me. - release 4.8 has a outdated grease version that causes the image to become unstable when you load something that uses grease. This is almost anything, so you can only use the image "as is" - the moose panel of release 4.9 needs to be closed and reopened. Loading PetitDelphi in this image causes several packages to be imported that only work in pharo 3.0. Note also that this is a barrier for new users. I tried to start the discussion on the moose list before how to improve this, but I got very little response. Note that these problems are easy to fix, but these fixes should be back ported to the release. At the moment I have no idea how I should do this, as the release is made with a snapshot, and that is hard to change. Snapshots work great to freeze, but are hard to maintain. PetitDelphi has a configuration that refers to PetitParser (development). PetitParser has a (loaded) configuration that refers to Glamour (development). Glamour has a (loaded) configuration. As the development version (also for pharo 2.0) refers to the latest version of the packages that only work in pharo 3.0. In PetitDelphi I do not want to change the version of PetitParser to the snapshot version, as here the groups not defined, and PetitDelphi only needs a part of PetitParser. So snapshotting the release, forces me to snapshot my configuration of PetitDelphi, and no longer use the configuration of PetitParser. I do not think that this is a good thing, that all projects depending on moose, should create a snapshot when moose is released. Note that this snapshot has to be made before other changes are made! Also continuing the development process on PetitDelphi would no longer work, as it uses a snapshot. I have the feeling that a snapshot really should not be related to a release and should be considered (and modeled as) a separate concept. Because the responsibility for snapshotting is that of the using project, not the owning project. In metaceller I made the possible to record the current loaded versions of a configuration, where it used the configuration. Meaning: of packages and used configurations in the configuration, the version is recorded (symbolic versions are replaced). I showed it to Doru and I could not convince him to use this. I am willing to put time and effort into the moose releases to improve them, but then I want to know what you think about this. Diego

11 years, 1 month

Issue 1005 in moose-technology: GTInspector should become the main inspector

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: chisvasi...(a)gmail.com Labels: Type-Enhancement Priority-Medium Component-GlamorousToolkit Milestone-5.0 New issue 1005 by tu...(a)tudorgirba.com: GTInspector should become the main inspector http://code.google.com/p/moose-technology/issues/detail?id=1005 Right now, we cannot install the GTInspector because the SpecDebugger from Pharo 3.0 depends on the inspector being implemented in Spec. The issue is reported on the Pharo tracker: https://pharo.fogbugz.com/f/cases/12055/The-Spec-Debugger-should-not-requir… -- 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

11 years, 1 month

Fwd: Auto-discard notification

by Gabriela Arevalo (gmail)

I tried again, but from iam email account. Cheers. Gabi ---------- Forwarded message ---------- > From: "Gabriela Arevalo (gmail)" <gabriela.b.arevalo(a)gmail.com> > To: Moose-related development <moose-dev(a)iam.unibe.ch> > Cc: > Date: Thu, 14 Nov 2013 15:00:24 -0200 > Subject: CAnalyzer or inFamix? > Hi guys, > > I need to import some C code into Moose (image you can download from the > website of Moose (http://www.moosetechnology.org/) > > I was checking the different tools we could find in Pharo, and there are > two tools: > > - CAnalyzer, and > - inFamix > > I loaded CAnalyzer in an image with Moose included in Pharo 3.0, and now > it seems that I should get the C code in an XML format using srcML. > > What is the active tool you guys suggest to use? I did not try yet with > inFamix. > > Cheers, > > Gabi -again trying to code :) > > -- www.tudorgirba.com "Every thing has its own flow"

11 years, 1 month

Issue 999 in moose-technology: VerveineJ: management of the anonymous class

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-VerveineJ New issue 999 by anne.et...(a)gmail.com: VerveineJ: management of the anonymous class http://code.google.com/p/moose-technology/issues/detail?id=999 Describe the problem: what do you get? what do you expect? According to the definition of FAMIXType >>isAnonymousClass ^ self container isMethod or: [ self name isAllDigits or: [ '*_anonymous_*' match: self name ]] But VerveineJ does not follow the same pattern to name the anonymous classes. Currently, there is no _ in the name of the anonymous class. So if the container of the anonymous class is not a method, it won't be recognized as such. 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

11 years, 1 month

Issue 998 in moose-technology: VerveineJ: Method in EnumValue -> anonymous or inner class

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-VerveineJ New issue 998 by anne.et...(a)gmail.com: VerveineJ: Method in EnumValue -> anonymous or inner class http://code.google.com/p/moose-technology/issues/detail?id=998 Consider the following Java code (real one, got from FindBugs plugin). There are some method definitions in Enum Value. How VerveineJ should consider the enum values? as anonymous or inner classes? If it is inner classes the definition of innerClass method has to be modified since it considers only that the container is a class (and not a type). enum FilterKind { INCLUDE("property.includefilter") { Collection<String> selectedFiles(UserPreferences u) { return u.getIncludeFilterFiles(); } Collection<String> excludedFiles(UserPreferences u) { return u.getExcludeFilterFiles(); } void setFiles(UserPreferences u, Collection<String> files) { u.setIncludeFilterFiles(files); } }, EXCLUDE("property.excludefilter") { Collection<String> selectedFiles(UserPreferences u) { return u.getExcludeFilterFiles(); } Collection<String> excludedFiles(UserPreferences u) { return u.getIncludeFilterFiles(); } void setFiles(UserPreferences u, Collection<String> files) { u.setExcludeFilterFiles(files); } }, EXCLUDE_BUGS("property.excludebugs") { Collection<String> selectedFiles(UserPreferences u) { return u.getExcludeBugsFiles(); } Collection<String> excludedFiles(UserPreferences u) { return Collections.emptyList(); } void setFiles(UserPreferences u, Collection<String> files) { u.setExcludeBugsFiles(files); } }; final String propertyName; FilterKind(String propertyName) { this.propertyName = propertyName; } abstract Collection<String> selectedFiles(UserPreferences u); abstract Collection<String> excludedFiles(UserPreferences u); abstract void setFiles(UserPreferences u, Collection<String> files); } Additional information: platform, context which may impact the problem 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

11 years, 1 month

Issue 997 in moose-technology: Inspector: "MenuModel(Object)>>doesNotUnderstand: #add:target:selector:"

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 997 by anne.et...(a)gmail.com: Inspector: "MenuModel(Object)>>doesNotUnderstand: #add:target:selector:" http://code.google.com/p/moose-technology/issues/detail?id=997 Describe the problem: what do you get? what do you expect? MenuModel(Object)>>doesNotUnderstand: #add:target:selector: when using the inspector in Moose-5.0 How to reproduce the problem: step by step if necessary Open an image. Execute a piece of code (in a workspace for example) and inspect the result. If the result is an entity (and not a collection), right clic on an element of the left column (but neither the class nor the all inst vars). A pop up window with MenuModel(Object)>>doesNotUnderstand: #add:target:selector: appears. So it is not possible to use the inspector in Moose 5.0 Additional information: platform, context which may impact the problem I tried only on Mac Please fill in the labels with the following information: Type-Defect, Component-5.0 -- 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

11 years, 1 month

Issue 1001 in moose-technology: Pharo: Moose: unable to get information from Dr. Geo packages.

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 1001 by matttbe: Pharo: Moose: unable to get information from Dr. Geo packages. http://code.google.com/p/moose-technology/issues/detail?id=1001 Hello, First, thank you for developing this free and OpenSource platform! > Describe the problem: what do you get? what do you expect? With the latest version of the Moose Suite, I'm not able to analyse data from Dr. Geo packages: the Moose panel is empty. > How to reproduce the problem: step by step if necessary From Moose Suite 4.9 image and Pharo 2: * Install DrGeo with these commands: Gofer new url: 'http://www.squeaksource.com/DrGeoII' ; package: 'ConfigurationOfDrGeo'; load. (Smalltalk at: #ConfigurationOfDrGeo) perform:#load. * Open the Moose Panel / st / select all DrGeoII-* packages / Next / Finished * Select the new model: there is nothing in the panel! Here is a http://uppix.com/f-Capture_du_2013_5284a4e800148d17.png > Additional information: platform, context which may impact the problem I also tested with another image where Moose was already installed but I have the same problem. I'm using Pharo 2 on Linux but it seems that we also have this problem when using it on Windows. Note that I was able to have something in Moose Panel by doing that: * Open the Moose Panel / st / select random packages (e.g. I tried with PetitParser* packages) / Next / Finished * Select the new model: everything seems fine * Don't close the Moose Panel and install Dr. Geo from the workspace * Switch to the Moose Panel window / st / select DrGeoII-* packages / Next / Finished * Select this new model: we can see boxes and select lines but all graphs are empty! Feel free to ask if you need additional information! Thank you for your help, Matt -- 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

11 years, 1 month

Issue 658 in moose-technology: write a test for MooseMenu entries

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 658 by jannik.l...(a)gmail.com: write a test for MooseMenu entries http://code.google.com/p/moose-technology/issues/detail?id=658 We need a test that take all entries in Moose Browser and test them, to avoid DNU and other kind.

11 years, 1 month

← Newer
1
...
7
8
9
10
11
12
13
...
16
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev November 2013