You don't consider NB to be core ? Thierry ________________________________________ De : Pharo-dev [[email protected]] de la part de Stéphane Ducasse [[email protected]] Date d'envoi : samedi 6 juillet 2013 11:04 À : Pharo Development List Objet : Re: [Pharo-dev] NativeBoost with no access to sources
Now with Opal in and the API rationalisation we will get stable. I agree that we should avoid core code in external packages. Stef > Here is another quick and dirty recipe 4U: > > - make a extension method in CompiledMethod > > nbEnsureTempNames > > self propertyValueAt: #tempNames ifAbsent: [ > self propertyValueAt: #tempNames put: self tempNames > ] > > nbTempNames > ^ self propertyValueAt: #tempNames > > > NativeBoost class>>prepareForProduction > > CompiledMethod allInstancesDo: [:aMethod | > ((aMethod primitive = 117) and: [ | lit | lit := aMethod > literalAt: 1. > lit first = #NativeBoostPlugin and: [ lit second == > #primitiveNativeCall]]) ifTrue: [ > aMethod nbEnsureTempNames > ]. > ] > > (and then sure thing, make sure to use #nbTempNames instead of tempNames). > > but for the future, i want a clear protocol in CompiledMethod to do > that, and do not make it depend on system changes. > Because if i do, the stuff which works in 2.0 (or 3.0) will suddenly > stop working in next version, > because of changes in system.. that's why i against even thinking that > NB having something to do with method's source code. It needs method's > argument names, and nothing else, period. > > -- > Best regards, > Igor Stasenko. >
