Hi In the past in Pharo when a message was not matching an existing selector the selector was turned into red 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
2016-01-15 13:10 GMT+01:00 stepharo <stepharo@free.fr>:
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. 2016-01-15 13:28 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-01-15 13:10 GMT+01:00 stepharo <stepharo@free.fr>:
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
2016-01-15 13:33 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
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 <nicolaihess@gmail.com>:
2016-01-15 13:10 GMT+01:00 stepharo <stepharo@free.fr>:
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.
Argh this is a pity because this is a really useful
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.
Yes I was discussing with students that used Pharo 40 during a lecture and they loved it.
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) Stef
2016-01-15 13:10 GMT+01:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
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
On 15 Jan 2016, at 20:38, stepharo <stepharo@free.fr> wrote:
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.
Argh this is a pity because this is a really useful
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.
Yes I was discussing with students that used Pharo 40 during a lecture and they loved it.
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)
'selectors' is a misleading name I think, but your definition is OK: 'selectors installed in method dictionaries'. I had already noticed that sometimes in completion you get suggestions like p pr pri prin print which is probably related. Just because someone somewhere defines a symbol (that might become garbage soon), does not yet make it a valid selector. But how fix this in an efficient way ?
Stef
2016-01-15 13:10 GMT+01:00 stepharo <stepharo@free.fr>:
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
How can we proceed? Because this coloring functionality is really important. 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
and so is auto completion ;) On Sat, Jan 16, 2016 at 1:03 PM stepharo <stepharo@free.fr> wrote:
How can we proceed? Because this coloring functionality is really important.
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 <marcus.denker@inria.fr>:
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).
On 16 Jan 2016, at 13:26, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-01-16 10:11 GMT+01:00 Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>>:
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 ?
maybe better when a method is added to a Method Dictionary? This way even adding things the strange way would work...
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⦠Marcus
2016-01-16 13:46 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
On 16 Jan 2016, at 13:26, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-01-16 10:11 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
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 ?
maybe better when a method is added to a Method Dictionary? This way even adding things the strange way would work...
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
I tried some methods from TBehavior basicAddSelector:withMethod: but for example Nautilus, directly modifies method dict Where? we should fix it.
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.
I will have a look. I know that andres valloud implemented a better SymbolTable but he never released it open-source.
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
I did not forget just running against time and busy Le 16/1/16 22:17, Nicolai Hess a écrit :
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)
2016-01-24 21:38 GMT+01:00 stepharo <stepharo@free.fr>:
I did not forget just running against time and busy
Le 16/1/16 22:17, Nicolai Hess a écrit :
Another possible solution, don't convert strings to symbols in RBMethod/RBMessagenodes selectorParts ^ self keywords collect: #asSymbol. selector: aSelector keywordsPositions := nil. selector := aSelector asSymbol.
this of course needs some changes for the compiler to actually create methoddictionary keys and literals for message send by conferting them explicit to symobls. There are suprisingly few places to modify. But the same has to be done for accesses in RBRefactoring classes too. And this is not as easy to change as for the compiler :(
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)
Hi Nicolai. Now your proposals in slice 17496 <https://pharo.fogbugz.com/f/cases/17496/add-table-for-all-defined-method-sel...> . We change it a little bit: we make SelectorsTable lazy. And code completion uses it too. 2016-01-16 22:17 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-01-16 13:46 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
On 16 Jan 2016, at 13:26, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-01-16 10:11 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
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 ?
maybe better when a method is added to a Method Dictionary? This way even adding things the strange way would work...
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
2016-01-29 13:10 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com>:
Hi Nicolai. Now your proposals in slice 17496 <https://pharo.fogbugz.com/f/cases/17496/add-table-for-all-defined-method-sel...> . We change it a little bit: we make SelectorsTable lazy. And code completion uses it too.
+1, Let's see if it works :) Thanks
2016-01-16 22:17 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-01-16 13:46 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
On 16 Jan 2016, at 13:26, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-01-16 10:11 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
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 ?
maybe better when a method is added to a Method Dictionary? This way even adding things the strange way would work...
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
And it is in 50556 2016-01-29 13:39 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-01-29 13:10 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com>:
Hi Nicolai. Now your proposals in slice 17496 <https://pharo.fogbugz.com/f/cases/17496/add-table-for-all-defined-method-sel...> . We change it a little bit: we make SelectorsTable lazy. And code completion uses it too.
+1,
Let's see if it works :) Thanks
2016-01-16 22:17 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-01-16 13:46 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
On 16 Jan 2016, at 13:26, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-01-16 10:11 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
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 ?
maybe better when a method is added to a Method Dictionary? This way even adding things the strange way would work...
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
This is supercool that you propose a working solution. I'm going over the Mooc exercises (text version first to get redy to shoot the videos). Stef Le 16/1/16 13:26, Nicolai Hess a écrit :
2016-01-16 10:11 GMT+01:00 Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>>:
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).
Hi, Indeed. Thanks. Could you pass your sketch around? Maybe someone else can jump in. Cheers, Doru
On Jan 17, 2016, at 9:49 AM, stepharo <stepharo@free.fr> wrote:
This is supercool that you propose a working solution. I'm going over the Mooc exercises (text version first to get redy to shoot the videos).
Stef
Le 16/1/16 13:26, Nicolai Hess a écrit :
2016-01-16 10:11 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
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).
-- www.tudorgirba.com www.feenk.com "There are no old things, there are only old ways of looking at them."
2016-01-17 9:55 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
Indeed. Thanks.
Could you pass your sketch around? Maybe someone else can jump in.
Just look at the attachement and load instruction in http://forum.world.st/Color-yzw-tp4871486p4871899.html It seems to work, but this is just a first try. Please review and give feedback.
Cheers, Doru
On Jan 17, 2016, at 9:49 AM, stepharo <stepharo@free.fr> wrote:
This is supercool that you propose a working solution. I'm going over the Mooc exercises (text version first to get redy to shoot the videos).
Stef
Le 16/1/16 13:26, Nicolai Hess a écrit :
2016-01-16 10:11 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
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).
-- www.tudorgirba.com www.feenk.com
"There are no old things, there are only old ways of looking at them."
participants (7)
-
Denis Kudriashov -
Dimitris Chloupis -
Marcus Denker -
Nicolai Hess -
stepharo -
Sven Van Caekenberghe -
Tudor Girba