Moose-dev October 2013

moose-dev@list.inf.unibe.ch

29 participants
128 discussions

Re: moose 4.9
by Stephan Eggermont 25 Oct '13

25 Oct '13

Hi Doru, No problem. I've been using 4.9 development since 4.8 is finished. When loading older stuff I've had to replace 'mondrian' by 'roassal' in glamour browsers a few times. Those packages I already committed. Stephan

1 0

moose 4.9
by Tudor Girba 25 Oct '13

25 Oct '13

Hi, I just released Moose 4.9. It holds a couple of fixes and has one Mondrian engine less :): https://code.google.com/p/moose-technology/issues/list?can=1&q=4.9 Please take a look at it and say if you see any problem. We should announce it and then move to Pharo 3.0. Doru -- www.tudorgirba.com "Every thing has its own flow"

1 1

SortedCollection and flatCollect
by roberto.minelli＠usi.ch 24 Oct '13

24 Oct '13

Hi, I am experiencing problems in using #flatCollect: on a SortedCollection. This reproduces my problem: ((OrderedCollection with: #(1 2 3) with: #(3 4 5)) asSortedCollection: [ :a :b | true ]) flatCollect: #yourself I am using the last Pharo 2.0 image from the CI server (ZeroConf script). SortedCollection(Object)>>shouldNotImplement SortedCollection>>at:put: WriteStream>>pastEndPut: WriteStream>>nextPut: WriteStream(Stream)>>nextPutAll: in Block: [:v | self nextPut: v] Array(SequenceableCollection)>>do: WriteStream(Stream)>>nextPutAll: WriteStream>>nextPutAll: SortedCollection(Collection)>>flatCollect: in Block: [:each | stream... SortedCollection(OrderedCollection)>>do: SortedCollection(Collection)>>flatCollect: Thanks for any help, Roby

1 0

Discover dependencies
by roberto.minelli＠usi.ch 24 Oct '13

24 Oct '13

Hi, I have a couple of questions about dependencies... In a previous release of my project, I had an explicit Moose model, and I added the load of Moose to my ConfigurationOf. Now, to ease the loading, I removed the meta model (i.e., removed dependencies with MooseEntity, annotations, etc.). Since I was working with Moose installed I exploited some cool messages (e.g., flatCollect is the first that came to my mind). The point is that I do not remember where and why I used methods from Moose. The question is, apart from loading my project without Moose and playing around to see when it crashes, is there any way to automatically detect missing dependencies or something like that? Cheers and thanks in advance, Roby

1 0

Jenkins build is back to stable : moose-latest-dev-4.9 #1337
by admin＠moosetechnology.org 24 Oct '13

24 Oct '13

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.9/1337/>

1 0

Issue 991 in moose-technology: Clean access isWrite/isRead
by moose-technology＠googlecode.com 24 Oct '13

24 Oct '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Milestone-4.9 Component-Famix New issue 991 by tu...(a)tudorgirba.com: Clean access isWrite/isRead http://code.google.com/p/moose-technology/issues/detail?id=991 isWrite is the mandatory field. If it is set, the Access is clearly either write or read. However, if it is not set, the situation is ambiguous. We need a systematic response. So, when isWrite is nil: - isWrite and isRead return false - isReadWriteUnknown returns true -- 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

Build failed in Jenkins: moose-latest-dev-4.9 #1335
by admin＠moosetechnology.org 24 Oct '13

24 Oct '13

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.9/1335/> ------------------------------------------ Started by upstream project "gtoolkit" build number 426 originally caused by: Started by timer Started by upstream project "petitjava" build number 291 originally caused by: Started by timer Started by upstream project "petitparser" build number 253 originally caused by: Started by timer Started by upstream project "roassal" build number 573 originally caused by: Started by timer Started by upstream project "gtoolkit" build number 427 originally caused by: Started by upstream project "glamour" build number 357 originally caused by: Started by timer Building remotely on moose-slave in workspace <https://ci.inria.fr/moose/job/moose-latest-dev-4.9/ws/> Deleting project workspace... done [moose-latest-dev-4.9] $ /bin/sh -xe /tmp/hudson7245081017407357872.sh + bash + wget --quiet -O - http://get.pharo.org/20+vmLatest 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.9 + REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main + ./pharo moose-latest-dev-4.9.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 resolve: ConfigurationOfCommandShell [ConfigurationOfCommandShell] in <https://ci.inria.fr/moose/job/moose-latest-dev-4.9/ws/package-cache> http://www.squeaksource.com/MetacelloRepository ERROR: 'GoferRepositoryError: Could not access http://www.squeaksource.com/MetacelloRepository: ZnHttpUnsuccessful: 503 Service Temporarily Unavailable' [0mMetacelloFetchingMCSpecLoader(Object)>>error: MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer: in Block: [| references nearestReference cachedReference ext...etc... MetacelloPharoPlatform>>do:displaying: in Block: [aBlock value] BlockClosure>>ensure: RPackageSet class>>withCacheDo: 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: MetacelloPharoPlatform>>do:displaying: MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer: MetacelloPackageSpec>>loadUsing:gofer: MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories: in Block: [:pkg | pkg loadUsing: self gofer: gofer] Array(SequenceableCollection)>>do: MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories: MetacelloFetchingMCSpecLoader>>explicitLoadPackageSpecs:repositories: in Block: [super linearLoadPackageSpecs: packageSpecs reposi...etc... BlockClosure>>ensure: MetacelloLoaderPolicy>>pushLoadDirective:during: MetacelloLoaderPolicy>>pushExplicitLoadDirectivesDuring:for: MetacelloFetchingMCSpecLoader>>explicitLoadPackageSpecs:repositories: MetacelloPackageSpec>>explicitLoadUsing: MetacelloPackageSpec>>loadUsing: in Block: [self explicitLoadUsing: mcLoader] MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>doingLoads: MetacelloPackageSpec>>loadUsing: [0m[31mGot startup errors: [0m[31m Error: Could not resolve: ConfigurationOfCommandShell [ConfigurationOfCommandShell] in <https://ci.inria.fr/moose/job/moose-latest-dev-4.9/ws/package-cache> http://www.squeaksource.com/MetacelloRepository ERROR: 'GoferRepositoryError: Could not access http://www.squeaksource.com/MetacelloRepository: ZnHttpUnsuccessful: 503 Service Temporarily Unavailable' [0mBuild step 'Execute shell' marked build as failure Archiving artifacts Recording test results

1 0

Issue 990 in moose-technology: Mondrian should be replaced with Roassal
by moose-technology＠googlecode.com 24 Oct '13

24 Oct '13

Status: Fixed Owner: ---- Labels: Type-Engineering Priority-Medium Milestone-4.9 New issue 990 by tu...(a)tudorgirba.com: Mondrian should be replaced with Roassal http://code.google.com/p/moose-technology/issues/detail?id=990 This issue is just to document that we removed Mondrian in Moose 4.9 -- 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 0

Class AthensCairoSurface missing in Athens Version 2.5?
by Alexandre Bergel 22 Oct '13

22 Oct '13

hi! Apparently this class is not present in Version 2.5. The example is broken because of this apparently: AthensCairoSurfaceExamples exampleInterop => error Any idea what's going on? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 9

Issue 985 in moose-technology: Table presentation renders with a glitch due to spliters
by moose-technology＠googlecode.com 21 Oct '13

21 Oct '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Milestone-4.9 Component-Glamour New issue 985 by tu...(a)tudorgirba.com: Table presentation renders with a glitch due to spliters http://code.google.com/p/moose-technology/issues/detail?id=985 The problem appears on any table rendered with Glamour. The problem is documented here: http://www.humane-assessment.com/blog/searching-for-a-morph-glitch/ -- 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

← Newer
1
...
4
5
6
7
8
9
10
...
13
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev October 2013