Moose-dev August 2013

moose-dev@list.inf.unibe.ch

26 participants
167 discussions

Issue 888 in moose-technology: MondrianViewBuilder should support a better zOrder
by moose-technology＠googlecode.com 13 Aug '13

13 Aug '13

Status: New Owner: ---- CC: alexandr...(a)gmail.com Labels: Type-Enhancement Priority-Medium Component-Roassal New issue 888 by tu...(a)tudorgirba.com: MondrianViewBuilder should support a better zOrder http://code.google.com/p/moose-technology/issues/detail?id=888 Here is a little example: view shape label text: #yourself. view nodes: (1 to: 20). view edges: (1 to: 20) from: [:x | x // 2] to: 1. view edges: (1 to: 20) from: [:x | x // 3] to: 2. view edges: (1 to: 20) from: [:x | x // 5] to: #yourself. view edges: (1 to: 20) from: [:x | x // 7] to: #yourself. view dominanceTreeLayout Open this one is Mondrian and then in the Roassal Easel. Then, try to select 1. In Roassal, you cannot select 1 because of the edges that go on top of it. What is more, you also can barely see it. This situation will always appear in graphs with edges that cross the nodes. Given that at least the MondrianViewBuilder should be about mapping domain models onto graphs, having a sensible zOrder, at least in the MondrianViewBuilder is important.

3 27

Build failed in Jenkins: moose-latest-dev-4.8 #865
by admin＠moosetechnology.org 12 Aug '13

12 Aug '13

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/865/> ------------------------------------------ Started by upstream project "roassal" build number 383 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/hudson1290826081779860701.sh + wget --quiet -O - http://get.pharo.org/20+vmLatest + bash 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/latest.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 + ./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: Error: Could not load Mondrian-ShapeVisitor-TudorGirba.6.mcz: ConnectionTimedOut: Data receive timed out. [0mMCHttpRepository(Object)>>error: MCHttpRepository>>readStreamForFileNamed:do: in Block: [:exception | self error: 'Could not load ' , aStr...etc... BlockClosure>>cull: MethodContext(ContextPart)>>handleSignal: in Block: [self exceptionHandlerBlock cull: exception] BlockClosure>>ensure: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: ConnectionTimedOut(Exception)>>pass ZnClient>>executeWithRetriesRemaining: in Block: [:exception | retryCount > 0... BlockClosure>>cull: MethodContext(ContextPart)>>handleSignal: in Block: [self exceptionHandlerBlock cull: exception] BlockClosure>>ensure: MethodContext(ContextPart)>>handleSignal: ConnectionTimedOut(Exception)>>signal ConnectionTimedOut(Exception)>>signal: ConnectionTimedOut class(Exception class)>>signal: Socket>>waitForDataFor: in Block: [ConnectionTimedOut signal: 'Data receive timed ou...etc... Socket>>waitForDataFor:ifClosed:ifTimedOut: Socket>>waitForDataFor: Socket>>receiveDataSignallingTimeout:into:startingAt: SocketStream>>receiveData SocketStream>>next ZnLineReader>>processNext ZnLineReader>>nextLine ZnStatusLine>>readFrom: ZnStatusLine class>>readFrom: ZnResponse>>readHeaderFrom: ZnResponse(ZnMessage)>>readFrom: ZnResponse class(ZnMessage class)>>readFrom: [0m[31mGot startup errors: [0m[31m Error: Could not load Mondrian-ShapeVisitor-TudorGirba.6.mcz: ConnectionTimedOut: Data receive timed out. [0mBuild step 'Execute shell' marked build as failure Archiving artifacts Recording test results

1 0

Issue 964 in moose-technology: <Initializer> methods created as stub
by moose-technology＠googlecode.com 12 Aug '13

12 Aug '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-VerveineJ New issue 964 by anquetil...(a)gmail.com: <Initializer> methods created as stub http://code.google.com/p/moose-technology/issues/detail?id=964 When an attribute is initialized at declaration, the initialization code goes in a <Initializer> method. This one should not be a stub but it is -- 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

1 1

what makes moose
by Tudor Girba 12 Aug '13

12 Aug '13

Hi Stef, On Sun, Aug 11, 2013 at 3:19 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr > wrote: > ... > To me I think that it would be good to have a Moosedev and a > MooseDeployment part because we have many differnt frameworks in the system > This is certainly an important topic and it warrants its own discussion. I think we should not distinguish between MooseDev and MooseDeployment :). My vision goes like this: - Moose is a platform that works for multiple technologies. Perhaps we can distinguish between what makes sense for Java or for a language like C#, but the differences would be small and would not warrant different distributions. - Moose is a platform for Pharo as well, although not many are seeing it like that. This means that the tools we have with Moose should be used for analyzing Pharo. - We could distinguish between a Pharo only distribution and the distribution for all other languages. Actually, this is what we have with the GToolkit project: a Pharo specific toolset. However, we still want to have the Pharo-specific tools inside a Java-specific distribution given that we want people to develop their own tools fast. And to debug them. And to inspect them. So we want all the Pharo specific tools in the large distribution, too. All in all, we now go towards: - GToolkit for everyone that wants to develop in Pharo only. - Moose for every other language (and it includes GToolkit). Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

2 5

Jenkins build became unstable: moose-latest-dev-4.8 #860
by admin＠moosetechnology.org 12 Aug '13

12 Aug '13

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

1 0

another one but that one I do not understand it :)
by Stéphane Ducasse 11 Aug '13

11 Aug '13

ACD-Model depends on MessageSendDebugAction ??? may be this one is the fix package: 'ACD-Model' with: [spec requires: #('NewDebugger-Core' 'DebuggerActions)]; in AnnouncerCentricDebugger To me I think that it would be good to have a Moosedev and a MooseDeployment part because we have many differnt frameworks in the system Stef

2 10

MooseImage
by Tudor Girba 11 Aug '13

11 Aug '13

Hi, MooseImage is a new class that is meant to store meta-information about the origin of the current image. Right now, this populated by the Jenkins build job. You can simply print the result of "MooseImage current" to find the information For example, you can get: Moose https://ci.inria.fr/moose/job/moose-latest-dev-4.8/855/ 11 August 2013 3:23:43 pm >From now on, we can identify our images better. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

2 1

Issue 963 in moose-technology: Jenkins should stamp a build number in the Moose image
by moose-technology＠googlecode.com 11 Aug '13

11 Aug '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Maintainability New issue 963 by tu...(a)tudorgirba.com: Jenkins should stamp a build number in the Moose image http://code.google.com/p/moose-technology/issues/detail?id=963 The best way to do this would be to extend the MooseImageSetupCommandLineHandler to support a build number parameter. -- 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

1 2

Jenkins build is back to normal : moose-latest-dev-4.8 #855
by admin＠moosetechnology.org 11 Aug '13

11 Aug '13

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

1 0

MooseCycleTable depends on DSMFamixCell
by Stéphane Ducasse 11 Aug '13

11 Aug '13

package: 'Moose-CycleTable' with: [spec requires: 'Moose-Dsm-Core']; => package: 'Moose-CycleTable' with: [spec requires: #('Moose-Dsm-Core' 'Moose-Dsm-Famix')]; or package: 'Moose-CycleTable' with: [spec requires: #('Moose-Dsm-Famix')]; because Moose-Dsm-Famix depends on Dsm-core

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev August 2013