- Moose-dev - INF Mailman

by Stéphane Ducasse

Hi guys I do not like the configurationOfXMLSupport because it introduces references to project using XML and I think that it makes little sense and leads to more complex configuration. I ported XMLWriter to SmalltalkHub and now I'm considering creating XMLParser with the parsing aspects of XMLSupport. I do not want to manage SIXX, Pastell: they should have their own projects and configurations! I could create a project, configuration… for Pastell for example. Do you know know what Moose really needs? Stef

12 years, 4 months

3
2
0 0

these projs are still residing in SS

by Usman Bhatti

Stef, These are the moose-related projects that are still hosted on SS, so if you can move these to SThub it will be great. These are not part of core-default baseline but still these are loaded in the current version of Moose. http://www.squeaksource.com/dsm http://www.squeaksource.com/SmallDude http://www.squeaksource.com/Kumpel http://www.squeaksource.com/Metanool tx, Usman

12 years, 4 months

1
0
0 0

Fwd: [Pharo-users] [JOB][Research] 16 month Postdoc "Architectural Design Exploration"

by Tudor Girba

---------- Forwarded message ---------- From: Marcus Denker <marcus.denker(a)inria.fr> Date: Mon, Feb 25, 2013 at 10:41 AM Subject: [Pharo-users] [JOB][Research] 16 month Postdoc "Architectural Design Exploration" To: "Pharo-project(a)lists.gforge.inria.fr Development" < Pharo-project(a)lists.gforge.inria.fr>, A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr> Cc: The general-purpose Squeak developers list < squeak-dev(a)lists.squeakfoundation.org> Architectural Design Exploration ================================ About Inria and the job ----------------------- Inria, with its academic, institutional and industrial partners, is commited to major research and innovation projects in the field of computational sciences. The institute disseminates across France thanks to its eight research centres. The Inria Lille - Nord Europe research centre, inaugurated in 2008, employs 357 people, including 250 scientists, in its seventeen research teams. Recognised for its significant contribution to the social and economic development of the Nord - Pas-de-Calais region, the Inria Lille - Nord Europe research centre promotes a policy of close cooperation with major businesses and small enterprises. By encouraging synergies between researchers and industrial partners, Inria contributes to the transfer of skills and expertise in computational technologies and provides access to top-level European and international research in order to support innovation and businesses, particularly in the region of Lille. Whether designing innovative software for business or logistics, modelling living cells or fusion plasma, or developing medical simulators or interfaces to facilitate human-computer interaction, our research opens up new possibilities that can revolutionise common practice and contribute to a better understanding of the natural phenomena which surround us. The postdoc is hosted by Team-Project RMoD. The goal of RMoD is to support remodularization of object-oriented applications. This objective is tackled from two complementary perspectives: reengineering and modularity constructs for programming languages. In the reengineering perspective we will propose new analyses to understand and restructure existing large applications (specialized package metrics, adapted visualizations, layer identification) on top of Moose [Duca08a], [Bhat12b]. http://rmod.lille.inria.fr/web/ Mission -------- Changes in the architecture may occur during the entire lifecycle of a system. Some of them might only affect local parts of a system, while others have more systemic impact. In general, we distinguish three types of approaches for handling change systematically, listed in an order of increasing severity: - Refactoring. They correspond to improvements and concern only certain components and connectors. They do not alter the offered functionality of the system. - Renovating. Sometimes, parts of the architecture are in such a bad condition that refactoring cannot work anymore. In such contexts, renovating the architecture – by restoring its fundamental principles or refreshing essential components – may be the better choice. Renovating also deals with only parts of the system. - Re-architecting. When an architecture is subject to significant changes, refactoring or renovating may not suffice. This might be the case if for example the technology platform is to be replaced by a new one, if there is a large change in business scope, or if the architecture is in such a bad shape that errors keep emerging. In such cases, re-architecting is required. The re-architecting process usually analyzes the existing architecture (e.g., using a SWOT analysis) and results in a new architecture by: a) reusing those components worthwhile to keep, b) modifying some of the existing components (refactoring) and c) re-building the rest of the components (renovating).[Ieee13] Because software engineers do not have a full understanding of the complete source code, each kind of changes may solve some problems (e.g. reduce some cycle between package), while creating new problems (e.g. creating new cycles). In this situation it would be profitable to have a tool that allows to test a possible new configuration (refactored, renovated or re-architectured) of the source code to see if the abstract property one wishes to improve, first actually improved, and second, did not improve at the expense of another equally important one. For this several alternatives new configurations have to be considered. In the RMoD team, we developed Orion [Lava10b], a tool that uses models as abstract representations of the program and enables the definition of several possible alternative versions of this program. Each version differentiates from the others by a set of refactoring operations. Currently, once an adequate version is selected, the user has to manually perform the operations on the code. Job offer description ---------------------- In this postdoc, we would like to enhance Orion in order to automatically generate code or modify the existing one once a version is chosen. Thus, it would be possible to study various alternatives of possible refactoring or restructuring of an existing program, using metrics [Abde12a], [Mord12b] or some other means [Hema12] to check the improvement in the "quality" of the code, and then ask the tool to perform the changes of the selected final solution onto the source code. The used metamodel enables a representation where code details are abstracted. A new metamodel for example AST metamodel, representing code will be introduced and the links between the two models will have to be maintained. Skills and profile -------------------- The candidate should : - hold a PhD degree in Computer Science - be fluent in English (French is an advantage but not required) - be knowledgeable in the domains of Software Engineering, maintenance, code analysis - have good programming skills in Smalltalk or be able to acquire them in a short amount of time Benefits --------- - Possibility of French courses - Help for housing - Participation for transportation - Scientific Resident card and help for husband/wife visa Additional information ----------------------- - Duration : 16 months - Salary: 2 620,84 € gross/month - Monthly salary after taxes : around 2 138€ (medical insurance included). - Before applying, please contact the scientist advisor: nicolas.anquetil(a)inria.fr - For the first selections, please apply before March 2013, 22nd Security and defense procedure ------------------------------- In the interests of protecting its scientific and technological assets, Inria is a restricted-access establishment. Consequently, it follows special regulations for welcoming any person who wishes to work with the institute. The final acceptance of each candidate thus depends on applying this security and defense procedure. More information: http://rmod.lille.inria.fr/web/pier/blog/2013-02-22-2 -- www.tudorgirba.com "Every thing has its own flow"

12 years, 4 months

1
0
0 0

Carrack?

by Alexandre Bergel

Hi! What Carrack is about? I guess it is related to Moose, but http://www.squeaksource.com/Carrack.html does not say much... The abstract of Fabrizo says it is an inferencer for dependencies. Maybe a short explanation, and even better, a very short example in the squeaksource and the moose website would be great... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

12 years, 4 months

2
2
0 0

Moose loaded on Pharo 2.0

by Nicolas Anquetil

tests are red :-) (not that much because we only took Moose-Ttests*) 1005 run, 969 passes, 0 skipped, 1 expected failures, 13 failures, 22 errors, 0 unexpected passes nicolas -- Nicolas Anquetil -- RMod research team (Inria)

12 years, 4 months

1
0
0 0

glamour moved

by Usman Bhatti

I moved glamour to STHub - config updated to create a baseline for pharo1.4 pointing to STHub for as many packages as possible (roassal, Metacello, BDD is still in SS) - loaded the baseline in 1.4 pharo...all tests green... - created a baseline for pharo 2.0...loaded in 2.0 and ran tests, here are the results: 357 run, 246 passes, 0 skipped, 12 expected failures, 0 failures, 99 errors, 0 unexpected passes - I wanted to define #stable and #development but since these are already defined with specific version info, I didn't modify these. Doru, can you have look for the definition of symbolic versions?

12 years, 4 months

1
0
0 0

glamour in the course of being migrated

by Tudor Girba

Hi, I started to migrate Glamour to SmalltalkHub. Cheers, Doru -- www.tudorgirba.com "Some battles are better lost than fought."

12 years, 4 months

4
19
0 0

Jenkins build became unstable: moose-latest-dev #1287

by address not configured yet

See <http://localhost:8020/job/moose-latest-dev/1287/>

12 years, 4 months

2
2
0 0

Fwd: [Pharo-project] Time Series in Smalltalk

by stephane ducasse

I thought that we had something like that in Moose. Begin forwarded message: > From: Serge Stinckwich <serge.stinckwich(a)gmail.com> > Subject: [Pharo-project] Time Series in Smalltalk > Date: February 20, 2013 10:28:10 PM GMT+01:00 > To: Pharo Development <pharo-project(a)lists.gforge.inria.fr> > Reply-To: Pharo-project(a)lists.gforge.inria.fr > > Hi all, > > I'm looking for a time series library available in Smalltalk. > Something like Python Time Series Analysis : http://pytseries.sourceforge.net/ > or > Pandas: http://pandas.pydata.org/ > > Thank you. > Regards, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ >

12 years, 4 months

1
0
0 0

config of moose on SThub

by Usman Bhatti

I sent this mail yesterday but strangely no received it, so here it is again. With Nicolas, we have created a first baseline of Moose based on the projects in STHub. The baseline baseline47STHub: corresponds to the old core-default baseline. Loading the baseline on 1.4 works fine, here are the test results: 998 run, 991 passes, 1 expected failures, 6 failures, 0 errors, 0 unexpected passes For each proj moved to SThub, we have tried to define two symbolic versions: #stable: a specific version of a proj at the time of move to STHub #bleedingEdge: load the latest packages of a proj.

12 years, 4 months

4
8
0 0

when do we release 4.8?

by Stéphane Ducasse

Hi doru What is blocking the release of 4.8? Because it would be good to release Moose 4.8 as the version before migrating to STHUB then we can work on having a version running on Pharo 2.0. Stef

12 years, 4 months

5
7
0 0

Build failed in Jenkins: moose-latest-dev #1284

by address not configured yet

See <http://localhost:8020/job/moose-latest-dev/1284/> ------------------------------------------ Started by timer Building in workspace <http://localhost:8020/job/moose-latest-dev/ws/> [workspace] $ /bin/sh -xe /tmp/hudson141875937493458092.sh + rm -rf <http://localhost:8020/job/moose-latest-dev/ws/moose> <http://localhost:8020/job/moose-latest-dev/ws/moose-tests> + /srv/ci.moosetechnology.org/builder/build.sh -i Pharo-1.4 -s monticello-fix-for-14 -s moose -s glamorous-theme -s moose-clean -s glamorous-toolkit -s cleanupforrelease -o moose [31m[33m =============================================================================== Notice: Errors in script loaded from <http://localhost:8020/job/moose-latest-dev/1284/artifact/moose/moose.st> =============================================================================== [0m[0m[31m==== Startup Error: GoferRepositoryError: Could not access http://www.squeaksource.com/glamoroust: ConnectionTimedOut: Cannot connect to 130.92.64.38:80 [0mMCHttpRepository(MCFileBasedRepository)>>goferReferences in Block: [:error | ^ GoferRepositoryError signal: error mes...etc... BlockClosure>>cull: MethodContext(ContextPart)>>handleSignal: in Block: [(self tempAt: 2)... BlockClosure>>ensure: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: [0m[31mGot startup errors: [0m[31m GoferRepositoryError: Could not access http://www.squeaksource.com/glamoroust: ConnectionTimedOut: Cannot connect to 130.92.64.38:80 [0m blockNoContextSwitchOffset != null 9102 + /srv/ci.moosetechnology.org/builder/build.sh -i moose -s patch-inputsensor -s testrunner -s moose-tests -o moose-tests [31m[33m =============================================================================== Notice: Errors in script loaded from <http://localhost:8020/job/moose-latest-dev/ws/moose-tests/moose-tests.st> =============================================================================== [0m[0m[31m==== Startup Error: MessageNotUnderstood: receiver of "new" is nil [0mUndefinedObject(Object)>>doesNotUnderstand: #new UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: Compiler class>>evaluate:for:notifying:logged: Compiler class>>evaluate:for:logged: Compiler class>>evaluate:logged: FileSystemFileStream(PositionableStream)>>fileInAnnouncing: in Block: [| chunk | val := (self peekFor: $!)... BlockClosure>>on:do: FileSystemFileStream(PositionableStream)>>fileInAnnouncing: in Block: [:bar | ... NonInteractiveUIManager(CommandLineUIManager)>>progressInitiationExceptionDefaultAction: [0m[31mGot startup errors: [0m[31m MessageNotUnderstood: receiver of "new" is nil [0m blockNoContextSwitchOffset != null 9102 + /srv/ci.moosetechnology.org/builder/build-oneclick.sh -i moose -o moose_suite-4_7_dev -n Moose -t 'Moose Suite 4.7 Development ' -v 4.7 -c Moose cp: cannot stat `/srv/ci.moosetechnology.org/builder/oneclick-icons/Moose.png': No such file or directory cp: cannot stat `/srv/ci.moosetechnology.org/builder/oneclick-icons/Moose.ico': No such file or directory cp: cannot stat `/srv/ci.moosetechnology.org/builder/oneclick-icons/Moose.icns': No such file or directory /srv/ci.moosetechnology.org/builder/build-oneclick.sh: line 170: zip: command not found Recording test results No test report files were found. Configuration error? Build step 'Publish JUnit test result report' changed build result to FAILURE Archiving artifacts

12 years, 4 months

1
1
0 0

moved Moose-Algos

by Usman Bhatti

Moose-Algos is moved to SThub. Created a new baseline that loads from SThub. Create a bleedingEdge symbolic version that loads the latest dev Created a version in #stable for both 1.4 and pharo 2.0. For pharo1.4-> All tests green For pharo 2.0- > All tests green

12 years, 4 months

2
1
0 0

Filtering elements to import from MSE files?

by Hani Abdeen

Hi, I'm wondering if it's possible to configure the MSE importer of Moose to import elements that satisfy some conditions (e.g., [ :element | element isFamixPackage ]). In fact, I need to import only packages/namespaces and their classes from MSE files. Why? because I want to load many many moose models (software versions) in one image and I'm interested in few information within those models (e.g., packages and their classes --without methods, attributes, references, invocations, etc.). By reading FMMSEParser and FMParseClientFilter, I found that we may set a filter that specify the name of elements to import. Yet I'm not sure about this. However, I did not find any api that we may use to set a filter that specify the type of elements to import. Is there a such api? if no, is it "possible" to implement it? any suggestions? It would be great if we can set a block filter: e.g., [ :element | element isFamixScopingEntity and: [ element isStub not ] ] Cheers, Hani

12 years, 4 months

3
5
0 0

Moving XMLSupport to Smalltalk

by Usman Bhatti

Hello, We are moving Moose to SmalltalkHub and once the projects in Moose moved and tested, we will port Moose to Pharo 2.0. Stef has volunteered to move XMLSupport to SThub and update configs for both Pharo 1.4 and Pharo 2.0. What do you think because it is important to have XMLSupport on a reliable repo. Usman

12 years, 4 months

1
0
0 0

stuck in Glamour-Merlin flow and update doesn't help

by Usman Bhatti

Scenario : I have an EyeSee chart that is updated from user input. Problem: The EyeSee chart does not update. There are two methods (AFAIK) to update glamour browser pane and its contents: explicitly send update message to the pane or new transmission to the port of the pane to be updated. Now, the first method does not work for EyeSee (may be a bug, i suggested a fix yesterday). The second method requires that transmissions are triggered but since Merlin is outside Glamour, I have to fake a transmission on a dummy port (I tried that but when I execute my browser, the dummy port is nil). I spent several hours looking into ports and their transmissions but couldn't obtain a workable solution for my problem. Here is a mock executable code to see what I am trying to achieve. | browser aModel myColor| browser := GLMDashboard new. browser title: 'Customizable EyeSee Chart Example'. browser addPaneNamed: #chart1 extent: 600@600. myColor := Color green. browser transmit to: #chart1; andShow: [ :a | a eyesee title: 'Sample bar chart'; diagram: [:renderer :x | (renderer kiviat) borderWidth: 1; radius: 150; models: {#(8 10 1). #(7 2 10). #(3 10 8)}; metrics: {#first. #second. #last. [ :each | each first + 2]}; maxs: {[ :model | 10]. [ :model | 10]. [ :model | 10]. [ :model | 10].}; mins: {[ :model | 1]. [ :model | 1]. [ :model | 1]. [ :model | 1]}; roundedBorder: true; backgroundColor: myColor; displayLegend: true; kiviatBackground: true; useColors: ESAbstractDiagram strongColorsTransparent]; act: [ | wizardControl wizardPane1 dropListPart| wizardControl := WizardControl new. wizardControl renderer: MerlinMorphicWizardRenderer new. wizardPane1 := WizardSinglePane new. dropListPart := DropListPart new list: #(red black green); yourself. wizardPane1 row: dropListPart associatedTo: #color. wizardControl addPane: wizardPane1. wizardControl atEndDo: [ :aDictionaryOfOutputs | myColor := aDictionaryOfOutputs at: #color. (browser paneNamed: #chart1) update ]. wizardControl open. ] entitled: 'Parameterize Color'. ]. browser openOn: #(1 2 3 4 5 6 7 8). "can't put color in the input model" Can you please have a look and see if I am missing something? regards, Usman

12 years, 4 months

1
1
0 0

Mondrian dependencies

by Usman Bhatti

Dependencies of Mondrian: Shout: 'http://www.squeaksource.com/MetacelloRepository' ProfStef: 'http://www.squeaksource.com/MetacelloRepository HealthReportProducer: 'http://www.squeaksource.com/HealthReportProducer' Nile-Base: http://www.squeaksource.com/Nile Which ones are exclusively used by Moose? Do we move them? CollectionExtensions: 'http://www.squeaksource.com/CollectionExtensions' This package seem to have moved from Moose repo to its own repo. I'll create a new project in STHub for it.

12 years, 4 months

3
3
0 0

flatCollect: in absence of Nile

by Stéphane Ducasse

http://code.google.com/p/pharo/issues/detail?id=7199

12 years, 4 months

1
0
0 0

Build failed in Jenkins: moose-latest-dev #1280

by address not configured yet

See <http://localhost:8020/job/moose-latest-dev/1280/> ------------------------------------------ [...truncated 717 lines...] BlockClosure>>on:do: [:bar | [workBlock value] on: HTTPProgress do: [:ex | (ex total ifNil: [true] ifNotNil: [ex amount == nil]) ifFalse: [(nextUpdateTime < Time millisecondClockValue or: [ex total = ex amount]) ifTrue: [bar value: ex amount asFloat / ex total asFloat. nextUpdateTime := Time millisecondClockValue + 100]]. ex resume]] in MCHttpRepository>>displayProgress:during: NonInteractiveUIManager(CommandLineUIManager)>>progressInitiationExceptionDefaultAction: ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during: ProgressInitiationException class>>display:at:from:to:during: NonInteractiveUIManager(CommandLineUIManager)>>displayProgress:from:to:during: MCHttpRepository>>displayProgress:during: MCHttpRepository>>readStreamForFileNamed:do: MCHttpRepository(MCFileBasedRepository)>>versionReaderForFileNamed:do: [self resizeCache: readerCache. super versionReaderForFileNamed: aString do: [:r | r ifNotNil: [readerCache at: aString put: r]]] in MCHttpRepository>>versionReaderForFileNamed: Dictionary>>at:ifAbsent: MCHttpRepository>>versionReaderForFileNamed: MCHttpRepository>>versionReaderForFileNamed:do: MCHttpRepository(MCFileBasedRepository)>>loadVersionFromFileNamed: MCHttpRepository(MCFileBasedRepository)>>goferVersionFrom: MetacelloCachingGoferResolvedReference(GoferResolvedReference)>>version MetacelloCachingGoferResolvedReference>>version [:each | each version] in [aCollection do: [:each | each version]. nearestReference version dependencies do: block. notDone := false] in MetacelloFetchingMCSpecLoader>>resolveDependencies:nearest:into: OrderedCollection>>do: [aCollection do: [:each | each version]. nearestReference version dependencies do: block. notDone := false] in MetacelloFetchingMCSpecLoader>>resolveDependencies:nearest:into: BlockClosure>>on:do: MetacelloFetchingMCSpecLoader>>resolveDependencies:nearest:into: [| references nearestReference cachedReference externalReference loadedVersionInfos mcVersion | self flag: #cleanup. cachedReference := self resolvePackageSpec: packageSpec cachedGofer: self loaderPolicy cacheGofer. (cachedReference ~~ nil and: [packageSpec getFile ~~ nil]) ifTrue: [cachedReference name = packageSpec file ifTrue: [^ self]]. references := self retryingResolvePackageSpecReferences: packageSpec gofer: gofer. nearestReference := references last asMetacelloCachingResolvedReference. (cachedReference ~~ nil and: [cachedReference name = nearestReference name]) ifTrue: [^ self]. (self ignoreImage not and: [(loadedVersionInfos := self ancestorsFor: packageSpec) ~~ nil]) ifTrue: [loadedVersionInfos do: [:info | info name = nearestReference name ifTrue: [^ self]. nil]]. externalReference := (references select: [:ref | ref name = nearestReference name]) first asMetacelloCachingResolvedReference. self repositoryMap at: externalReference name put: externalReference repository. (self resolveDependencies: externalReference nearest: nearestReference into: (OrderedCollection with: nearestReference)) do: [:reference | | pSpec l | mcVersion := reference version. (l := (GoferVersionReference name: reference name) resolveAllWith: self loaderPolicy cacheGofer) isEmpty ifTrue: [self cacheRepository storeVersion: mcVersion. reference == nearestReference ifTrue: [pSpec := packageSpec] ifFalse: [pSpec := packageSpec project packageSpec. pSpec name: mcVersion info]. self loadData addVersion: mcVersion versionInfo: mcVersion info resolvedReference: reference packageSpec: pSpec]]. self loaderPolicy resetCacheGofer. self preLoad: packageSpec. (MetacelloDirective loadPackage: packageSpec externalReference: externalReference loader: self) addTo: self loadDirective. self postLoad: packageSpec. Transcript cr; show: 'Fetched -> ' , externalReference name , ' --- ' , externalReference repository description , ' --- ' , nearestReference repository description] in MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer: [:bar | bar value: 1. aBlock value. bar value: 2] in MetacelloPharoPlatform>>do:displaying: NonInteractiveUIManager(CommandLineUIManager)>>progressInitiationExceptionDefaultAction: ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during: ProgressInitiationException class>>display:at:from:to:during: ByteString(String)>>displayProgressAt:from:to:during: MetacelloPharoPlatform>>do:displaying: MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer: MetacelloPackageSpec>>loadUsing:gofer: [:pkg | pkg loadUsing: self gofer: gofer] in MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories: OrderedCollection>>do: MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories: [super linearLoadPackageSpecs: packageSpecs repositories: repositories] in MetacelloFetchingMCSpecLoader>>atomicLoadPackageSpecs:repositories: BlockClosure>>ensure: MetacelloLoaderPolicy>>pushLoadDirective:during: MetacelloLoaderPolicy>>pushAtomicLoadDirectivesDuring:for: MetacelloFetchingMCSpecLoader>>atomicLoadPackageSpecs:repositories: MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>load MetacelloMCVersionSpecLoader>>load MetacelloMCVersion>>executeLoadFromArray: [:dict | ^ self executeLoadFromArray: anArray] in [self versionSpec loader: newLoader. MetacelloPlatform current useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray] defaultDictionary: Dictionary new] in [[self versionSpec loader: newLoader. MetacelloPlatform current useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray] defaultDictionary: Dictionary new] ensure: [self versionSpec loader: originalLoader]] in MetacelloMCVersion>>fetchRequiredFromArray: [^ aBlock value: dict] in MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: BlockClosure>>on:do: MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: [self versionSpec loader: newLoader. MetacelloPlatform current useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray] defaultDictionary: Dictionary new] in [[self versionSpec loader: newLoader. MetacelloPlatform current useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray] defaultDictionary: Dictionary new] ensure: [self versionSpec loader: originalLoader]] in MetacelloMCVersion>>fetchRequiredFromArray: BlockClosure>>ensure: [[self versionSpec loader: newLoader. MetacelloPlatform current useStackCacheDuring: [:dict | ^ self executeLoadFromArray: anArray] defaultDictionary: Dictionary new] ensure: [self versionSpec loader: originalLoader]] in MetacelloMCVersion>>fetchRequiredFromArray: [:bar | bar value: 1. aBlock value. bar value: 2] in MetacelloPharoPlatform>>do:displaying: NonInteractiveUIManager(CommandLineUIManager)>>progressInitiationExceptionDefaultAction: ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: -- and more not shown --------------------------------------------------------------------------------- THERE_BE_DRAGONS_HERE Got startup errors: ------------------------------------------------------------------------------- THERE_BE_DRAGONS_HERE PrimitiveFailed: primitive #primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex: in Socket failed ------------------------------------------------------------------------------- Build step 'Execute shell' marked build as failure Recording test results Archiving artifacts

12 years, 4 months

1
1
0 0

Customizable Eyesee chart example

by Usman Bhatti

Hello, I think it would be good to include this example in GlamourExamples. There are some more in MooseBrowsers implemented by André. | browser aModel| browser := GLMDashboard new. browser title: 'Customizable EyeSee Chart Example'. browser addPaneNamed: #firstInput; addPaneNamed: #chart1 extent: 300@300. browser transmit to: #firstInput; andShow: [ :a | a dropDownList title: 'Colors'; display: [ :model | model first ]; selectedIndex: 1 ]. browser transmit to: #chart1; fromOutsidePort: #entity; from: #firstInput; andShow: [ :a | a eyesee title: 'Sample bar chart'; diagram: [:renderer :model :color | renderer verticalBarDiagram y: #yourself; defaultColor: color; models: model second; width: 200; height: 150; baseAxisLine. renderer interaction popupText: #yourself ]]. aModel := Array with: {Color black. Color red. Color green} with: #(1 2 3 4 5 6 7 8). browser openOn: aModel.

12 years, 4 months

1
0
0 0

http://www.squeaksource.com/ShapeST80

by Usman Bhatti

I am moving EyeSee from squeaksource to SThub. EyeSee has a dependency on ShapeST80 (ss/ShapeST80). Should I move this project to Moose team or is this project used somewhere independent of EyeSee? usman

12 years, 4 months

3
2
0 0

SS/Moose -> St/Moose + St/MooseArchive

by Usman Bhatti

As the subject suggests, moose repo on squeaksource has been completely moved to SThub. Now, we distinguish two types of package in squeaksource/Moose: - the packages from the repo loaded by the current moose configuration are moved to Moose project on SThub. - the packages not loaded by the current moose config are moved to MooseArchive project on SThub (to be sure that we do not lose code). ConfigurationOfMoose cannot be updated and tested unless all peripheral tools (Mondrian/XMLSupport/etc.) are moved to SThub. So, we are first moving and updating leaves before updating and testing the config of trunk. So, now remaining projects (in the coreDefault: baseline of Moose): Mondrian, MooseAlgos, Glamour, PetitParser, XMLSupport. I've already downloaded all packages of Mondrian, tomorrow I'll push them and update the config. The ones that require more effort in terms of organization: Glamour and PetitParser. So, may be during of the next week we can start loading the first basic config of moose (after some cleanup: exclude DSM, Smalldude, Nile, etc.) loadable from STHub and it would be good to make it rapid otherwise, if someone needs to push some changes in moose and (s)he starts doing it on SS, it'll be a mess. usman

12 years, 4 months

1
0
0 0

EyeSee update - a fix

by Usman Bhatti

Currently, an EyeSee chart does not update itself when its pane is updated in Glamour. I think the problem comes from the fact that erroneously the presentation is assigned a new diagram block instead of a new renderer. This code fixes this problem. Can I integrate it in glamour? GLMMorphicEyeSeeRenderer >> actOnPresentationUpdate: ann "ann presentation diagram: ESDiagramRenderer new." ann presentation eyeseeRenderer: ESDiagramRenderer new. canvasScrollPane scroller removeMorph: canvasScrollPane scroller submorphs first. self eyeseeCanvasFor: ann presentation

12 years, 4 months

1
0
0 0

EyeSee + STShape80 now on SThub

by Usman Bhatti

- moved the code of the both to SThub - updated the config - tested in 1.4 (all tests green) - tested in 2.0 1. Apparently, BlockContext is removed in 2.0 so eyeSeeValue: cannot be loaded from EyeSee in 2.0. 2. All tests green except ESExamplesTest>>testSmoke Should I open bug entries for these? Usman

12 years, 4 months

1
0
0 0

doing Eyesee then Mondrian

by Usman Bhatti

12 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev