February 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] The evil twin in 40516

by stepharo

> Sooner or later then you will have to name people, because talking > generally wont change the situation. > > Who in this community believe that improving Pharo is pointless / does > not have an effect ? marcus is not mentioning people in this community but outside. > > I am getting totally opposite feeling with this community. One the > reasons I enjoy Pharo. Me too. And the infrastructure is getting really really great. To be point that I cannot see what the people will do with it. So this is great, > > On Fri, Feb 27, 2015 at 2:34 PM, Marcus Denker <marcus.denker(a)inria.fr > <mailto:marcus.denker@inria.fr>> wrote: > > >> On 27 Feb 2015, at 13:24, kilon alios <kilon.alios(a)gmail.com >> <mailto:kilon.alios@gmail.com>> wrote: >> >> I can explain why, its the language you use. >> >> For example this feature, I have no clue what you guys are >> talking about. >> >> For people to be impressed first they need to understand what >> they should be impressed with. >> > I did not mean this feature. I mean the abstract concept of > improvement having an effect. > >> On Fri, Feb 27, 2015 at 2:12 PM, Marcus Denker >> <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> >> >> On Fri, Feb 27, 2015 at 12:35 PM, Tudor Girba >> <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: >> >> So many cool things! >> >> We cannot even imagine at this point what all these >> little conceptual things will bring in downstream >> projects. This is amazing. >> >> >> Interestingly, the world view of most people is different... >> they never realise this, they seem to fundamentally not see this >> connection. I have not yet found out why... >> >> Marcus >> >> > >

Feb. 27, 2015

Re: [Pharo-dev] The evil twin in 40516

by stepharo

in essence we can annotate an AST and the annotations can become live at runtime and can also represents the computation itself. So you can have objects that represent properties of the execution itself and change the execution or something like that :). So with that we can for example build better debugger, profilers, Le 27/2/15 13:24, kilon alios a Ã©crit : > I can explain why, its the language you use. > > For example this feature, I have no clue what you guys are talking about. > > For people to be impressed first they need to understand what they > should be impressed with. > > On Fri, Feb 27, 2015 at 2:12 PM, Marcus Denker <marcus.denker(a)inria.fr > <mailto:marcus.denker@inria.fr>> wrote: > > > > On Fri, Feb 27, 2015 at 12:35 PM, Tudor Girba > <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: > > So many cool things! > > We cannot even imagine at this point what all these little > conceptual things will bring in downstream projects. This is > amazing. > > > Interestingly, the world view of most people is different... they > never realise this, they seem to fundamentally not see this > connection. I have not yet found out why... > > Marcus > >

Feb. 27, 2015

Re: [Pharo-dev] The evil twin in 40516

by stepharo

Thanks clara. Le 27/2/15 14:24, Clara Allende a Ã©crit : > Great news! I'll get in touch with you and see how I can help :) > > 2015-02-27 10:16 GMT-03:00 Marcus Denker <marcus.denker(a)inria.fr > <mailto:marcus.denker@inria.fr>>: > > > > On 27 Feb 2015, at 13:59, Clara Allende <clari.allende(a)gmail.com > <mailto:clari.allende@gmail.com>> wrote: > > > > Looks super cool :) Now that I finished my exams I can get back > on this too... > > Very good! > > The idea is to step-by-step take your prototype and move it over. > > Next I will do the link-setting infrastructure: > - set a link on the AST -> create twin/invalidate > - remove last link -> twin disappears. > > > For the AST transformer I want to build a tiny Plugin-Architecture > for Opal > (which then people can use for more crazy experiments, too). > > > Yay! I love this :) > > > Marcus > > >

Feb. 27, 2015

Re: [Pharo-dev] The evil twin in 40516

by stepharo

> So many cool things! > > We cannot even imagine at this point what all these little conceptual > things will bring in downstream projects. This is amazing. well there are large conceptual things made looking like little conceptual things :) This is the trick but yes we know were we go and I love it. > > Thanks a lot, > Doru > > > On Fri, Feb 27, 2015 at 12:07 AM, Marcus Denker > <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > > Hi, > > In 40516 there is now a strange, but rather powerful mechanism for > CompiledMethod: the Twin. > > What does that do? > > you can call on a method #createTwin > > (ReflectivityExamples>>#exampleMethod) createTwin. > > after this, the CompiledMethod has a high-level representation > (the AST) attached that itself references the CompiledMethod > (they form a twin). > > (ReflectivityExamples>>#exampleMethod) reflectiveMethod > > The fun thing is now that one can install either in the class. > Call #invalidate to make sure the reflective method is installed. > > ReflectiveMethod implements #run:with:in: which calls a > compilation hook (too re-create from the AST) and then installs > that in the > method dict and then executes the method: > > (ReflectivityExamples>>#exampleMethod) createTwin. > (ReflectivityExamples>>#exampleMethod) invalidate. > self assert: (ReflectivityExamples>>#exampleMethod) class > = ReflectiveMethod. > self assert: ReflectivityExamples new exampleMethod = 5. > self assert: (ReflectivityExamples>>#exampleMethod) class > = CompiledMethod. > > Which means that this gives us an in-image, on-demand JIT compiler > AST->Bytecode. In 50 lines of code. > > e.g. try on Morph: > > Morph methods do: #createTwin. > Morph methods do: #invalidate. > > Counting which twin is installed shows us the working set of Morph: > > (Morph methods select: [ :each | each class = CompiledMethod ]) size > > some 330 method out of nearly 900â¦. > > So what can one do with this? In essence this turns the AST into a > reflective representation for Methods > (if you care to set up twin creation + invalidation correctly). > > What will this allow us to do? stay tuned... > > Marcus > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Feb. 27, 2015

Re: [Pharo-dev] Issue Grabber

by Marcus Denker

> On 27 Feb 2015, at 16:05, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 27 Feb 2015, at 16:00, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >> >> >>> On 27 Feb 2015, at 15:55, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>> >>> >>>> On 27 Feb 2015, at 15:53, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >>>> >>>> It seems the following now fails, both in older and newer images: >>>> >>>> ZnClient new url: 'http://bugs.pharo.org/issues/name/15008' <http://bugs.pharo.org/issues/name/15008'>; get. >>>> >>>> Which means 'Grab' of an issue number in MCSliceMaker no longer works. >>>> >>>> What changed ? >>>> >>>> >>> >>> It seems to be a change at fogbugz? In the browser it says: >>> >>> Entry point not found >>> The FogBugz page "/issues/name/15008'" was not found >> >> OK, but there must also be some proxy from us in between, no ? >> Because @ fogbugz there is no public API. >> > > ahhâ¦ it uses bugs.pharo.org <http://bugs.pharo.org/> which I made to point to fog bugs (as it is > unmaintained and out of date). > > I will for now re-enable it. I swtiched the DNS back. bugs.pharo.org <http://bugs.pharo.org/> should not forward anymore (can take a while till DNS is propagated) Marcus

Feb. 27, 2015

Re: [Pharo-dev] The evil twin in 40516

by stepharo

I hope that we will get better profilers alex :) Le 27/2/15 00:15, Alexandre Bergel a Ã©crit : > Wow!!! > This means that one can call #createTwin, modify the AST, and simply call it! > Impressive!!! > Is it per default in Pharo 40516? > > Alexandre > > >> On Feb 26, 2015, at 8:07 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Hi, >> >> In 40516 there is now a strange, but rather powerful mechanism for CompiledMethod: the Twin. >> >> What does that do? >> >> you can call on a method #createTwin >> >> (ReflectivityExamples>>#exampleMethod) createTwin. >> >> after this, the CompiledMethod has a high-level representation (the AST) attached that itself references the CompiledMethod >> (they form a twin). >> >> (ReflectivityExamples>>#exampleMethod) reflectiveMethod >> >> The fun thing is now that one can install either in the class. Call #invalidate to make sure the reflective method is installed. >> >> ReflectiveMethod implements #run:with:in: which calls a compilation hook (too re-create from the AST) and then installs that in the >> method dict and then executes the method: >> >> (ReflectivityExamples>>#exampleMethod) createTwin. >> (ReflectivityExamples>>#exampleMethod) invalidate. >> self assert: (ReflectivityExamples>>#exampleMethod) class = ReflectiveMethod. >> self assert: ReflectivityExamples new exampleMethod = 5. >> self assert: (ReflectivityExamples>>#exampleMethod) class = CompiledMethod. >> >> Which means that this gives us an in-image, on-demand JIT compiler AST->Bytecode. In 50 lines of code. >> >> e.g. try on Morph: >> >> Morph methods do: #createTwin. >> Morph methods do: #invalidate. >> >> Counting which twin is installed shows us the working set of Morph: >> >> (Morph methods select: [ :each | each class = CompiledMethod ]) size >> >> some 330 method out of nearly 900â¦. >> >> So what can one do with this? In essence this turns the AST into a reflective representation for Methods >> (if you care to set up twin creation + invalidation correctly). >> >> What will this allow us to do? stay tuned... >> >> Marcus >> >> >>

