Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

by Tudor Girba

I am still on holidays, but I could not help to notice that all sorts of tests are failing :). Please take a look: https://ci.inria.fr/moose/ Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

12 years

Issue 907 in moose-technology: VerveineJ does not export source anchors for FAMIXAnnotationType and FAMIXAnnotationTypeAttribute

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: anquetil...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Famix New issue 907 by tu...(a)tudorgirba.com: VerveineJ does not export source anchors for FAMIXAnnotationType and FAMIXAnnotationTypeAttribute http://code.google.com/p/moose-technology/issues/detail?id=907 When we have an explicit annotation in the code, we should also get the source anchor associated with it. For example, in the below case, SomeAnnotation.java should be associated with SomeAnnotation: SomeAnnotation.java @Documented @Target({ ElementType.FIELD }) @Retention(RetentionPolicy.CLASS) public @interface SomeAnnotation {...} The same applies for the contained FAMIXAnnotationTypeAttributes.

12 years

PetitJava performance

by Stephan Eggermont

While working on PetitDelphi, we noticed significant performance problems. As PetitDelphi copied the design of PetitJava, we found the same root cause. When creating a new java parser, a significant amount of time is spend on initialization, especially the creation of parsers for keywords, separators and operators. The introduction of a lexicon cache allows the tests to run significantly faster. 2230 ms to 224ms the second time. PetitJava-DiegoLont.115 Yuriy, can you merge? Stephan

12 years

Build failed in Jenkins: moose-latest-dev-4.8 #588

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/588/> ------------------------------------------ Started by upstream project "petitjava" build number 89 originally caused by: [URLTrigger] A change within the response URL invocation (log) Building remotely on moose-ubuntu1204-dualproc-i386 in workspace <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/> Deleting project workspace... done [moose-latest-dev-4.8] $ /bin/sh -xe /tmp/hudson7862730162219260867.sh + + bash wget --quiet -O - http://get.pharo.org/20+vm Downloading the latest 20 Image: http://files.pharo.org/image/20/latest.zip Pharo.image Downloading the latest pharoVM: http://files.pharo.org/vm/pharo/linux/stable.zip pharo-vm/pharo Downloading PharoV10.sources: http://files.pharo.org/sources//PharoV10.sources.zip Downloading PharoV20.sources: http://files.pharo.org/sources//PharoV20.sources.zip Creating starter scripts pharo and pharo-ui Please install the 32bit libraries sudo aptitude install ia32-libs + ./pharo Pharo.image save moose-latest-dev-4.8 + REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main + ./pharo moose-latest-dev-4.8.image config http://www.smalltalkhub.com/mc/Moose/Moose/main ConfigurationOfMoose --install=development [31m[33m =============================================================================== Notice: Installing ConfigurationOfMoose development =============================================================================== [0m[0m[31m==== Startup Error: MetacelloProjectSpecLoadError: No version found for '#stable' of ConfigurationOfNewDebugger [0mMetacelloMCProjectSpec>>loadVersion: MetacelloMCProjectSpec>>load MetacelloProjectReferenceSpec>>loadUsing:gofer: MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories: in Block: [:pkg | pkg loadUsing: self gofer: gofer] OrderedCollection>>do: MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories: MetacelloFetchingMCSpecLoader>>atomicLoadPackageSpecs:repositories: in Block: [super linearLoadPackageSpecs: packageSpecs reposi...etc... BlockClosure>>ensure: MetacelloLoaderPolicy>>pushLoadDirective:during: MetacelloLoaderPolicy>>pushAtomicLoadDirectivesDuring:for: MetacelloFetchingMCSpecLoader>>atomicLoadPackageSpecs:repositories: MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>load MetacelloMCVersionSpecLoader>>load MetacelloMCVersion>>executeLoadFromArray: MetacelloMCVersion>>fetchRequiredFromArray: in Block: [:dict | ^ self executeLoadFromArray: anArray] MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: in Block: [^ aBlock value: dict] BlockClosure>>on:do: MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: MetacelloMCVersion>>fetchRequiredFromArray: in Block: [self versionSpec loader: newLoader.... BlockClosure>>ensure: MetacelloMCVersion>>fetchRequiredFromArray: in Block: [[self versionSpec loader: newLoader.... MetacelloPharoPlatform>>do:displaying: in Block: [:bar | ... BlockClosure>>cull: Job>>run in Block: [result := block cull: self] BlockClosure>>on:do: Job>>run in Block: [self prepareForRunning.... BlockClosure>>ensure: Job>>run NonInteractiveUIManager(UIManager)>>displayProgress:from:to:during: ByteString(String)>>displayProgressFrom:to:during: [0m[31mGot startup errors: [0m[31m MetacelloProjectSpecLoadError: No version found for '#stable' of ConfigurationOfNewDebugger [0mBuild step 'Execute shell' marked build as failure Archiving artifacts Recording test results

12 years

News from your work

by Guillaume Larcheveque

Hello Jan, We are really interested about your project on Island Grammar. I know that Stephane has some money to invite you to present your work and exchange about that. We would really like to hear and learn from you. Thanks in advance -- *Guillaume Larcheveque*

12 years

Issue 945 in moose-technology: Truncating right yAxis labels in EyeSee

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 945 by cunningh...(a)gmail.com: Truncating right yAxis labels in EyeSee http://code.google.com/p/moose-technology/issues/detail?id=945 Charts made look fine in the browser, but if you export to PNG (or other formats), any labels axis values on a right axis will be truncated. It should instead keep all drawing within the bounds of the canvas being drawn on - I believe EyeSee is drawing outside of its bounds (allowed in Pharo, interstingly, so you don't see the effects except when exporting). to reproduce: values := #( 1 5 10 40 70 100). chart := ESDiagramRenderer new. (chart verticalBarDiagram) rightYAxis; y: #value; yAxisLabel: 'Right Label'; regularAxis; preferredAxisMaxY: 111; models: values; yourself. chart open then export to PNG (or GIF). Look at that PNG, and you'll see the issue. Please fill in the labels with the following information: * Type-Defect * Component-EyeSee -- 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

12 years

Dictionary class>>keys:values:

by Ben Coman

12 years

Equivalence relation on FAMIX entities

by Serge Stinckwich

Hi all, I want to implement equivalence relation on FAMIX entities. For example, methods m1, m2 are equivalent if they have the same name, same signature and their classes have the same name. Any idea to introduce these relations in a customizable way in FAMIX ? I guess I have to introduce a new meta-model in the FAMIX family ? Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

12 years

Re: [Pharo-dev] Modification on CollectionsExtensions

by Guillaume Larcheveque

Ok so if everyone agree I will remove the flatCollect: method from CollectionExtensions since Sebastian made the correction in Pharo 3.0. 2013/6/12 Stéphane Ducasse <stephane.ducasse(a)inria.fr> > > On Jun 12, 2013, at 1:02 PM, Sebastian Tleye <stleye(a)gmail.com> wrote: > > ok, i understood, > > Discussing with Marcus we believe that it would be better to keep > Collecition>>gather: and add Collection>>flatCollect: (with the same > implementation) and put a comment in gather: saying that is kept for > compatibility purposes. > > flatCollect: will be included in Pharo and will be removed from > CollectionExtensions. > > > + 1 > > >> -- *Guillaume Larcheveque*

12 years

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

by admin＠moosetechnology.org

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

12 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev