Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

moose panel open?
by Alexandre Bergel 22 Feb '11

22 Feb '11

Hi! The last hudson version does not have the open panel? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 1

Version number for Moose
by Alexandre Bergel 22 Feb '11

22 Feb '11

Hi! I am working on using MetacelloBrowser for Moose. The goal is to make explicit all the versions of Moose and keep a record of them. Each new commit of one of the Moose package or each new version of a dependent library should produce a new version of Moose. I guess we all want that. I use this for Mondrian and I am quite happy. I propose to use a simple version numbering. Something like 4.3.X where X will increment at each new commit made in one of the packages of Moose. I have produced version 4.3.1. It loads in the latest Pharo 1.2. However, it contains a bit of hack. I believe that a Configuration version should not depend on the default baseline. It still contains: spec project: 'MooseAlgos for Moose' with: '2.2'; project: 'PetitParser for Moose' with: 'default'; project: 'DSM for Moose' with: 'default'; project: 'Glamour for Moose' with: '2.1'; project: 'Mondrian for Moose' with: 'default'; project: 'SmallDude for Moose' with: 'default'; project: 'Merlin' with: '1.0'; project: 'RPackage' with: 'default'. If you agree with this, I can produce a fix version for each of these package. Does it goes in the right direction? I already produce Version 2.1 of Glamour. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

4 7

intall default model doesn't work
by Fabrizio Perin 22 Feb '11

22 Feb '11

Hi, i did try to install the sample models using the proper menu entry into the Moose Panel but apparently it doesn't work. Should i open an issue? Cheers, Fabrizio

3 4

Fade layout
by Alexandre Bergel 22 Feb '11

22 Feb '11

Hi, I am glad to announce that I incorporated Eduardo's work into Mondrian. He implemented FADE. FADE is a force directly algorithm (also called spring algorithm or spring layout) invented by Aaron Quigley (http://www.cs.st-andrews.ac.uk/~aquigley/?Research:Past_Projects:FADE). FADE is faster than MOForceBasedLayout when more than 350 edges and 350 nodes have to be layouted. On my machine: [| view | view := MOViewRenderer new. view shape rectangle withText. view nodes: Collection withAllSubclasses. view nodes: Morph withAllSubclasses. view edgesFrom: #superclass. view XXXXX. view root applyLayout ] timeToRun For XXX = fadeLayout, it takes 12204 ms to compute For XXX = forceBasedLayout, it takes 17604ms In version 2.51 of Mondrian Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 2

Re: Hudson build is still unstable: moose-latest-dev #209
by Tudor Girba 22 Feb '11

22 Feb '11

No, it should not be rewritten. The problem is due to me removing DSM and SmallDude from the default configuration because of Metacello problems. I hope to restart working on it next week. Cheers, Doru On 22 Feb 2011, at 10:56, Cyrille Delaunay wrote: > MooseSqueakClassPackageImporterTest>>#testCategoryImporter is looking for all packages matching ''Moose-TestResources-Dsm*'', but there is no packages like that in the image. I guess the test should be re-written? > > 2011/2/22 <admin(a)moosetechnology.org> > See <http://hudson.moosetechnology.org/job/moose-latest-dev/209/> > > > -- www.tudorgirba.com "Be rather willing to give than demanding to get."

1 0

Fwd: [ANN] pharo focused sprint - bern, feb 26
by Tudor Girba 21 Feb '11

21 Feb '11

Hi, I would like to remind you that this Saturday, February 26, we organize a Sprint at SCG, University of Berne, Switzerland (room 107): http://scg.unibe.ch/contact/maps Further details can be found below. Please let us know by mail if you plan to attend and what you would wish to work on (see below). Cheers, Doru Begin forwarded message: > From: Tudor Girba <tudor.girba(a)gmail.com> > Date: 1 February 2011 16:38:30 CET > To: "Pharo-project(a)lists.gforge.inria.fr Development" <pharo-project(a)lists.gforge.inria.fr> > Cc: Adrian Lienhard <alienhard(a)netstyle.ch> > Subject: [ANN] pharo focused sprint - bern, feb 26 > > Hi, > > We would like to organize a Pharo Sprint on Saturday, February 26 at SCG, University of Berne, Switzerland (room 107): > http://scg.unibe.ch/contact/maps > > Unlike other sprints, this would not be about fixing things from the tracker, but about building something new and reviewing the situation around one central topic. For this one, the main topic will be Morphic and the IDE. Why? Because it is time to rethink our day-to-day tools and bring them closer to this century (ok, maybe decade :)). It is Ok if you are not a specialist. It is more important to want to participate and learn. The rest will come in time. > > ***** Please let us know by mail if you plan to attend and what you would wish to work on (see below). > > Proposed tasks (other tasks are possible in the same area): > - Enhancements of Morphic widgets: > --- TabGroupMorph with lazy pages, closable tabs, overflow handling and toolbars (a start exists in Glamour) > --- High level support for collapsable panes (based on the input of Gary) > --- SearchMorph with multiple groups of items (like in Spotlight) > --- MorphTreeMorph integrated with GeneralScrollPane to allow for space filling > --- BreadcrumbMorph > --- Hyperlinks in TextMorphs > - Test and enhance the current IDE > - Evaluate TextMorphs: NewTextMorph, PluggableTextMorph, SMxPluggableTextMorph etc > - Prototype a new ToolSet solution > - Enhancements of Glamour and of the Glamorous Toolkit > --- Debugger > --- Coder > --- Multipage Workspace > --- CodeBubbles > - Develop WeakAnnouncement (start from the implementation of Lukas) > - Evaluate the various keybinding implementations > - Evaluate ToolBuilder > - Evaluate the path to adopt SimpleMorphic > > A second working topic is getting Monticello faster, but this will only be tackled if there are enough people for the first one. > > Cheers, > Adrian and Doru > > > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > -- www.tudorgirba.com "It's not how it is, it is how we see it."

1 0

XMLWriter question
by Stéphane Ducasse 21 Feb '11

21 Feb '11

Hi guys I have a question about XMLWriter. I have cards and group of cards. Each class know how to serialize itself. For card I have xmlOn: (one of my methods) that describes the card attributes Card>>xmlOn: aWriter "write a description of the receiver properties as xml uing aWriter, an instance of XMLWriter" aWriter tag name: #card; with: [self xmlInstVarOn: aWriter] Group>>xmlOn: aWriter "write a description of the receiver properties as xml uing aWriter, an instance of XMLWriter" | cardWriter | cardWriter := XMLWriter new. cards do: [:each | each xmlOn: cardWriter]. aWriter tag name: #group; with: [ aWriter tag: #groupName with: self groupName. aWriter tag: #cards with: [ aWriter raw: cardWriter contents]] And I'm not really happy. Because I would like to avoid to use raw: and instantiate a new writer. I would like to know how I could use the write to pass the results of the iteration over cards I wanted to write something like aWriter tag name: #group; with: [ aWriter tag: #groupName with: self groupName. aWriter tag: #cards with: [self cards do: [:each | each xmlOn: aWriter]]

1 0

preparing 4.3
by Tudor Girba 21 Feb '11

21 Feb '11

Hi, It seems that I am the only one working on 4.3 :). So the plan is to release it in 10 days, on February 20. Please let me know if you are interested in giving a hand. It can be as small as testing or writing some piece of documentation or a blog post. Cheers, Doru -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."

3 3

[ANN] Moose 4.3
by Tudor Girba 21 Feb '11

21 Feb '11

We are happy to announce the Moose Suite version 4.3: *http://moosetechnology.org/download* What is new: - New look and feel - New and flexible API to browse FAMIX models - Extensible Moose Finder - Enhanced Glamour engine to deal with complex actions - Enhanced FAMIX support for Java systems - Enhanced Glamour rendering for Morphic - Enhanced meta browser - Enhanced documentation of Mondrian - Enhanced XMLSupport - Enhanced Smalltalk importer A list of issues addressed in this release can be found at: *http://code.google.com/p/moose-technology/issues/list?can=1&q=status=Fixed%20milestone=4.3* Have fun, The Moose Team

1 0

Issue 539 in moose-technology: Introduce SourceLanguage as an explicit entity
by moose-technology＠googlecode.com 20 Feb '11

20 Feb '11

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Famix Milestone-4.3 New issue 539 by tudor.gi...(a)gmail.com: Introduce SourceLanguage as an explicit entity http://code.google.com/p/moose-technology/issues/detail?id=539 Currently, sourceLanguage is modeled with a symbol stored in the Model. This is suboptimal due to at least two things: - the only way to decide strategies of what highlighting to use when displaying text is with an if - there is no possibility of having multiple languages in the same model I would like to introduce FAMIXSourceLanguage as an explicit entity that can be linked to any FAMIXEntity. If an entity does not have a FAMIXEntity, it will fallback to the mooseModel sourceLanguage. The overall MooseModel sourceLanguage will be decided based on the FAMIXSourceLanguage object that has no attached entities.

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev