- Moose-dev - INF Mailman

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

by admin＠moosetechnology.org

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

12 years, 2 months

1
0
0 0

PetitDot

by Serge Stinckwich

Hi all, I started to work on a dot parser: http://smalltalkhub.com/#!/~SergeStinckwich/PetitDot The idea is to be able to import large graph and do some visualizations with Roassal. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

12 years, 2 months

2
1
0 0

We need you for an evaluation

by Stéphane Ducasse

Please distribute this mail around Hi all, We are conducting an academic research to improve tools for software integration. If you maintain a project with multiple contributors, we will greatly appreciate your participation. Your answers will be used for research purposes and to support the development of new tools. You can later access the results of this study, make free use of our tools to support the integration of changes, and maybe receive a gift. https://sondages.inria.fr/index.php/667625/lang-en Best regards, Martin Dias, Nicolas Anquetil, Veronica Isabel Uquillas, Stéphane Ducasse and the RMOD Inria team

12 years, 2 months

1
0
0 0

Fuel import/export in Moose

by Usman Bhatti

Hello, I've seen some discussion on the subject and I am interested in serializing my moose model with Fuel and load it back in my model. The idea is to be able to store user annotations on program entities in Moose across several models. Could someone comment on the state of the import/export of Fuel in Moose, are there any tests/documentation? tx, usman

12 years, 2 months

3
3
0 0

[ANN] Changes to PetitXPath

by Esteban Lorenzano

Hi, After more than two years (!), I made a small iteration on the PetitXPath parser. - I fixed the grammar to match more accurately to the specification (http://www.w3schools.com/xpath/xpath_syntax.asp) - I added a couple of more grammars (this is still incomplete, but now is a bit better) - I refactored a lot of stuff to extract functionality from XML documents and put it into an independent (and therefore, extensible) class (I was thinking on implementing something to introspect the pharo system, for example...). - I also renamed the entry method from the too generic "find::" to a more precise "findXPath:" - I create a "default" parser, a singleton who allows me to speed up my processes (my benchmarks gave me x12 speed up on querying documents by just not creating a parser each time) - I added class comments. Probably not the best in the world, but at least better than before. - finally, but not least, I added tests to validate the syntax still far from an ideal situation, but I think a lot better... now, the problem is: - it is not backward compatible, because I removed #find: method. I can put it back if required (but deprecated), but I'm not sure anyone is using it (in fact, I think no one is actually using it right now) - I need write access into the Moose team to commit my changes :) cheers, Esteban

12 years, 2 months

3
4
0 0

Moose-MondrianPaintings package

by Juraj Kubelka

Hi! There are a bunch of methods in package Moose-MondrianPaintings which I think does not relate to this package. Mainly methods of FAMIXClass. Is it right that method #abstractMethodsGroup is in this package? I am asking because I am moving/migrating these methods into package Moose-RoassalPaintings package. Thank you a lot. Jura

12 years, 2 months

1
0
0 0

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

by admin＠moosetechnology.org

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

12 years, 2 months

1
0
0 0

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

by admin＠moosetechnology.org

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

12 years, 2 months

1
0
0 0

Software Integration Survey

by Martin Dias

Hi all, We are conducting an academic research to improve tools for software integration. If you maintain a project with multiple contributors, we will greatly appreciate your participation. Your answers will be used for research purposes and to support the development of new tools. You can later access the results of this study, make free use of our tools to support the integration of changes, and maybe receive a gift. https://sondages.inria.fr/index.php/667625/lang-en Best regards, Martín Dias, Nicolas Anquetil, Verónica Isabel Uquillas, Stéphane Ducasse and the RMOD Inria team

12 years, 2 months

1
0
0 0

collection>>sum:

by Tudor Girba

Hi, Pharo 2.0 comes with Collection>>sum: Collection>>sum: aBlock "This is implemented using a variant of the normal inject:into: pattern. The reason for this is that it is not known whether we're in the normal number line, i.e. whether 0 is a good initial value for the sum. Consider a collection of measurement objects, 0 would be the unitless value and would not be appropriate to add with the unit-ed objects." | sum sample | sample := aBlock value: self anyOne. sum := self inject: sample into: [ :previousValue :each | previousValue + (aBlock value: each) ]. ^ sum - sample To some extent, this is more generic than the one we had in Moose that considered only numbers: Collection>>sum: aSymbolOrBlock ^ self inject: 0 into: [:sum :each | sum + (aSymbolOrBlock value: each)] However, with the Pharo 2.0 implementation the collection must not be empty, while the other implementation we get 0. If the collection is empty, you get an exception due to anyOne. This induced several errors in metric computations (like number of methods of a package when the package had no classes). These are now fixed, but I thought I would let you know just in case you want to rely on this method. I actually still believe we would benefit from a robust but more limited sum:. Perhaps we could have sumNumbers:. Cheers, Doru -- www.tudorgirba.com "If you can't say why something is relevant, it probably isn't."

12 years, 2 months

4
4
0 0

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

by admin＠moosetechnology.org

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

12 years, 2 months

3
27
0 0

Any wishes for Roassal?

by Alexandre Bergel

Hi! Roassal 2.0 is on the way. We would like to make sure everybody find this release attractive. We are wondering whether you have some particular requirements you would like us to address or some bugs you would like to see fixed. Feel free to speak up! Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

12 years, 2 months

4
5
0 0

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

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/301/> ------------------------------------------ [URLTrigger] A change within the response URL invocation (log) Building remotely on moose-slave 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/hudson7816025404390257859.sh + bash + wget --quiet -O - http://get.pharo.org/20+vmLatest Downloading the latest 20 Image: http://files.pharo.org/image/20/latest.zip image.0zs1F/Pharo-20599.image Downloading the latest pharoVM: http://files.pharo.org/vm/pharo/linux/pharo-linux-latest.zip pharo-vm/pharo Downloading PharoV10.sources: http://files.pharo.org/image//PharoV10.sources.zip Downloading PharoV20.sources: http://files.pharo.org/image//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 #development of ConfigurationOfMooseAlgos [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 #development of ConfigurationOfMooseAlgos [0mBuild step 'Execute shell' marked build as failure Archiving artifacts Recording test results

12 years, 2 months

1
0
0 0

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

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/299/> ------------------------------------------ Started by upstream project "roassal" build number 126 originally caused by: [URLTrigger] A change within the response URL invocation (log) Building remotely on moose-slave 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/hudson6602131191160343972.sh + bash + wget --quiet -O - http://get.pharo.org/20+vmLatest Downloading the latest 20 Image: http://files.pharo.org/image/20/latest.zip image.GjOb9/Pharo-20599.image Downloading the latest pharoVM: http://files.pharo.org/vm/pharo/linux/pharo-linux-latest.zip pharo-vm/pharo Downloading PharoV10.sources: http://files.pharo.org/image//PharoV10.sources.zip Downloading PharoV20.sources: http://files.pharo.org/image//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+ ./pharo moose-latest-dev-4.8.image mooseimagesetup + ./pharo moose-latest-dev-4.8.image moosetest --junit-xml-output [31m[33m =============================================================================== Notice: Running tests in 128 Packages =============================================================================== [0m[0m[31mError: index out of range [0mTabSelectorMorph(Object)>>error: TabSelectorMorph(Morph)>>privateAddAllMorphs:atIndex: TabSelectorMorph(Morph)>>addAllMorphs: TabSelectorMorph>>updateTabs TabSelectorMorph>>extent: TabSelectorMorph(Morph)>>bounds: TabSelectorMorph(Morph)>>layoutInBounds: TableLayout>>layoutLeftToRight:in: TableLayout>>layout:in: PanelMorph(Morph)>>doLayoutIn: PanelMorph(Morph)>>fullBounds in Block: [self doLayoutIn: self layoutBounds] BlockClosure>>on:do: PanelMorph(Morph)>>fullBounds LazyTabGroupMorph(Morph)>>submorphBounds in Block: [:m | | subBox | m visible... Array(SequenceableCollection)>>do: LazyTabGroupMorph(Morph)>>submorphBounds LazyTabGroupMorph(Morph)>>privateFullBounds LazyTabGroupMorph(Morph)>>doLayoutIn: LazyTabGroupMorph(Morph)>>fullBounds in Block: [self doLayoutIn: self layoutBounds] BlockClosure>>on:do: LazyTabGroupMorph(Morph)>>fullBounds PanelMorph(Morph)>>submorphBounds in Block: [:m | | subBox | m visible... Array(SequenceableCollection)>>do: PanelMorph(Morph)>>submorphBounds PanelMorph(Morph)>>privateFullBounds PanelMorph(Morph)>>doLayoutIn: PanelMorph(Morph)>>fullBounds in Block: [self doLayoutIn: self layoutBounds] BlockClosure>>on:do: PanelMorph(Morph)>>fullBounds PanelMorph(Morph)>>submorphBounds in Block: [:m | | subBox | m visible... [0mBuild step 'Execute shell' marked build as failure Archiving artifacts Recording test results ERROR: Failed to archive test reports hudson.util.IOException2: remote file operation failed: <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/> at hudson.remoting.Channel@4ce1e2b3:moose-slave at hudson.FilePath.act(FilePath.java:848) at hudson.FilePath.act(FilePath.java:825) at hudson.tasks.junit.JUnitParser.parse(JUnitParser.java:87) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:122) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:134) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:810) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:785) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:732) at hudson.model.Run.execute(Run.java:1568) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: hudson.util.IOException2: Failed to read <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/Glamour-Tests-Morphic…> at hudson.tasks.junit.TestResult.parse(TestResult.java:244) at hudson.tasks.junit.TestResult.parse(TestResult.java:163) at hudson.tasks.junit.TestResult.parse(TestResult.java:140) at hudson.tasks.junit.TestResult.<init>(TestResult.java:116) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:117) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:90) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2309) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) Caused by: org.dom4j.DocumentException: Error on line 85 of document file://<https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/Glamour-Tests-Morphic…> : XML document structures must start and end within the same entity. Nested exception: XML document structures must start and end within the same entity. at org.dom4j.io.SAXReader.read(SAXReader.java:482) at org.dom4j.io.SAXReader.read(SAXReader.java:264) at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:129) at hudson.tasks.junit.TestResult.parse(TestResult.java:227) ... 15 more Caused by: org.xml.sax.SAXParseException; systemId: file://<https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/Glamour-Tests-Morphic…;> lineNumber: 85; columnNumber: 1; XML document structures must start and end within the same entity. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:391) at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1404) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.endEntity(XMLDocumentFragmentScannerImpl.java:882) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.endEntity(XMLDocumentScannerImpl.java:582) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.endEntity(XMLEntityManager.java:1370) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(XMLEntityScanner.java:1740) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.skipChar(XMLEntityScanner.java:1393) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2769) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:625) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:488) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:819) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:748) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1208) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:525) at org.dom4j.io.SAXReader.read(SAXReader.java:465) ... 18 more

12 years, 2 months

1
0
0 0

Issue 922 in moose-technology: Update ConfigurationOfMoose to work with Roassal from STHub

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-MooseCore Milestone-4.8 New issue 922 by tu...(a)tudorgirba.com: Update ConfigurationOfMoose to work with Roassal from STHub http://code.google.com/p/moose-technology/issues/detail?id=922 Just what the title says -- 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, 2 months

1
1
0 0

Issue 927 in moose-technology: Rename the importers with Squeak in their names

by moose-technology＠googlecode.com

Status: New Owner: tu...(a)tudorgirba.com Labels: Type-Enhancement Priority-Medium Milestone-4.8 New issue 927 by tu...(a)tudorgirba.com: Rename the importers with Squeak in their names http://code.google.com/p/moose-technology/issues/detail?id=927 Just what the title says -- 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, 2 months

1
1
0 0

Roassal new algorithms

by mathieubmddehouck＠mailoo.org

Hi There are more than simply linear, quadratic and cubic Bezier curves. In fact, as you can have as many control points as you wish, you can have a Bezier curve of any order. But what I was calling RadialBezierCurve was a kind of strategy, I mean I have an abstract class which knows how to compute a curve, but I still have to choose my control points so I was thinking to create different subclasses whose role is to know what are their control points : - The radial one choose its control points within the same radius as its source and its target. I wanted to create an ortoVertical and an ortoHorizontal whose control points would have been computed differently, so that we could use Bezier curve for regular tree too. Regards Mathieu

12 years, 2 months

4
3
0 0

comments for java enum values

by Vaidotas Didžbalis

Hello, Thank you for Moose tool. It seems that comments for java enum values are not imported in 4.8 dev image. regards, Vaidotas

12 years, 2 months

1
0
0 0

#stable and Metacello (was Re: ConfigurationOfGlamourSeaside)

by Chris Cunningham

Interesting. Does Metacello allow us to associate #stable with a version of a platform (for instance, #stable for Moose 4.7)? Because #stable isn't always stable, as you have pointed out. On Wed, Apr 17, 2013 at 8:34 AM, Diego Lont <diego.lont(a)delware.nl> wrote: > Problem found, thanks to Doru. It was loading the stable version of > Glamour. That is apparently not stable in 4.8. It should load the > development version. I changed this, and now I can continue working once I > load GlamourSeaside. Running the tests failed 44 out of 66: When I browse > through them I saw two problems: it needed a HTTPRequest, that no longer > exists (problem in Seaside Tests), and I did not start the Parasol server. > So no surprises here yet. Maybe someone else can test if GlamourSeaside > loads good? > > Cheers, > Diego > > P.S. I now loaded my configuration using GTMetaceller. > > Thanks for doing this. > > I am not sure what you mean by becoming unstable. ConfigurationOfGlamour > #development is already loaded in the image. It should not cause any > further problems. > > What might happen is that ConfigurationOfGlamour loads Magritte which > loads Grease, and this might have an impact on Seaside. Maybe we are not > loading the proper versions. Could it be it? > > Cheers, > Doru > > > > > On Wed, Apr 17, 2013 at 4:01 PM, Diego Lont <diego.lont(a)delware.nl> wrote: > >> Hi all, >> >> Done some more testing and cleaned to configuration to follow standards. >> >> I have an additional note. Currently when I load the development version >> of ConfigurationOfGlamour into moose 4.8, my moose becomes unstable. I am >> not sure what is wrong here, but this makes it hard to test well. So I >> guess I am stuck untill Glamour is stable again in 4.8. >> >> Serge and Doru, >> >> Please let me know if some more work is needed on the >> ConfigurationOfGlamourSeaside. It should be fine now. >> >> Cheers, >> Diego >> >> > Hi all, >> > >> > I am not fully done testing, but so far looking good, so here I share >> how far I am: >> >> Version 0.4 is tested in Moose 4.8. I loaded it in Pharo 2.0 and got >> an error while loading Seaside Tests. Only the tests depend on this >> project, so this should be ok. Maybe the tests even run, when you proceed >> on the warning. >> >> Important note: the configuration of Seaside30 comes from Seaside30 >> repository instead of the MetacelloRepository on squeak source. So you need >> to load this configuration manually before loading GlamourSeaside. >> > >> > After manually loading configuration of GlamourSeaside and Seaside30 >> the following should load this project: >> > >> > (ConfigurationOfGlamourSeaside project version: '0.4') load: 'Examples' >> > After that you should of course start the server by: >> > ZnZincServerAdaptor startOn: 8080 >> > >> > Cheers >> > >> > >> > _______________________________________________ >> > Moose-dev mailing list >> > Moose-dev(a)iam.unibe.ch >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >

12 years, 2 months

4
7
0 0

Version 1.39 of Versionner

by Alexandre Bergel

Hi All, I have produced a new version of Versionner (how odd is that ? :-) What is new: - you can load a project from SmalltalkHub (cf screenshot) - some bugs have been fixed (e.g., browsing a version) - including some other fixes, from Norbert for example Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

12 years, 2 months

1
0
0 0

Metacello issue?

by Alexandre Bergel

Hi Dale, I am facing some problem with Metacello that really drive me crazy. Recently we have introduced a dependency to Athens in the baseline 0.6. This triggers some error that I do not understand. For example: Error: Error composing version '1.220': MessageNotUnderstood: SmallInteger>>add: { versionCompositionError } [ #validateProject: ] Error: Error composing version '1.239': MessageNotUnderstood: SmallInteger>>add: { versionCompositionError } [ #validateProject: ] Warning: Symbolic version #development refers to a version'0.6-baseline' whose blessing #baseline is not #development { notDevelopmentVersion } [ #validateVersionSpecForSymbolicVersion:symbolicVersion: ] I am thinking about removing the dependency of Athens because all the tooling we have to development is broken. Do you have any idea what is going on? You can reproduce the problem by doiting the following in a 2.0: -=-=-=-=-=-=-=-=-=-=-=-= Gofer new url: 'http://smalltalkhub.com/mc/ObjectProfile/Roassal/main' ; package: 'ConfigurationOfRoassal'; load. (MetacelloToolBox validateConfiguration: (Smalltalk at: #ConfigurationOfRoassal)) explore -=-=-=-=-=-=-=-=-=-=-=-= Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

12 years, 2 months

2
2
0 0

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

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/288/> ------------------------------------------ Started by upstream project "roassal" build number 116 originally caused by: [URLTrigger] A change within the response URL invocation (log) [URLTrigger] A change within the response URL invocation (log) [URLTrigger] A change within the response URL invocation (log) Building remotely on moose-slave 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/hudson6898755218833735760.sh + bash + wget --quiet -O - http://get.pharo.org/20+vmLatest Downloading the latest 20 Image: http://files.pharo.org/image/20/latest.zip [image.X8lMJ/image.zip] End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in one of image.X8lMJ/image.zip or image.X8lMJ/image.zip.zip, and cannot find image.X8lMJ/image.zip.ZIP, period. Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results

12 years, 2 months

1
0
0 0

Options for Visualization

by Damir Majer

Hi, I´m searching for Options to visualize diagrams, for example an class-diagram. Is there an graphViz-Implementation in Pharo or better other Options to display Diagrams? (here is the graphViz-Dot-Example: graph ethane { Car -- tire1 [type=s]; Car -- tire2 [type=s]; Car -- tire3 [type=s]; Car -- tire4 [type=s]; } Thanks for routing me in the right direction! Cheers, Damir ----- -- Damir Majer ... be agile: www.majcon.de -- View this message in context: http://forum.world.st/Options-for-Visualization-tp4682144.html Sent from the Moose mailing list archive at Nabble.com.

12 years, 2 months

5
6
0 0

Re: [Seaside-dev] ConfigurationOfSeaside30

by Dale Henrichs

Johan, I think that OneClick was put where it was because it is in the #squeakPlatform block, not the #common block ... there is no OneClick for GemStone ... IIRC, the original OneClick group was created because I noticed that the OneClick images were built with different contents than the 'default' group, so I created the separate group .. Dale ----- Original Message ----- | From: "Johan Brichau" <johan(a)inceptive.be> | To: "Seaside - developer list" <seaside-dev(a)lists.squeakfoundation.org> | Cc: "Moose-related development" <moose-dev(a)iam.unibe.ch> | Sent: Tuesday, April 16, 2013 1:24:30 AM | Subject: Re: [Seaside-dev] ConfigurationOfSeaside30 | | I adapted that group, which was indeed forgotten (why was it written at the | bottom and the other groups at the top?) | | I'm testing... | | On 16 Apr 2013, at 09:56, Diego Lont <diego.lont(a)delware.nl> wrote: | | > Hi all, Hi Johan, | > | > I tried loading the seaside30 version 3.0.8 into moose 4.8 by using: | > (ConfigurationOfSeaside30 project version: '3.0.8') load: 'OneClick'. | > This resulted in a failure, since there was still some dependency on OB, | > and this could not be resolved, since OB is removed in Pharo 2.0 for the | > time being. | > | > I fixed this by moving 'Seaside-Tools-OmniBrowser' in group 'OneClick' from | > squeakcommon to squeak + pharo 1.x. And since this package is too big for | > the list, anyone who wants it can mail me. | > | > On squeaksource I am called del, so if someone could add me here, I will | > commit this version to the Seaside30 repository. | > | > Cheers, | > Diego_______________________________________________ | > seaside-dev mailing list | > seaside-dev(a)lists.squeakfoundation.org | > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev | | _______________________________________________ | seaside-dev mailing list | seaside-dev(a)lists.squeakfoundation.org | http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |

12 years, 2 months

1
0
0 0

ideas for a new Famix

by Nicolas Anquetil

Hi guys, Food for thoughts. It's a long one, but it is literally the result of years of thinking and discussing Famix in our group. This is still work in progress so that those who might want to participate have a chance to do it before everything is already decided. You can call it a vision for the next Famix (and Fame incidentally) Although the goal of Famix is to be able to model systems in any language, the reality of it is that it focuses very much on OO, and more precisely on ST and Java. And even with only these two languages, it is already difficult. Famix is the union of ST + Java which means unneeded complexity when you deal with only one of the two. Same happen when considering something outside the current scope. For example something as a C function calling another C function is currently represented as an invocation, which means it has a receiver (the object on which a message is sent, useless in C) and also a collection of candidates (whereas in C function names must be unique). When working with different languages, mostly not OO, it started to annoy me, and I wanted to see how we could redesign a new Famix so that: - we have a bare core metamodel that is really language independent - something that is easily extensible so that one does not have to redefine basic stuff (what is a variable, a class, a method) - no "hidden" associations as the declaredType of a FamixStructuralEntity - it is completely model driven, which means we can regenerate all the code in Smalltalk, Java and other languages from the metamodel. Having Fame (and thus Famix) in Java helped a lot when I did VerveineJ. I can imagine having a C implementation of Fame could be nice to reuse old parsers based on Bison+Flex :-) I had two other requirements steming from the way I see metamodels: primarily as conceptual representations of some domain. They should be as clear as possible about what is meant by the concepts and their relationships, and also it should be as close as possible from the human conception of the domain. This implies: - I want it to be typed. C and Java have types to guard the developer from making mistakes, I want types to clarify the meaning of the concepts, like defining an ontology - I want it to have multiple inheritance, with as little restrictions as possible (typical multiple inheritance problems in programming languages) to try to be closer from the abstract conception of the domain. In short, we are looking for the Graal, nothing new here :-) Now the question is how far we can push it and how close can we get? Discussing we had the idea of a GenericEntity, probably equivalent to the current FamixSourcedEntity. We could have generic FunctionEntity, VariableEntity, ClassEntity inheriting from GenericEntity; MethodEntity inheriting from FunctionEntity. And all these only stating consensual things like a class defines methods, a function defines variables. Independent of that (meant to be used through multiple inheritance) we would have the idea that there are ContainerEntity, BehavioredEntity, TypedEntity, maybe even NamedEntity. So that FunctionEntity (which is a GenericEntity) would also be a BehavioredEntity + a NamedEntity. Invocation would occur between two BehavioredEntity And we could create new entities by combining all these things. For example, a JavaMethodEntity would inherit from MethodEntity + TypedEntity + ContainerEntity (may define classes) A PascalProgram could be a GenericEntity+ContainerEntity (contains functions)+BehavioredEntity All this would be declarative in the new Famix and translated in some way by Fame into different languages (lets concentrate on Pharo and Java for now). In a first step, behaviour to be reused (like navigation between a ContainerEntity and its members) could be stored directly in the metamodel for each target language and then copied appropriately when generating actual code. In a second step I also dream of using FAST (AST metamodeling, see http://youtu.be/dRr3WHOD3x4) to model the behaviour abstractly and then generate the code from that. I believe this would introduce only two real changes to Moose: First Fame would have to allow for multiple inheritance, second MooseChef would have to be re-designed to allow for new queries (at least ContainerEntity, BehavioredEntity). And of course, we would need to using it concretely to see whether it really helps considering new languages So this is about it. If you have any idea or comment on this, we will be glad to here from you. If you want to participate, we will be even gladder because we are not that many and it is a lot of work. nicolas -- Nicolas Anquetil -- RMod research team (Inria)

12 years, 2 months

5
19
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev