Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Issue 901 in moose-technology: ROCachedLabel - improved performance with large numbers of elements

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 901 by benjamin...(a)gmail.com: ROCachedLabel - improved performance with large numbers of elements http://code.google.com/p/moose-technology/issues/detail?id=901 With large numbers of elements that display strings, Roassal is quite slow. Tracing this down shows the main culprit is #extentFor:. A proposed solution ROCachedLabel is provided in attached .st file which returns a cached extentFor value. This is nilled out when the value of the string changes. The other variables in ROCachedLabel are also cached, but the performance gain from these is unclear. To test the effect of this, try the following script for both ROLabel and ROCachedLabel... --- | rawView el count elements | rawView := ROView new @ RODraggable. count := 1000. elements := (1 to: count) collect: [ :x | el := (ROElement spriteOn: x) + ROLabel "ROCachedLabel". el on: ROMouseLeftClick do: [ :ev | ev element model: (ev element model + 1). ev element view signalUpdate . ] ]. rawView addAll: elements. 1 to: count do: [ :x | rawView add: (ROEdge new from: (elements at: x) to: (elements at: (Random new nextInt: count - x + 1))) + ROLine. ]. ROHorizontalTreeLayout on: rawView elements. rawView open --- Also attached is the MessageTally report from which it was determined that #extentFor was the problem. Attachments: ROCachedLabel.st 1.3 KB MessageTally-ROLabel.txt 38.8 KB

12 years, 3 months

GLMAction>>shortcutAsString

by Ben Coman

Some time ago I hit a problem due to GLMAction>>shortcutAsString sometimes returning nil. I fixed this by appending --- ifNil: [ '' ] --- to the method, and then moved on, so sorry I have no record of the context the problem occurred in. I just noticed this again now clearing out Monticello of changes and thought I should report it. cheers -ben

12 years, 3 months

a mirror of moose CI

by Usman Bhatti

Hello, I think it would be good to have a mirror of moose CI so that we have a replicated service because CI at moosetechnology is currently down and it's impeding our work. I can setup a mirror of moose CI in Lille to ensure continuity of the service. For that I need to know which configuration to load. I have tried to load development symbolic version and I had a few problems. Core-default loads fine but I'm not sure that this is the correct version to build a moose image from pharo 1.4. regards, Usman

12 years, 3 months

ci.moosetechnology.org back online

by Tudor Girba

Hi, ci.moosetechnology.org is back online on a stronger server. I still have problems with getting moosetechnology.org to work with apache, though. Cheers, Doru -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

12 years, 3 months

Extending FAMIX

by roberto.minelli＠usi.ch

Hi guys, I modeled a Git repository in Smalltalk. My first class objects are: - GitterAuthor - GitterRevision, and - GitterRepository I want to have a Moose model (i.e., an extension of FAMIX), so that I can use all the tool suite of Moose. I have a couple of questions on that since I don't find a good explanation on how to do that. Let me describe what I did. For each of the classes listed above: - I create a class side method 'annotation' as follows GitterRepository class>>annotation <MSEClass: #GitterRepository super: #Object> <package: #Gitter> - For each of the accessor of the instance variables I added the pragmas as follows: GitterRepository>>authors <MSEProperty: #authors type: #GitterAuthor > <multivalued> <MSEComment: 'Authors appearing as committers in this Repository.'> The first question is what can be the choice for the type of a property? As far as I understood I can have Number, String, and one of the classes belonging to the model. But what if an instance variable has type, for example FileSystemGitRepository. Should I put #Object in the type or what else? - The last thing I did is to create an accept method to add the visitor, as follows GitterRepository>>accept: aVisitor aVisitor visitGitterRepository: self. Then implemented FAMIXImportingVisitor>>visitGitterRepository: aGitterRepository self visitEntity: aGitterRepository . I'm wondering if I did everything needed and how can I test it in a way.. Cheers and thanks in advance, Roberto Minelli

12 years, 3 months

Glamour question

by Nicolas Anquetil

In a Glamour browser with 3 pane (#master, #slave1, #slave2) I would like to be able to "send" the selection in #master either to #slave1 or #slave2 a nice behaviour would be: - if I select a line into #master, it is transmitted to #slave1 (browser transmit) from: #master; to: #slave1 - but on a context menu in #master, I can tell him to send to #slave2 instead act: [:each | each selection something-here] entitled: 'Display in slave 2'; among other things, it means the selection+context menu in #master would not automatically transmit to #slave1 Another question is what should I put in the act: block to transmit to #slave2 ? nicolas -- Nicolas Anquetil -- RMod research team (Inria)

12 years, 3 months

importers and extractors

by Tudor Girba

Hi, A while ago we had a discussion between the use of the importer and extractor terms. In particular, Stef argued that the SmalltalkImporter should be named SmalltalkExtractor to denote that we talk about source code. I think it is useful to get a consensus around this topic. I happen to have implemented recently a half a dozen importers for various situations, and here is the current status of my understanding of the meaning of terms: - importer stands for creating a model out of some source that is external to Moose. This can be source code in a file, an XML file, an MSE file, or source code in Smalltalk. It is the importer that contains the factory logic of creating and ensuring entities. This is a simple meaning that can be communicated in a simple manner: "we import the model from something" - extractor stands for the dedicated logic of traversing the external source. In most cases, the importer requires one or more extractors as helpers to do the job. For example, the SmalltalkImporter requires the SmalltalkMethodVisitor. The MSE importer is special, because it does not have explicit factory methods, and thus it is one with the extractor. What do you think? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

12 years, 3 months

Re: [Pharo-project] Martin Fowler's kind words about Smalltalk and Moose ...

by Tudor Girba

Unexpected, indeed. But, the cool thing is that Moose popped up in his mind in a seemingly unrelated area. From this point of view, Moose is not just an analysis platform, but it became an example of how "reprogrammability" (which is just another name for reflective environments as I would call it) can become practical. So, it is as much a positive thing for Moose as it is for Pharo. Did I mention that I think that Pharo can use Moose as a killer app? :) Cheers, Doru On Jan 11, 2013, at 5:21 PM, Geert Claes <geert.wl.claes(a)gmail.com> wrote: > http://martinfowler.com/bliki/InternalReprogrammability.html > > > > > -- > View this message in context: http://forum.world.st/Martin-Fowler-s-kind-words-about-Smalltalk-and-Moose-… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- www.tudorgirba.com "Don't give to get. Just give."

12 years, 3 months

Moose ... Martin Fowler

by Geert Claes

http://martinfowler.com/bliki/InternalReprogrammability.html -- View this message in context: http://forum.world.st/Moose-Martin-Fowler-tp4662960.html Sent from the Moose mailing list archive at Nabble.com.

12 years, 3 months

Glamour-Roassal RODraggableWithVelocity versus a large number of elements

by Ben Coman

This is a post in two parts. The first is purely Rossal and the second is on the Glamour-Roassal integration. Part One RODraggableWithVelocity seems to have a problem overshooting the drag distance with large numbers of elements. For example, referring to the next script, with RODraggable only, if I drag the view background sideways by a quarter-window-width, even though it takes a few seconds to respond to a drag, the final position of the elements is a quarter-window-width sideways. However with RODraggableWithVelocity, doing the same action, I observe the elements briefly appear a quarter-window-width sideways, then another quarter-window-width, then another until the elements disappear off the side of the window. This behaviour disappears from this example by reducing to 1000 elements, but occurs in my application with only 100 elements (plus an equal number of edges). ----- | rawView domain | rawView := ROView new @ RODraggable " @ RODraggableWithVelocity " . domain := 1 to: 10000. domain do: [ :x | rawView add: (ROElement on: x) + (ROLabel) ]. ROVerticalLineLayout on: rawView elements. rawView open ---- Part Two Given that the paintingBlock of the GLMRoassalPresentation returned by 'GLMCompositePResentation>>rossal' is passed a ROMondrianViewBuilder that has already added RODraggableWithVelocity to the rawView, how do I remove that RODraggableWithVelocity from the rawView? The '@' method seems to work differently between ROView (in processing the interaction straight away) and ROElement (which seems to store the interaction for later processing so it can be removed more easily). In addition, could something like a GLMMorphicRoassalRawRenderer be added to the Glamour-Roassal interface? - which would pass an unencumbered ROView to the paintingBlock. It is not really a Glamour-Roassal interface at the moment, more of a Glamour-Mondrian interface. I hacked up a GLMMorphicRoassalRawRenderer as best I could as part of my experiment with "Interactive Roassal" but it wasn't very elegant and I'm not sure it was correct. cheers -ben

12 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev