Moose-dev September 2013

moose-dev@list.inf.unibe.ch

30 participants
148 discussions

Changes to Famix-Core, Moose-Core & Moose-MonticelloImporter safe?

by Stephan Eggermont

When trying to walk smalltalkhub and import latest versions to find invocations, we needed to make the following changes to make it work: FAMIXAccess>variable: aStructuralEntity (aStructuralEntity isKindOf: FAMIXAnnotationInstanceAttribute) ifFalse: [ variable := FMMultivalueLink on: self update: #incomingAccesses from: self variable to: aStructuralEntity] Add MooseMonticelloVisitor>visitScriptDefinition: aMCPostscriptDefinition "TODO" MooseMonticelloHTTPImporter>setRepositoryCache: aCache. repositoryCache := aCache MooseMonticelloMethodPopulator>ensureAnnotationType: aRBPragmaNode ^self importer ensureAnnotationType: aRBPragmaNode. And change for performance: MooseGroupRuntimeStorage>add: anElement | key group | key := anElement class. group := byType at: key ifAbsentPut: [ OrderedCollection new ]. group add: anElement. elements add: anElement. byName at: anElement mooseName asSymbol put: anElement. ^ anElement MooseGroupRuntimeStorage >at: uniqueName ifAbsent: exceptionBlock | entity na | na := uniqueName asSymbol. "look first by name and if not found" entity := byName at: na ifAbsent: [nil]. entity notNil ifTrue: [ entity mooseName asSymbol = na ifTrue: [ ^entity] ifFalse: [ byName at: na put: nil. byName at: entity mooseName asSymbol put: entity. self halt. "Should this be happening?" ]]. ^ exceptionBlock value Would they be safe to commit?

11 years, 3 months

Namespace tree calculation for java

by Stephan Eggermont

This looks like a rather slow way to calculate a namespace tree. I'm pretty sure it can be done in such a way that a Task is not needed. MooseModel>inferNamespaceParentsBasedOnNames <menuItem: 'Infer Namespace Parents Based on Names' category: 'Utilities'> | parent parentNameSize currentPosition parentName namespaces | namespaces := self allNamespaces. MooseCustomTask new with: [:task | namespaces do: [ :each | currentPosition := 1. each name: (each name copyReplaceAll: '.' with: '::'). [ currentPosition := each name indexOf: $: startingAt: currentPosition. currentPosition isZero not ] whileTrue: [ parentName := (each name copyFrom: 1 to: currentPosition - 1) asSymbol. namespaces detect: [ :x | parentName = x mooseName ] ifNone: [ | newNamespace | newNamespace := FAMIXNamespace new name: parentName. namespaces add: newNamespace. self add: newNamespace ]. currentPosition := currentPosition + 2 ]. task increment]. namespaces do: [ :each | each belongsTo isNil ifTrue: [ parentNameSize := (each name lastIndexOf: $:) - 2. parentNameSize > 0 ifTrue: [ parent := namespaces detect: [ :x | (each name copyFrom: 1 to: parentNameSize) asSymbol = x mooseName ] ifNone: [ nil ]. parent isNil ifFalse: [ each name: (each name copyFrom: parentNameSize + 3 to: each name size) asSymbol. each parentScope: parent ] ] ]. task increment] ] description: 'Infer namespace parents based on names' length: (namespaces size * 2); runWithProgress. ^ self allNamespaces

11 years, 3 months

Jenkins build is back to stable : moose-latest-dev-4.8 #1129

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/1129/>

11 years, 3 months

Jenkins build became unstable: moose-latest-dev-4.8 #1127

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/1127/>

11 years, 3 months

Re: Changes to Famix-Core, Moose-Core & Moose-MonticelloImporter safe?

by Stephan Eggermont

I wrote: >FAMIXAccess>variable: aStructuralEntity > (aStructuralEntity isKindOf: FAMIXAnnotationInstanceAttribute) ifFalse: [ > variable := FMMultivalueLink on: self > update: #incomingAccesses > from: self variable > to: aStructuralEntity] Dory wrote: >This is strange. Why do you need that? We tried to do findDeprecationsFor: aVersion in: aProject | mooseModel | mooseModel := (MooseMonticelloHTTPImporter new setRepositoryCache: aProject monticelloRepository; importFileNamed: (aVersion at: #filename)). mooseModel allInvocations do: [ :each| aProject addInvocation: each inVersion: aVersion ]

11 years, 3 months

Snapshot Release

by Diego Lont

Hi all, I like moose a lot, but I have a problem with the way the moose configurations are used. So I would like to discuss this on the developers list. I would like to know if more people experience these problems. First of all, I like the way the development works out. All development configurations simply do not use any version numbers, and therefor return the latest version. Maybe we should create an actual development version, that is empty, except for the packages we want to be a fixed version. But this is a minor point. But once moose is released, a snapshot is taken, it is no longer a proper configuration. Main drawback is that all groups and such are removed. But also referred configurations are no longer used. I believe it should be possible to upgrade to the stable version of a configuration in the place where a development version was used. Especially when the development version is released. Taking snapshots prevents this, since it no longer contains groups. Also I think that bug fixes of used configurations should be imported automatically. Taking snapshots prevents this, since they do not use used configurations. Finally there is a scenario that actually breaks configurations downstream. When I load version 1.6-baseline of PetitParser and sub sequentially ask for the current version, it returns 1.7-snapshot. But since I try to load the 'Core' group of PetitParser, I can no longer use my configuration. It simply halts on the error that the group 'Core' could not be found. I have two suggestions to improve the process: > We either choose to stick to snapshots for the releases, since this is a very reliable way to reproduce a build (with all known bugs). But for this we create a class SnapshotOf<projectname>, for each project, with all the methods needed, to indicate it is not a configuration. We could add previous releases to this class. > We create a proper stable version, in the way configurations are meant to be. We bless these methods with release and only update versions if it is a bug fix. We also create a new development version at the moment we make the release, so we can continue development, without breaking the release For the last suggestion I have updated my Metaceller tool (part of GToolkit). It is still beta, but it produces proper release version for a single configuration, based on the current state of the image. Regards, Diego

11 years, 3 months

Make edges not clickable in Roassal visualization from within a Glamour browser

by Damien Cassou

Please answer at: http://stackoverflow.com/questions/18829093/make-edges-not-clickable-in-roa… -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

11 years, 3 months

MooseGroupRuntimeStorage implementation

by Stephan Eggermont

While trying to import some monticello packages from smalltalkhub with a MooseMonticelloHTTPImporter, we noticed some less nice behavior from the MooseGroupRuntimeStorage. at: ifAbsent is really slow when byName contains 128 elements and elements 64K. What is the usecase for putting the elements in an OrderedCollection? Doing byName at: anElement mooseName asSymbol put: anElement. in add: makes it perform a lot better. Is there a usecase where you don't want byName to be filled immediately? Diego & Stephan

11 years, 3 months

MooseDay - any news?

by Andrei Vasile Chis

Hi, Will the moose day still take place? If yes is the date fixed? Cheers, Andrei

11 years, 3 months

Roassal 3D

by Usman Bhatti

Hi Alex, I would like to play a bit with Roassal 3D, I'm looking for a link to load and run my first examples ;). tx. Usman

11 years, 3 months

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev September 2013