Feb. 27, 2015

Re: [Pharo-dev] The evil twin in 40516

by stepharo

:) pay attention I have a lot of ideas for you to implement :) Stef Le 27/2/15 00:07, Marcus Denker a Ã©crit : > Hi, > > In 40516 there is now a strange, but rather powerful mechanism for CompiledMethod: the Twin. > > What does that do? > > you can call on a method #createTwin > > (ReflectivityExamples>>#exampleMethod) createTwin. > > after this, the CompiledMethod has a high-level representation (the AST) attached that itself references the CompiledMethod > (they form a twin). > > (ReflectivityExamples>>#exampleMethod) reflectiveMethod > > The fun thing is now that one can install either in the class. Call #invalidate to make sure the reflective method is installed. > > ReflectiveMethod implements #run:with:in: which calls a compilation hook (too re-create from the AST) and then installs that in the > method dict and then executes the method: > > (ReflectivityExamples>>#exampleMethod) createTwin. > (ReflectivityExamples>>#exampleMethod) invalidate. > self assert: (ReflectivityExamples>>#exampleMethod) class = ReflectiveMethod. > self assert: ReflectivityExamples new exampleMethod = 5. > self assert: (ReflectivityExamples>>#exampleMethod) class = CompiledMethod. > > Which means that this gives us an in-image, on-demand JIT compiler AST->Bytecode. In 50 lines of code. > > e.g. try on Morph: > > Morph methods do: #createTwin. > Morph methods do: #invalidate. > > Counting which twin is installed shows us the working set of Morph: > > (Morph methods select: [ :each | each class = CompiledMethod ]) size > > some 330 method out of nearly 900â¦. > > So what can one do with this? In essence this turns the AST into a reflective representation for Methods > (if you care to set up twin creation + invalidation correctly). > > What will this allow us to do? stay tuned... > > Marcus > > >

Feb. 27, 2015

Re: [Pharo-dev] [Metacello] Getting all working copies from a configuration

by Sean P. DeNigris

Guillermo Polito wrote > I know that I can do a #record to get the list of specs of a particular > version. I'm not sure I understand... How does your use case differ from what #record provides? What has always worked for me is "(ConfigurationOfXXX project version: #'1.0') record loadDirective" ----- Cheers, Sean -- View this message in context: http://forum.world.st/Metacello-Getting-all-working-copies-from-a-configura… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 27, 2015

About slots and syntax

by stepharo

Hi guys I was reading the definitions we sent around and I have some questions about => Object subclass: #TestLocal slots: { #local => ProcessLocalSlot } classVariables: { } category: 'SlotTestGuille'. Object subclass: #TestLocal2 slots: { #local => ProcessLocalSlot default: 5} classVariables: { } category: 'SlotTestGuille'. Are we sure that we want to use that => I thought about = but this is not an assignement this is a declaration and normally we use | for declaration. So what would be other alternatives before the world use => Then I still do not understand why we have empty classVariables: to me it does not make sense. I do not get why we like to have empty collections for the sake of having empty collections. We are trapped in some strange ways of thinking. Object subclass: #TestLocal slots: { #local => ProcessLocalSlot } classVariables: { } category: 'SlotTestGuille'. => Object subclass: #TestLocal slots: { #local => ProcessLocalSlot } package: 'SlotTestGuille'.

Feb. 27, 2015

Re: [Pharo-dev] [Pharo4] Slots: ExampleSlotWithDefaultValue

by Sean P. DeNigris

stepharo wrote > I have the impression that literals are better because no runtime needed. Except it eliminates a common-sounding case like: Object subclass: #GG slots: { #creationTimestamp => ExampleSlotWithDefaultValue default: DateAndTime now } classVariables: { } category: âPlayGround' ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo4-Slots-ExampleSlotWithDefaultValue-tp4807635p48… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 27, 2015