Color yzw

2016-01-15 13:33 GMT+01:00 Nicolai Hess <[hidden email]>:
>
>
> No, you are right. It isn't shown in red, even if it is a unknown symbol.
>
> I'll have a look.

Oh, that is bad.
The check for existing Symbols always succeeds, because
Parsing an expression with RBParser creates RBMethod- and RBMessageNodes
And they use always #asSymbol for its selectors.

That means, as soon as we parse an expression, we add all new Symbols.

And as the parser is now used for syntax highlighting as well, this means
new symbols will be added on compiling new methods and expressions
or just highlighting them. That's bad.

anyone an idea?

 
>
>
>
>
> 2016-01-15 13:28 GMT+01:00 Nicolai Hess <[hidden email]>:
>>
>>
>>
>> 2016-01-15 13:10 GMT+01:00 stepharo <[hidden email]>:
>>>
>>> Hi
>>>
>>> In the past in Pharo when a message was not matching an existing selector the selector was turned into red
>>
>>
>> I think this only happened for names not known as a symbol, regardless whether this symbol exists as a message selector or just a symbol.
>>
>> If no symbol table includes the symbol yzw
>>
>> Color yzw
>>
>> will show yzw red,
>>
>> Color yello
>> will print yello in italic
>> Color yellow
>> will print yellow normal
>> Color jaune
>> will print jaune red, as long it is not in a SymbolTable.
>>
>>  
>>>
>>> So we could see immediately that you typed an error.
>>>
>>> Right now, the behavior only exists for Class
>>> so
>>>
>>>     Po is italiczec
>>>     Pox is red
>>>
>>> I played with the blueStyleTable but I cannot get it working on selector.
>>> Does anybody know?
>>>
>>> Such kind of glitch is slowing me when shooting new pharo videos.
>>>
>>> Stef
>>>
>>>
>>
>

> No, you are right. It isn't shown in red, even if it is a unknown symbol.
>
> I'll have a look.

Oh, that is bad.
The check for existing Symbols always succeeds, because
Parsing an expression with RBParser creates RBMethod- and RBMessageNodes
And they use always #asSymbol for its selectors.

That means, as soon as we parse an expression, we add all new Symbols.

And as the parser is now used for syntax highlighting as well, this means
new symbols will be added on compiling new methods and expressions
or just highlighting them. That's bad.

anyone an idea?

 
>> 2016-01-15 13:10 GMT+01:00 stepharo <[hidden email]>:
>>>
>>> Hi
>>>
>>> In the past in Pharo when a message was not matching an existing selector the selector was turned into red
>>
>>
>> I think this only happened for names not known as a symbol, regardless whether this symbol exists as a message selector or just a symbol.
>>
>> If no symbol table includes the symbol yzw
>>
>> Color yzw
>>
>> will show yzw red,
>>
>> Color yello
>> will print yello in italic
>> Color yellow
>> will print yellow normal
>> Color jaune
>> will print jaune red, as long it is not in a SymbolTable.
>>
>>  
>>>
>>> So we could see immediately that you typed an error.
>>>
>>> Right now, the behavior only exists for Class
>>> so
>>>
>>>     Po is italiczec
>>>     Pox is red
>>>
>>> I played with the blueStyleTable but I cannot get it working on selector.
>>> Does anybody know?
>>>
>>> Such kind of glitch is slowing me when shooting new pharo videos.
>>>
>>> Stef
>>>
>>>
>>
>

anyone an idea?

I'm trying to think.
Looks like it would be good to be able to make a distinction between symbols and selectors (selectors installed
in method dictionaries)

yes, this would improve code completion a bit, too, as there are more symbols than symbols that are actually names

of methods.

The data could be created per environment (Smalltalk globals) the first time and then cached till shutdown.

(it would be an array of size 46451, pointing to existing symbols).

The environment could cache sent selectors, too… pablo did an experiment with that.

Marcus 

2016-01-16 10:11 GMT+01:00 Marcus Denker <[hidden email]>:

anyone an idea?

I'm trying to think.
Looks like it would be good to be able to make a distinction between symbols and selectors (selectors installed
in method dictionaries)

yes, this would improve code completion a bit, too, as there are more symbols than symbols that are actually names

of methods.

The data could be created per environment (Smalltalk globals) the first time and then cached till shutdown.

(it would be an array of size 46451, pointing to existing symbols).

The environment could cache sent selectors, too… pablo did an experiment with that.

Marcus 

How about a new SymbolTable "SelectorTable" that gets new entries on every method compilation ?

I hacked a simple experimental version.

But I don't yet understand the workflow for initialisation of the Symbol class (with rehash, interned, and compacting).

 

I tried some methods from TBehavior basicAddSelector:withMethod:

but for example Nautilus, directly modifies method dict

I hacked a simple experimental version.

But I don't yet understand the workflow for initialisation of the Symbol class (with rehash, interned, and compacting).

If we hook into adding methods, then compactSymbolTable and rehash could just reset the SelectorTable and fill it after by going over all methods… 

see attached changesets.

load with:

DangerousClassNotifier disableDuring:[
    String subclass: #Symbol
    instanceVariableNames: ''
    classVariableNames: 'NewSymbols OneCharacterSymbols SymbolTable SelectorTable'
    package: 'Collections-Strings'
    ].

DangerousClassNotifier disableDuring:[
'selectortable.1.cs'
asFileReference fileIn.
    ].
Symbol initSelectorTable.
'use_selector_table.cs' asFileReference fileIn.

what do you think ?

(selectortable.cs defines SelectorTable and some methods in Symbol and String)

(use_selector_table adds selectors as internedSelectorSymbol if this

selector is set as a selector on CompiledMethod

and uses findInternedSelector .... in RubStyler visitMessageNode)

 

Marcus