Hi all,
I like moose a lot, but I have a problem with the way the moose configurations are used. So I would like to discuss this on the developers list. I would like to know if more people experience these problems.
First of all, I like the way the development works out. All development configurations simply do not use any version numbers, and therefor return the latest version. Maybe we should create an actual development version, that is empty, except for the packages we want to be a fixed version. But this is a minor point.
But once moose is released, a snapshot is taken, it is no longer a proper configuration. Main drawback is that all groups and such are removed. But also referred configurations are no longer used.
I believe it should be possible to upgrade to the stable version of a configuration in the place where a development version was used. Especially when the development version is released. Taking snapshots prevents this, since it no longer contains groups.
Also I think that bug fixes of used configurations should be imported automatically. Taking snapshots prevents this, since they do not use used configurations.
Finally there is a scenario that actually breaks configurations downstream. When I load version 1.6-baseline of PetitParser and sub sequentially ask for the current version, it returns 1.7-snapshot. But since I try to load the 'Core' group of PetitParser, I can no longer use my configuration. It simply halts on the error that the group 'Core' could not be found.
I have two suggestions to improve the process:
> We either choose to stick to snapshots for the releases, since this is a very reliable way to reproduce a build (with all known bugs). But for this we create a class SnapshotOf<projectname>, for each project, with all the methods needed, to indicate it is not a configuration. We could add previous releases to this class.
> We create a proper stable version, in the way configurations are meant to be. We bless these methods with release and only update versions if it is a bug fix. We also create a new development version at the moment we make the release, so we can continue development, without breaking the release
For the last suggestion I have updated my Metaceller tool (part of GToolkit). It is still beta, but it produces proper release version for a single configuration, based on the current state of the image.
Regards,
Diego
While trying to import some monticello packages from smalltalkhub with a
MooseMonticelloHTTPImporter, we noticed some less nice behavior from
the MooseGroupRuntimeStorage. at: ifAbsent is really slow when
byName contains 128 elements and elements 64K. What is the usecase for
putting the elements in an OrderedCollection?
Doing
byName at: anElement mooseName asSymbol put: anElement.
in add:
makes it perform a lot better. Is there a usecase where you don't want
byName to be filled immediately?
Diego & Stephan
Shoot!
Thanks for spotting it! I'm currntly on holidays but i'll check this out asap.
--- Mensaje Original ---
Desde: "Alexandre Bergel" <alexandre.bergel(a)me.com>
Enviado: 17 de septiembre de 2013 5:18 PM
Para: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Asunto: [Moose-dev] Re: GraphET x-axis label - bug?
Thanks for having spotted the bug.
In the meantime, you may want to check this how to add labels in a "manual" way:
http://stackoverflow.com/questions/18831437/graph-et-x-axis-labels/18853456…
Cheers,
Alexandre
On Sep 16, 2013, at 11:18 AM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
> Hello,
>
> I am starting to use GraphET and looks really nice. While learning to script with it, I stumbled upon this script that does not place x-axis label in the correct place. In fact the x-axis label is superimposed on y-axis one. Here's how you can reproduce it:
>
> tmpBrowser := GLMDashboard new.
> tmpBrowser addPaneNamed: #first.
> tmpBrowser transmit to: #first; andShow: [:a |
> a graphET
> title: 'First Chart with ET';
> chart: [:chart :mooseModel|
> chart verticalBarDiagram
> models: (1 to: 3);
> xAxisLabel: 'Test label';
> yAxisLabel: 'Another';
> regularAxis.
> ].
> ].
> tmpBrowser openOn: 1
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
It seems we should update the Magritte and OSProcess dependencies:
- Loading Magritte seems to load a wrong version of Grease that has a conflict with RPackage
- OSProcess was published on MetacelloRepository
It would be great if anyone would take a look at this, and then we can re-snapshot a Moose 4.8.1.
Cheers,
Doru
--
www.tudorgirba.com
"It's not how it is, it is how we see it."
