- Moose-dev - INF Mailman

Moving Moose-Core to Moose project in SmalltalkHub

by Usman Bhatti

We are working today to move all Moose package in Moose repo in SqueakSource to SmalltalkHub, update the config and test these packages on both 1.4 and 2.0.

12 years, 4 months

1
0
0 0

Moose on pharo 2.0 -> moving it STHub

by Usman Bhatti

Hello all, Today, we worked on moving Moose on pharo2.0. We needed to update a few baselines because some packages were already present in Pharo2.0. For example, - RPackage is already present in Pharo 2.0, so no need to load it in the image. - PetitParser loads Glamour, which loads NECompletion and NEC does not have configuration for pharo2.0. We decided to move all the moose code to STHub before porting it to 2.0 so that we can save changes somewhere. Some projects are created in STHub in the Moose team: Fame (Moved all code from FAME on squeaksource to STHub, updated configurationOf to load from STHub + creating a version with latest dev.) Glamour (in the process of downloading packages but its taking long, but glamour will be difficult because it has dependencies with other projects so may be it should be moved incrementally. Doru, I think you can take lead on that since you know the project better) Moose (FAMIX + Moose-Core, downloading packages, will be committing next week) PetitParser (will be moved next week too) For people interested in moving code, here are the scripts for fetch and push. ================================== "fetch all FAME packages from their repository" | go | go := Gofer new squeaksource: 'Fame'. ((go allResolved select: [:aPac |'*Fam*' match: aPac packageName ]) do: [:each | self crLog: each packageName. go package: each packageName. Transcript show: each printString ; cr. go fetch.]). ====================================== "commit all FAME packages into the smalltalkhub FAME project" |go repo| repo := MCSmalltalkhubRepository owner: 'Moose' project: 'Fame' user: 'XXX' password: 'XXX'. go := Gofer new. go repository: repo. (((FileSystem disk workingDirectory / 'package-cache') allFiles select: [:each | '*Fame*.mcz' match: each basename]) groupedBy: [:each | (each base copyUpToLast: $-) ]) keys do: [:name | go package: name; push] Now, moving to Pharo2.0 is important, so it will be good to kill this boring task by working collaboratively :-) Usman P.S: The last step of moving every project is to create a new baseline to point to STHub for the project and preferably create a version with that baseline.

12 years, 4 months

6
8
0 0

I started to migrate Merlin

by Stéphane Ducasse

Hi guys I started to migrate Merlin. Now I published all the packages to the Moose/Merlin project. Stef

12 years, 4 months

3
3
0 0

Fame is migrated

by Stéphane Ducasse

Hi guys - I fixed the 1.4 stable and development specification (do not use common) - I produced a version for 2.0 Now I do not understand why the tests are red in 1.4 and 2.0 199 run, 193 passes, 0 expected failures, 0 failures, 6 errors, 0 unexpected passes Failures: Errors: FMExporterTest>>#testExportAsMSE FMExporterTest>>#testExportAsXML FMMetaRepositoryFilterTest>>#testExportAsMSE FMMetaRepositoryFilterTest>>#testExportAsXML FMLibraryExample>>#testPrintMetamodel FMLibraryExample>>#testPrintModel I will check to see if I can fix them. But to me it looks like a bad practice to have red tests. Stef

12 years, 4 months

3
7
0 0

Glamour tree presentation - red square of death

by Ben Coman

I am having some trouble with a with a tree presentation in Glamour being replaced with red square with a yellow cross. How can I attach troubleshooting this? Naively I tried wrapping each of the blocks passed with exception handling as follows.... ---- a tree updateOn: LEKShownClassesChanged from: self announcer when: [ :ann :entity | [ self setNavigatorIconsFor: LEKCimPackage rootPackage ] on: Exception do: [ self inform: 'upDateOn error' ] . true ] ; children: [ :item | [ item children sort: [ :before :after | before cimName < after cimName ] ] on: Exception do: [ self inform: 'children error' ] ] ; format: [ :item | [ item cimName ] on: Exception do: [ self inform: 'format error' ] ] ; act: [ :presentation :model | self shownClasses inspect ] entitled: 'selected package classes' ; icon: [ :item | [ self navigatorIconFor: item ] on: Exception do: [ self inform: 'icon error' ] ] ; ---- and also similarly wrapping the rendering... ---- GLMMorphicTreeRenderer>>render: aPresentation | container | [ container := super render: aPresentation. aPresentation shouldAllExpand ifTrue: [container submorphs first expandAll ]. aPresentation shouldRootsExpand ifTrue: [container submorphs first expandRoots ]. ] on: Exception do: [ self inform: 'render error' ]. Transcript crShow: container. ^ container ---- but nothing happens. Where does the red square get generated from? So I can try making a debugger come up instead of the red square. cheers, Ben

12 years, 5 months

1
0
0 0

Migrated HashTable from ss to SmalltalkHub

by Stéphane Ducasse

- migrated all the history - defined configurationOf - All tests are green under 1.4 and 2.0 Stef

12 years, 5 months

1
0
0 0

Moose on pharo 2.0

by Usman Bhatti

Hello, Tomorrow, there is a pharo sprint in Lille. We, people working on Moose in Lille, thought of doing a Moose sprint/dojo and the purpose is to port Moose on Pharo 2.0. Is there someone who has tried to make Moose work on Pharo 2.0? If so, do we have a list of bugs for Moose 4.8 that we can kill tomorrow? Usman

12 years, 5 months

1
0
0 0

marea

by Tudor Girba

Hi Mariano, I just stumbled across the paper, and it looks really nice. I definitely would like to have it used in Moose. I actually started to prototype a cache based on Fuel, but obviously Marea is way better. In the paper, you mention that the use in Moose is to be able to handle multiple models. That is a use case, but I think it's not a critical one. A more interesting use case is the one in which we want to store an AST alongside FAMIX. There are two challenges here: - The size of AST data is really prohibitive for being loaded in memory all the time - For the AST to be most valuable, we need to be able to link parts of the model to the corresponding AST nodes. See the picture in the attachment for an example: an invocation between methodA and methodB would have a corresponding message send node in the AST of methodA. If I understand Marea right, we could consider as roots all the AST root nodes, and essentially have them all swapped until we get to use one for some detailed analysis such as whether the invocation happens inside a loop or not. Is that correct? Cheers, Doru -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it."

12 years, 5 months

1
0
0 0

VerveineJ: analyse Eclipse

by Damien Cassou

Hi, is it possible to analyse Eclipse source code with VerveineJ? I always got various OutOfMemoryException Thank you -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

12 years, 5 months

3
2
0 0

PPTextHighlighter removed/moved

by Andrei Vasile Chis

Hi, In the latest version from jenkins the MoosePanel in not very usable because PPTextHighlighter is missing from the image, and it's still used in FAMIXJavaSourceLanguage and MooseMSEFilesExplorer. I saw it was removes in the latest version of PetitGui. Cheers, Andrei

12 years, 5 months

2
1
0 0

The idea behind "derived" pragma

by Yuriy Tymchuk

Hi everyone! I have a question about a <derived> pragma. As stated on http://code.google.com/p/moose-technology/wiki/FameMetaDescriptions : <derived> the property value can be derived from other properties (no need for persistence). So I have a question: why are for example localVariables and parameters of a FAMIXBehaviouralEntity derived when they are stored in the instance variable? Regards Yuriy -- View this message in context: http://moose-dev.97923.n3.nabble.com/The-idea-behind-derived-pragma-tp40260… Sent from the moose-dev mailing list archive at Nabble.com.

12 years, 5 months

2
2
0 0

Issue 880 in moose-technology: Improving VerveineJ stub invocations/methods

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: anquetil...(a)gmail.com Labels: Type-Enhancement Priority-Medium Component-VerveineJ Milestone-4.7 New issue 880 by andreho...(a)gmail.com: Improving VerveineJ stub invocations/methods http://code.google.com/p/moose-technology/issues/detail?id=880 When creating models without classpath, invocations/methods (where the biding are not found) are created in the format: anInvocation(???) This is the case even if the real invocation in source code contains parameters such as: anInvocation(a, b) It would be good maintain the information with respect to the number of parameters in such invocation/method, and then export the #signature with something like: anInvocation(?, ?) Like that we can at least count the number of parameters.

12 years, 5 months

1
14
0 0

Issue 909 in moose-technology: FAMIXNamedEntity>>receivingInvocations ?!?

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Famix New issue 909 by anquetil...(a)gmail.com: FAMIXNamedEntity>>receivingInvocations ?!? http://code.google.com/p/moose-technology/issues/detail?id=909 Why is there a receivingInvocations attribute in FAMIXNamedEntity ? Is that a remnant of MooseCook ?

12 years, 5 months

1
2
0 0

Issue 838 in moose-technology: VerveineJ does not export non-javadoc comments

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: anquetil...(a)gmail.com Labels: Type-Defect Priority-Medium Component-VerveineJ New issue 838 by tudor.gi...(a)gmail.com: VerveineJ does not export non-javadoc comments http://code.google.com/p/moose-technology/issues/detail?id=838 VerveineJ exports javadoc comments for both types and methods. However, it does not export line comments like: //This is also a relevant comment

12 years, 5 months

1
2
0 0

Issue 908 in moose-technology: Kiviat should have popups

by moose-technology＠googlecode.com

Status: New Owner: andreho...(a)gmail.com Labels: Type-Enhancement Priority-Medium Component-EyeSee Milestone-4.8 New issue 908 by andreho...(a)gmail.com: Kiviat should have popups http://code.google.com/p/moose-technology/issues/detail?id=908 Kiviat diagrams should have popups which is not possible now.

12 years, 5 months

1
2
0 0

How to organize Moose on SmalltalkHub

by Stéphane Ducasse

Hi doru I have some scripts (available in the wonderful chapter on Gofer) to migrate code from ss and ss3 to SmalltalkHub. Now the question is how do we organize moose? I propose to create a team Moosers? and Moose as a project Then what do we put underneath? Fame as subproject? Mondrian Metanool Stef

12 years, 5 months

3
5
0 0

Freezing version Moose-based tools

by Stéphane Ducasse

Hi guys I finished to find a stupid bug today. Now the moose reloader works. The idea is that you can freeze a complete Moose tools and be able to take a 1.4 image and reload all the packages that were loaded when you snapshot it. I could reload the latest version of Moose in a 1.4 image. I published the result on ConfigurationOfMoose. Gofer new url: 'http://smalltalkhub.com/mc/StephaneDucasse/MooseReloader/main' username: '' password: ''; package: 'ReloaderForMoose'; load Here is the comment of this class. I'm a kind of saver/loader that knows how to save and load list of packages by recursively navigating metacello configurationOf. To work I need a metacello record and a place to save package version. Here are examples to create a spec of packages to be saved. =========================================== In an image containing the loaded configuration of the tools you want to version execute the following: Reloader new configurationRecordInput: (((Smalltalk globals at: #ConfigurationOfMoose) project version: 'default') ignoreImage: true; record) ; repositoryClass: MooseConfigurationRepositoryForPharo14; publishNewVersion Reloader new configurationRecordInput: (((Smalltalk globals at: #ConfigurationOfMoose) project version: 'default') ignoreImage: true; record) ; repositoryClass: ConfigurationOfMoose; publishNewVersion It will produce a method called scriptXxx in the repositoryClass you specify. Here is an example of such method. script5 ^ #( #('ConfigurationOfFame-StephaneDucasse.6.mcz' 'http://www.squeaksource.com/Fame/' 'ConfigurationOfFame' ) #('ConfigurationOfMooseAlgos-TudorGirba.28.mcz' 'http://www.squeaksource.com/MooseAlgos/' 'ConfigurationOfMooseAlgos' ) ...... ) You can then use this method as follows, for example in a ConfigurationOf you can flatVersion47: spec <version: '4.7-flat'> spec for: #common do: [ self populateSpec: spec with: self script5 ] Note that the populateSpec: with: is generated when necessary. Reloading. =================================== In another image you can reload the configuration in two different ways: either by using metacello or by using the reloader. Using metacello is simple if you created a method similar to flatVersion47: spec <version: '4.7-flat'> spec for: #common do: [ self populateSpec: spec with: self script5 ] just execute (ConfigurationOfMoose project version: '4.7-flat') load If you do not use a configurationOf you can simply invoke the method reload: with the number of the script using the method reload: aNumber and it will load all the packages you previously specified. reloadLatest will load the latest script version Typical use cases are: ------------------------------------ Reloader new repositoryClass: MooseConfigurationRepositoryForPharo14; reload: 2 Reloader new repositoryClass: SynectiqueCaseOneConfigurationRepository; publishNewVersion Reloader new repositoryClass: SynectiqueCaseOneConfigurationRepository; loginSpecification: {{ '*squeaksource*' . 'sd' . 'xyxyx'} . { '*ss3*' . 'StephaneDucasse' . 'xxxx'} . { '*' . '' . ''}}; reload: 2 =================================================== Implementation Notes. First version fully working on metacello records. Let me know if it works for you. Stef

12 years, 5 months

3
4
0 0

Re: Issue 865 in moose-technology: Reloader should get the list of packages to be loaded from the ConfigurationOfMoose

by moose-technology＠googlecode.com

Comment #2 on issue 865 by tu...(a)tudorgirba.com: Reloader should get the list of packages to be loaded from the ConfigurationOfMoose http://code.google.com/p/moose-technology/issues/detail?id=865 The problem is that we still cannot quite obtain the list of packages from Metacello in proper order.

12 years, 5 months

1
1
0 0

Issue 851 in moose-technology: Create a stable version for Moose and all its subparts

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Engineering Priority-Medium Maintainability Milestone-4.7 New issue 851 by tu...(a)tudorgirba.com: Create a stable version for Moose and all its subparts http://code.google.com/p/moose-technology/issues/detail?id=851 The configuration of Moose should be versionned, especially for a release. We have to investigate if Reloader is good enough for 4.7.

12 years, 5 months

1
4
0 0

the build is green

by Tudor Girba

Hi, Thanks to the fix of Stef and the rapid Roassal fix of Alex, we now have a green build: http://ci.moosetechnology.org/job/moose-latest-dev/ So, we are pretty much ready for the release. Cheers, Doru -- www.tudorgirba.com "If you can't say why something is relevant, it probably isn't."

12 years, 5 months

4
4
0 0

Roassal vision - animated layout algorithm

by Ben Coman

Just an idea floating through my head (its good to let them out before they do too much damage in there) ... It seems lots of research continues to goes into improving layouting algorithms. I think Roassal could provide a good basis to visualize the operation of a layout algorithm as an animation. This could be useful to researchers as well as teaching demonstrations to students. The benefit for Roassal of being 'the platform' for researchers to develop and test their layout algorithms, would be ending up with all the latest and greatest of these built-in. Perhaps a student project... One alternative could be a framework that manually inserted #signalUpdate's at significant points of the algorithm. Another could being extending the Smalltalk debugger to automatically send #signalUpdate's with each step. cheers -ben

12 years, 5 months

2
1
0 0

Glamour-roassal does not unsubscribe when browser error

by Usman Bhatti

Hello, I had a "Not enough memory" problem in my Moose image so digging the error (with Jean-Baptiste) reveals that when there is an error in a glamour browser, roassal visualization does not unsubscribe events. In my case, it retained the browser objects in the memory because these were pointed to by the subscriptions and this the browser was not releasing my MooseModel. To reproduce the problem, you can execute the script below. On the right pane, right click on any node and then do, "select in tree". Close browser, garbage collect, and then do: MOAnnouncer allInstances. There are few instances related to MOAnnouncer that exist in the memory. Without the error, these objects disappear. Can you please have a look? tx, Usman | browser items | browser := GLMTabulator withStatusbar. items := 50. browser column: #one; column: #two. browser transmit to: #one; andShow: [ :a | (a tree) title: 'Tree'; showOnly: 30; display: [:each | 1 to: items]; children: [ :item :x :level | level > 1 ifTrue: [ #() ] ifFalse: [ 1 to: item ]]]. browser transmit to: #two; from: #one; andShow: [ :a | a mondrian title: 'Numbers in Mondrian list'; painting: [:view :number | view interaction item: 'Select in tree' action: [:each | ((browser paneNamed: #one) port:#selection) value:41 ]. view interaction on: ROMouseEnter do: [ :n | ]. view shape rectangle size: 10. view nodes: (Collection withAllSubclasses). view edgesFrom: #superclass. view treeLayout. ] ]. browser openOn: 1

12 years, 5 months

3
4
0 0

Issue 903 in moose-technology: ROEdge without ROLine locks the image

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 903 by benjamin...(a)gmail.com: ROEdge without ROLine locks the image http://code.google.com/p/moose-technology/issues/detail?id=903 I have isolated the problem with the image locking up when ROEdge is used without ROLine. I noticed that problem occurred also when using ROAbstractLine instead of ROLine. So hacking breakpoints & logging into the four methods of ROLine lead me to these being called on from ROEdge on instance variable 'shape'. Looking at references of 'shape', I notice that ROEdge adds three methods that RONullShape does not have. So the image can be prevented from locking up with the following ugly hack... ROEdge>>contains: aPoint (shape isKindOf: RONullShape) ifTrue: [ ^false]. ^ shape contains: aPoint for: self ROEdge>>topLeft (shape isKindOf: RONullShape) ifTrue: [ ^ 0@0 ]. ^ (shape lineSegmentsFor: self) first I'll leave it there for Alexandre to come up with a more appropriate fix. cheers -ben Ben Coman wrote: > I can reproduce this on Windows 7 in Moose-4.7-beta from 2012-01-03 > (ConfigurationOfRoassal.A...B...752) > With the ROLine commented as shown below the image locks. Alt-. fails to > interrupt. > With the ROLine uncommented it works fine. > Forgetting ROLine is likely a common occurance for people new to Roassal, > so > this makes it a bit fragile. > --- > | view node1 node2 edge | > view := ROView new. > node1 := ROLabel elementOn: 'node1'. > node2 := ROLabel elementOn: 'node2'. > edge := (ROEdge from: node1 to: node2) "+ ROLine" . > view add: node1; add: node2; add: edge. > view open > --- > cheers -ben > Alexandre Bergel wrote: > > Hi Yuriy! > > > > I guess you meant "view add: edge; add: node1; add: node2." instead of > using "rawView". > > The script does not freeze the VM I use (Croquet Cog 4.0.2636 and the > one contained in the Pharo 1.4 one click). > > In fact, having an edge without line is perfectly okay. No error is > raised and none should be raised. The line is simply invisible. Strange > that you got this error. > > > > Anyone can reproduce this error? > > > > Cheers, > > Alexandre > > > > > > On Jan 25, 2013, at 10:37 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > wrote: > > > > > >> Hi. > >> > >> When edges are initialized without lines, VM freezes. > >> > >> For instance when I run next code: > >> > >> | view node1 node2 edge | > >> view := ROView new. > >> node1 := ROLabel elementOn: 'node1'. > >> node2 := ROLabel elementOn: 'node2'. > >> node1 @ RODraggable. > >> node2 @ RODraggable. > >> edge := ROEdge from: node1 to: node2. > >> rawView add: edge; add: node1; add: node2. > >> ROHorizontalLineLayout on: (Array with: node1 with: node2). > >> view open > >> > >> > >> I know that you should do something like > >> > >> edge + (ROLine red). > >> > >> But Roasal shouldnt freeze the VM anyway :) > >> > >> > >> > >> -- > >> View this message in context: > http://moose-dev.97923.n3.nabble.com/Roasal-freezing-VM-tp4025992.html > >> Sent from the moose-dev mailing list archive at Nabble.com. > >> _______________________________________________ > >> Moose-dev mailing list > >> Moose-dev(a)iam.unibe.ch > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > > > >

12 years, 5 months

1
4
0 0

Roasal freezing VM

by Yuriy Tymchuk

Hi. When edges are initialized without lines, VM freezes. For instance when I run next code: | view node1 node2 edge | view := ROView new. node1 := ROLabel elementOn: 'node1'. node2 := ROLabel elementOn: 'node2'. node1 @ RODraggable. node2 @ RODraggable. edge := ROEdge from: node1 to: node2. rawView add: edge; add: node1; add: node2. ROHorizontalLineLayout on: (Array with: node1 with: node2). view open I know that you should do something like edge + (ROLine red). But Roasal shouldnt freeze the VM anyway :) -- View this message in context: http://moose-dev.97923.n3.nabble.com/Roasal-freezing-VM-tp4025992.html Sent from the moose-dev mailing list archive at Nabble.com.

12 years, 5 months

3
5
0 0

roassal development version is unloadable

by Tudor Girba

Hi, I am looking into testing the fix of Stef to go around the PharoTaskForces problem, but now I have another problem: ConfigurationOfRoassal>>development is unloadable because version 1.266 needs to load RoassalMorphic-DR.108 which does not exist in the squeaksource repository. Alex, can you look into this, please? Cheers, Doru -- www.tudorgirba.com "Presenting is storytelling."

12 years, 5 months

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev