Lukas, I clearly identified one (Text on: Symbol) creator as the
#summary of a MCConflict on a MCClassDefinition.
2009/11/10 Lukas Renggli :
> Maybe you can find the creator of the Text instances with Text inside
> by modifying Text>>#setString:setRuns:?
>
> Text>>setString: aString setRuns: anA
Maybe you can find the creator of the Text instances with Text inside
by modifying Text>>#setString:setRuns:?
Text>>setString: aString setRuns: anArray
(aString isText)
ifTrue: [ self haltOnce ].
string := aString.
runs := anArray
Don't forget to enable t
I cannot reproduce the problem. There must be a different cause in
your image, which is the root of the problem and should be fixed.
In all my images all Text object contain only Strings:
Text allInstances reject: [ :each | each string isString ]
--> #()
Text allInstances select: [ :each
Hi Lukas,
found the same problem again in a MCMergeBrowser
There are pure Symbols and Symbol asText in the list of changes.
This list of changes is computed in
MCPatchBrowser>>list
^ self items collect: [:ea | ea summary]
In my case, the second element of the list was a
MCConflict>MCAddi
>>> And so far this is not the case. In fact I preferred the old way
>>> because it was dead simple and
>>> working. accesses to iv /accesses to classVar.
>>
>> I find it dead simple. Clicking on 'variables' always shows you what
>> you can see from the current browsing context:
>
> In the menu?
I
Ok I will check again
On Nov 7, 2009, at 10:30 PM, Lukas Renggli wrote:
>> And so far this is not the case. In fact I preferred the old way
>> because it was dead simple and
>> working. accesses to iv /accesses to classVar.
>
> I find it dead simple. Clicking on 'variables' always shows you what
On Nov 8, 2009, at 10:21 AM, Lukas Renggli wrote:
> Something slightly unrelated:
>
> Already last week I fixed all but one of the broken refactoring tests.
> AFAIK, these tests never worked in the Squeak or Pharo port of the
> refactoring engine. Last time I check we had 60 plus broken tests. No
Something slightly unrelated:
Already last week I fixed all but one of the broken refactoring tests.
AFAIK, these tests never worked in the Squeak or Pharo port of the
refactoring engine. Last time I check we had 60 plus broken tests. Now
the situation is better:
334 run, 333 passes, 0 expecte
Hi Hernán,
I cannot reproduce that problem.
Looks like in you end up with a non-string in a Text class. That
should never happen, because then the class invariants of Text are not
met. If OB instantiates a Text like that, this is an OB bug of course,
but I can't figure out a place where that coul
> And so far this is not the case. In fact I preferred the old way
> because it was dead simple and
> working. accesses to iv /accesses to classVar.
I find it dead simple. Clicking on 'variables' always shows you what
you can see from the current browsing context:
- When you are on the instance s
Let say that knowing who access to a given variables is one important
browsing behavior and even a blind should be able to do it without
thinking.
And so far this is not the case. In fact I preferred the old way
because it was dead simple and
working. accesses to iv /accesses to classVar.
Stef
Stef,
[sorry about empty mail]
If you have the instance selected when you chase you get the class variables
when you select class in chaser...instance variables when instance selected.
If you have the class selected when you chase you apear to get the class
variables for the superclasses when
- "Stéphane Ducasse" wrote:
| Lukas
|
| I tried but it did not work.
| I tried on NetNameResolver
| to see how useOldNetwork is set.
|
| Stef
|
|
| On Nov 7, 2009, at 6:05 PM, Lukas Renggli wrote:
|
| > 2009/11/7 Stéphane Ducasse :
| >> when you are on the class side if you method has a
NetNameResolver displays correctly for me. Are you sure you used the
right browser? :
SystemBrowser default: OBSystemBrowserAdaptor.
OBSystemBrowser openOnClass: NetNameResolver class.
2009/11/7 Stéphane Ducasse :
> Lukas
>
> I tried but it did not work.
> I tried on NetNameResolver
> to see how
Lukas
I tried but it did not work.
I tried on NetNameResolver
to see how useOldNetwork is set.
Stef
On Nov 7, 2009, at 6:05 PM, Lukas Renggli wrote:
> 2009/11/7 Stéphane Ducasse :
>> when you are on the class side if you method has a classVariable and
>> you want to know who access it.
>> Then
2009/11/7 Stéphane Ducasse :
> when you are on the class side if you method has a classVariable and
> you want to know who access it.
> Then chase variables show you the class instance varaibles but not the
> classVariable.
Yes, that's a bug. When you are on the class side, the class variables
of
when you are on the class side if you method has a classVariable and
you want to know who access it.
Then chase variables show you the class instance varaibles but not the
classVariable.
Too bad.
Stef
___
Pharo-project mailing list
Pharo-proje
17 matches
Mail list logo
