Issue 888 in moose-technology: MondrianViewBuilder should support a better zOrder
by moose-technology@googlecode.com
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.
9 years, 9 months
Build failed in Jenkins: moose-latest-dev-4.8 #865
by admin@moosetechnology.org
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
9 years, 9 months
what makes moose
by Tudor Girba
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"
9 years, 9 months
another one but that one I do not understand it :)
by Stéphane Ducasse
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
9 years, 9 months
MooseImage
by Tudor Girba
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"
9 years, 9 months
MooseCycleTable depends on DSMFamixCell
by Stéphane Ducasse
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
9 years, 9 months