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."
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
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.
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.
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
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.
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, Stéphane Ducasse, Tudor Gîrba and Oscar Nierstrasz, “
Domain-Specific Program Checking,” Proceedings of the 48th International
Conference on Objects, Models, Components and Patterns (TOOLS’10)
--
Andre Hora
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.
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.