Issue 4295 in pharo: Do not use the bytecode for #class.

Status: Accepted
Owner: [hidden email]
CC: marianopeck
Labels: Milestone-1.4

New issue 4295 by [hidden email]: Do not use the bytecode for #class.
http://code.google.com/p/pharo/issues/detail?id=4295

We should remove the special bytecode for #class.

This way we can do proxies, futures and things like that much easier...

(CC: Mariano)


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #1 on issue 4295 by marianopeck: Do not use the bytecode for #class.
http://code.google.com/p/pharo/issues/detail?id=4295

Agree.

        (ParseNode classVarNamed:  'StdSelectors') removeKey: #class ifAbsent: [].
        Compiler recompileAll.

The loose in performance I could measure is about 4%

       


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #2 on issue 4295 by [hidden email]: Do not use the bytecode  
for #class.
http://code.google.com/p/pharo/issues/detail?id=4295

But when you recreate the specialObjectsArray, StdSelectors will be  
re-inialized...


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #3 on issue 4295 by marianopeck: Do not use the bytecode for #class.
http://code.google.com/p/pharo/issues/detail?id=4295

There is a deeper problem and it is that #recreateSpecialObjectsArray does  
NOT use the (ParseNode classVarNamed:  'StdSelectors'). So, it duplicates  
the informations:


        newArray at: 24 put: #( #+ 1 #- 1 #< 1 #> 1 #<= 1 #>= 1 #= 1 #~= 1
                                                        #* 1 #/ 1 #\\ 1 #@ 1 #bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1
                                                        #at: 1 #at:put: 2 #size 0 #next 0 #nextPut: 1 #atEnd 0 #== 1 #class 0
                                                        #blockCopy: 1 #value 0 #value: 1 #do: 1 #new 0 #new: 1 #x 0 #y 0 ).


So....you neeed to change in both places?

Maybe we can change VariableNode >> initialize  ?



_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #4 on issue 4295 by [hidden email]: Do not use the bytecode  
for #class.
http://code.google.com/p/pharo/issues/detail?id=4295

no, VariableNode>>#initialize gets the data from the SpecialObjectArray.

So: remove it theore, call VariableNode initialize.

I will do that.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #5 on issue 4295 by [hidden email]: Do not use the bytecode  
for #class.
http://code.google.com/p/pharo/issues/detail?id=4295

Hmm... the image freezes when I change the specialObjectsArray. I am sure I  
did that in the past.. (StackVM I use)


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #6 on issue 4295 by marianopeck: Do not use the bytecode for #class.
http://code.google.com/p/pharo/issues/detail?id=4295

Marcus, in Marea I do:

        (ParseNode classVarNamed:  'StdSelectors') removeKey: #class ifAbsent: [].
        Compiler recompileAll.
       


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #7 on issue 4295 by [hidden email]: Do not use the bytecode  
for #class.
http://code.google.com/p/pharo/issues/detail?id=4295

yes, and then do


VariableNode initialize

what happens?




_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #8 on issue 4295 by marianopeck: Do not use the bytecode for #class.
http://code.google.com/p/pharo/issues/detail?id=4295

nothing bad happens.
I can perfectly do


(ParseNode classVarNamed:  'StdSelectors') removeKey: #class ifAbsent: [].
  Compiler recompileAll.
VariableNode initialize.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: FixProposed

Comment #9 on issue 4295 by [hidden email]: Do not use the bytecode  
for #class.
http://code.google.com/p/pharo/issues/detail?id=4295

But after VariableNode initialize, ParseNode classVarNamed:  'StdSelectors'  
has again the key for #class.

Attached is a cs that works (it does not delete #class but replaces it in  
nil in the list so that the offers do
not change.

File in, do Smalltalk recreateSpecialObjectsArray, than VariableNode  
initialize, then recompile the image.

Attachments:
        SpecialOb.2.cs  5.2 KB


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: Closed

Comment #10 on issue 4295 by [hidden email]: Do not use the bytecode  
for #class.
http://code.google.com/p/pharo/issues/detail?id=4295

in 14132


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker