Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Visualizations (no need to read, just see pictures and click)
by Alexandre Bergel 12 May '11

12 May '11

Food for thoughts: http://well-formed-data.net/experiments/lifestream_mashup/ http://www.visualizing.org/html5/22246 (you can also scroll horizontally with your moose wheel) http://www.visualizing.org/stories/visualizing-war-dead (a bit morbid) to play: you just need to click around http://www.visualizing.org/html5/22246 http://moritz.stefaner.eu/projects/eigenfactor/ http://idl.fh-potsdam.de/projects/powerdome/ -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

Re: [Pharo-project] Re: Highlight problem with glamour
by Tudor Girba 12 May '11

12 May '11

Hi, On 12 May 2011, at 16:44, Marcus Denker wrote: > > On May 12, 2011, at 4:42 PM, Tudor Girba wrote: >> >> I did not mean that someone should look into the posted code. I was in a hurry and I simply asked a direct question if anyone has any idea of why 4096 would be a limit for highlighting text in TextMorph. The question had nothing to do with Glamour, but I am sorry if the form of the mail made you waste your time. >> >> In any case, I will look into this in more details. >> > > > maybe this is relevant? We should release 1.2.2.... > > http://code.google.com/p/pharo/issues/detail?id=4157 Hmm. Sounds similar, but I am too ignorant. I could reproduce the problem outside of Glamour. The issue is indeed not with TextMorph, but with PluggableTextMorph: string := ''. 1 to: 1000 do: [:i | string := string, 'abcde']. text := ((string asText addAttribute: TextColor red), ('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' asText)). (PluggableTextMorph on: text text: #yourself accept: #value) openInWindow Cheers, Doru > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > -- www.tudorgirba.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

2 3

Inner Classes
by Usman Bhatti 12 May '11

12 May '11

For nested types, I am setting the containing class to be the container entity of the nested class. I am trying to create a Tree View for my Moose entities. So, I have Namespace Namespace Class Method .... (Just to see my results are correct...) Earlier I was using downcast to change container entity into a Namespace. That allowed me to navigate from a parent namespace to a child namespace using Namespace.getChildScope(). However, Container entity does not allow me to perform this navigation as the only thing available with ContainerEntity is belongsTo. My question is: Why cannot we ascertain the containing elements of a ContainerEntity? thanx in advanace, Usman

3 3

Re: [Pharo-project] Re: Highlight problem with glamour
by Marcus Denker 12 May '11

12 May '11

On May 12, 2011, at 4:51 PM, Tudor Girba wrote: > Hi, > > On 12 May 2011, at 16:44, Marcus Denker wrote: > >> >> On May 12, 2011, at 4:42 PM, Tudor Girba wrote: >>> >>> I did not mean that someone should look into the posted code. I was in a hurry and I simply asked a direct question if anyone has any idea of why 4096 would be a limit for highlighting text in TextMorph. The question had nothing to do with Glamour, but I am sorry if the form of the mail made you waste your time. >>> >>> In any case, I will look into this in more details. >>> >> >> >> maybe this is relevant? We should release 1.2.2.... >> >> http://code.google.com/p/pharo/issues/detail?id=4157 > > Hmm. Sounds similar, but I am too ignorant. > > I could reproduce the problem outside of Glamour. The issue is indeed not with TextMorph, but with PluggableTextMorph: > > string := ''. > 1 to: 1000 do: [:i | string := string, 'abcde']. > text := ((string asText addAttribute: TextColor red), ('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' asText)). > (PluggableTextMorph on: text text: #yourself accept: #value) openInWindow > works fine in 1.2.2a -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] Re: Highlight problem with glamour
by Marcus Denker 12 May '11

12 May '11

On May 12, 2011, at 4:10 PM, Tudor Girba wrote: > Thanks, Fabrizio. > > I noticed a similar problem with highlighting Java code, but I thought it was related to the grammar. > > I CC-ed the Pharo mailing list. > > Anyone knows why it would be a problem to highlight text with more than 4096 characters in a TextMorph? > Which version of Pharo are you using? > Cheers, > Doru > > > On 12 May 2011, at 16:03, Fabrizio Perin wrote: > >> It basically breaks after 4096 characters. >> >> >> On 12 May 2011, at 16:02, Fabrizio Perin wrote: >> >>> Hi, >>> i was playing with textlint and i noticed that the highlight is broken. Seems that the problem is related to the length of the text. If you try to execute the script below you notice that the highlight doesn't work. If you lower 1000 to 100 it works. It seems that the break point is 194. After that it dies. >>> >>> | browser | >>> browser := GLMTabulator new. >>> browser >>> column: #details. >>> >>> "if you need initial display" >>> browser transmit to: #details; andShow: [:a | >>> a text display: [:x | >>> | string | >>> string := ''.1 to: 1000 do: [:i | string := string, 'jjjjj j j j j j jjj j']. >>> (string asText addAttribute: TextColor red), ('jjjjj j j j j j jjj j' asText) ] ]. >>> >>> browser openOn: 5 >>> >>> Any idea? >>> >>> Cheers, >>> >>> Fabrizio >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "The coherence of a trip is given by the clearness of the goal." > > > > > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

3 2

Highlight problem with glamour
by Fabrizio Perin 12 May '11

12 May '11

Hi, i was playing with textlint and i noticed that the highlight is broken. Seems that the problem is related to the length of the text. If you try to execute the script below you notice that the highlight doesn't work. If you lower 1000 to 100 it works. It seems that the break point is 194. After that it dies. | browser | browser := GLMTabulator new. browser column: #details. "if you need initial display" browser transmit to: #details; andShow: [:a | a text display: [:x | | string | string := ''.1 to: 1000 do: [:i | string := string, 'jjjjj j j j j j jjj j']. (string asText addAttribute: TextColor red), ('jjjjj j j j j j jjj j' asText) ] ]. browser openOn: 5 Any idea? Cheers, Fabrizio

2 3

Issue 608 in moose-technology: VerveineJ exports some anchors with endLine = -1
by moose-technology＠googlecode.com 12 May '11

12 May '11

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-VerveineJ Milestone-4.4 New issue 608 by tudor.gi...(a)gmail.com: VerveineJ exports some anchors with endLine = -1 http://code.google.com/p/moose-technology/issues/detail?id=608 Parsing Silverpeas retrieves 515 model classes (out of 1858) with a FileAnchor that has a positive startLine, but an endLine that is -1. These classes can be checked by: - parse and load the MSE into Moose - select all model classes and then select based on: each sourceAnchor notNil and: [each sourceAnchor startLine > 0 and: [each sourceAnchor endLine = -1]] Even more interesting is that if you look in the methods of these classes, they have a correct endLine.

3 6

DistributionMap and SmallLint rules
by Andre Hora 12 May '11

12 May '11

Hello, I just created some visualizations (Marcus's idea) using DistributionMap with SmallLint rules to check how distributed are the lint problems in a class. I enclosed some figures with the distribution for some packages of Moose. So, the small boxes represent methods. The red color is a method with more than 3 lint problems, the orange 2 problems, green 1 problem and white no problem. We can clearly see a lot of "lint problems" in Famix package. Of course, we have some false-positives mainly for Glamour and Mondrian as we can check in [1]. Btw, I also created a job in Hudson to generate a simple report with smallLint rules in Moose (and Pharo): Job: https://pharo-ic.lille.inria.fr/hudson/view/LintReport/job/LintReportMoose Report: https://pharo-ic.lille.inria.fr/hudson/view/LintReport/job/LintReportMoose/… regards, [1] Lukas Renggli, Stéphane Ducasse, Tudor Gîrba and Oscar Nierstrasz, “ Domain-Specific Program Checking,” Proceedings of the 48th International Conference on Objects, Models, Components and Patterns (TOOLS’10) -- Andre Hora

5 6

Issue 628 in moose-technology: [Glamour] Useless mouseUp event in test
by moose-technology＠googlecode.com 11 May '11

11 May '11

Status: New Owner: tudor.gi...(a)gmail.com Labels: Type-Defect Priority-Medium New issue 628 by damien.c...(a)gmail.com: [Glamour] Useless mouseUp event in test http://code.google.com/p/moose-technology/issues/detail?id=628 GLMTreeMorphicTest>>testChildrenBlock has a line which looks like: self send: self tree mouseUpOnItem: self treeRoots first. The test passes whether the line is present or not.

1 3

Issue 627 in moose-technology: Glamour-Morphic unit tests are fragile to changes in the submorphs tree
by moose-technology＠googlecode.com 11 May '11

11 May '11

Status: New Owner: damien.c...(a)gmail.com CC: tudor.gi...(a)gmail.com Labels: Type-Engineering Priority-Low New issue 627 by damien.c...(a)gmail.com: Glamour-Morphic unit tests are fragile to changes in the submorphs tree http://code.google.com/p/moose-technology/issues/detail?id=627 Glamour-Morphic unit tests contain code like this: treeMorph := window submorphs last submorphs first submorphs first submorphs first submorphs first. self assert: treeMorph class = LazyMorphTreeMorph. Which is very fragile to any changes in the submorphs tree. I propose to replace each of these piece of code to something like: treeMorph := self find: LazyMorphTreeMorph in: window The method #find:in: could use something like Morph>>allMorphsDo: to find a corresponding morph in the submorphs tree. I guess this would made the code slower but haven't tested it.

1 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev