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

Re: [Pharo-dev] [Pharo4] Slots can now be saved with MC

by stepharo

>> We would love. >> With Epicea we have Changes representing not only class and instance addition/removal... >> Now the question is also how do we initialize such new added instance variable. > That's easy if the slot definition has an initialiser. > >> Now we have probably to recompile the full class hierarchy. > I don't see a way if avoiding this unless we move to a self/newspeak model of inst var accessor. But it can be made much faster than recompiling from source. The idea is simply to disassemble every method from bytecode to an assembler level representation (such as Marcus' byte surgeon or my method massage), adjust offsets and regenerate. > > This is what VisualWorks does and it is /much/ faster than recompiling from source. Yes we should do that. >> We are brainstorming on a modular way to initialize objects >> What are the paths to achieve that in a clever way. > Yes the monolithic initialize method is an issue if one wants to be able to add inst vars individually. Lazy initialize toon in accessors is one way. That works well for eg inst vars used to implement caches (although now flushing becomes an issue). There's no such thing as a free lunch :-) I know :) Damien was working on a incremental initialization model with marco >

Jan. 16, 2015

Re: [Pharo-dev] [Pharo4] Slots can now be saved with MC

by Ben Coman

do you mean...? https://hal.inria.fr/hal-00641716/file/Verw11b-OOSPLA11-FlexibleObjectLayou… On Fri, Jan 16, 2015 at 8:02 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Maybe it wasnât a blog post - but I definitely recall reading something > last year that introduced the idea and showed some sample code (it wasnât a > pdf). I thought it was really handy, and wanted to go back a read it in the > context of this thread. > > Tim > > On 15 Jan 2015, at 18:04, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > >> On 15 Jan 2015, at 13:04, Tim Mackinnon <tim(a)testit.works> wrote: > >> > >> Marcus, can you remind us where that Blog post you wrote about using > slots is? A google search of âPharo Smalltalk slotsâ doesnât seem to find > it, and I remember it being a great intro to what is possible. > >> > >> (Itâs worth considering tagging that post better - it should come up > much higher in google search results). > >> > > > > There is no blog post yetâ¦ I want to actually have it finished, else I > would write a post about something not workingâ¦ which would be > > hard. > > > > Marcus > > > >> Tim > >> > >> On 12 Jan 2015, at 14:59, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> > >>> > >>>> On 11 Jan 2015, at 18:50, Chris Muller <asqueaker(a)gmail.com> wrote: > >>>> > >>>> It has been a while since I read the paper, but my memory is that > >>>> Slots lets you define features and/or constraints on inst-var's. For > >>>> example, assigning default values or restricting the set of valid > >>>> values. > >>>> > >>>> This would probably be appealing for folks coming from languages like > >>>> Java or C++, because they're used to all of their "slots" being > >>>> statically typed. It does seem ironic that where those static > >>>> languages have been trying to move toward being more dynamic, Pharo > >>>> newbies would find themselves arrived at a language which is trying to > >>>> make something that was purely dynamic into something more static. > >>>> > >>> > >>> It is *possible* to implement a kind of TypedSlot, but I do not think > that > >>> this is what people will use Slots for. And for sure there will be no > TypeSlot > >>> by default in Pharo. > >>> > >>> For Slots there are two levels > >>> > >>> 1) having objects that describe variables instead of strings. This is > very powerful > >>> already and will allow us to e.g. do watchpoints/breakpoitns in > variables very easily > >>> > >>> This is already in Pharo3, but Pharo4 enhances the API and provides > with the LinkWrapper > >>> slot a way to transparently hook into variable access. This will be > very powerful. > >>> > >>> 2) provide a way to declare that a slot is described by a special > subclass of Slot. This is what this > >>> change is about > >>> > >>> This is what we use Slots for are three directions: > >>> > >>> 1) active slots that announce when the are set. Replacing the whole > ValueHolder stuf to some extend. > >>> (This is where Slots + their Meta Object Protocol allow one to > implement the special variables in Tweak > >>> very easily. It is interesting that there, one had to copy the whole > compiler and do many, many hacks. > >>> > >>> 2) Allow optimizing memory representation. E.g. look at Morph. Many > flags are needed, but each takes a > >>> whole pinter to true of false. So we have MorphExtension. And then on > top of that a property dictionary. > >>> With Slots, flags (sots that can only store true or false) can be > realised very efficiently (31 boolean slots > >>> of the hierarchy map to one ivar). With a PropertySlot, one can have > values that are used seldomely > >>> encoded in a way that they take no space. > >>> > >>> 3) Slots + Magritte. Magritte now relies of conventions and methods > added to the class side. But what it > >>> is: meta descriptions for ivars. I think there will be something very > powerful in combining Magritte and Slots. > >>> > >>> 4) Experiments. One way to see Pharo is that it is suppose to be > flexible enough to allow experiments > >>> to be done fast and easy so we can explore many ideas easily. > >>> These experiments will often be just that: experiments. But some of > them will be so good that they will > >>> turn out to be useful. > >>> > >>>> My understanding is that specifying a certain Slot-type can save the > >>>> need to write, i.e., initializing or validating methods. In exchange, > >>>> the number of concepts inherent in the language that must be learned > >>>> and remembered is increased. Standard Smalltalk is only about 2 or 3 > >>>> concepts -- sending messages and assigning pointers. Period. There's > >>>> something exciting about that because even Grandma can grok 2 or 3 > >>>> concepts. No other language is so simple. > >>>> > >>> Slots do not really increase the concepts: they just are meta objects > that have the > >>> definition of the behaviour of assignment, turning assignment into > message sends. > >>> > >>>> By introducing the implicit behaviors of slots, the number of > >>>> different conceptual interactions between code and the slots it > >>>> references increases exponentially with the number of slot-types. I > >>>> fear trying to explain them to Grandma will have her eyes starting to > >>>> glazeâ¦ > >>>> > >>> I do not see now an active slot is harder to understand than e.g. a > ValueHolder. > >>> or a BooleanSlot should be easier to understand than doing all that > explicitely? > >>> > >>> > >>> Marcus > >>> > >>> > >> > >> > > > > > > >

Jan. 16, 2015

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

by Marcus Denker

> On 16 Jan 2015, at 11:28, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Hi Marcus, > > So now ' self class allSlots ' should be used also in the debugger to get the instance variables of an object? > Yes, at least for nowâ¦ I am not yet that happy with the namingâ¦ it is hard to get consistent *and* be resably compatibleâ¦. So the idea is that the old API for (instVarAt:, instVarNamesâ¦) continues to work *but* this shows (and manipulates) what is really there. VM level instance variables. Slots are first class instance variables that a) might redefine what happens of read/write â> all reflective read and write needs to go through the slots. b) they often correspond 1:1 to a low level ivar, but they donât have to (e.g. the TestSlot in the example has no underlying ivar) â> we need to ask for all Slots, not just all instVarNames. For the namingâ¦ in some way Slots are just âFirst Class Instance Variablesâ that map to VM level Fields. Sometimes I feel it would be nice to use just these two for naming: Fields (VM Level) and Instance Variables (Image level, aka Slots). But then, there is backward compatibility to be taken into accountâ¦ we canât really change instVarAt:â¦ but we could of course keep those for legacy and use the âlong formâ for the âreifiedâ instance variables: instanceVariableNamed:, #instanceVariableNames, and so onâ¦ To make it really consistent and just use âField and Ivar", there would be a lot to be changed: names of byte codes, for example. So maybe having it like it is now is good? âField and Ivarâ are one concept, while the high-level one is âSlotâ. I am not sure myselfâ¦ I have to admit. Marcus

Jan. 16, 2015

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

by Tudor Girba

I guess so. Doru On Fri, Jan 16, 2015 at 3:28 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Hi Marcus, > > So now ' self class allSlots ' should be used also in the debugger to get > the instance variables of an object? > > > Cheers, > Andrei > > On Fri, Jan 16, 2015 at 2:59 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> Hi, >> >> Now GTInspector can inspect objects that use custom Slot definitions. >> >> >> https://pharo.fogbugz.com/f/cases/14741/GTInspector-add-simple-slot-support >> >> create a class with he TestSlot (where the ivar lives in the Slot >> instance and is thus shared >> over all instances of A): >> >> Object subclass: #A >> slots: { #iv => TestSlot } >> classVariables: { } >> category: âPlayground' >> >> >> Inspect >> >> A new >> >> change âivâ to value (e.g. 5). >> >> inspect another "A newâ >> >> ==> it should show the value as 5. >> >> Thus both reading and writing now is done via the Slot. (as such this >> require just a very simple change in GT, of course). >> >> The GT support of course needs to be improved later: >> >> -> we need a view that shows the object âas it really isâ (keep in mind, >> this object has no VM level instance variable!). >> -> In the view with the slots they should annotated so we see that it is >> a slot and can easily navigate to the slot definition >> -> â¦ I am sure more will be obvious as soon as we use it. >> >> Marcus >> > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 16, 2015

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

by Andrei Chis

Hi Marcus, So now ' self class allSlots ' should be used also in the debugger to get the instance variables of an object? Cheers, Andrei On Fri, Jan 16, 2015 at 2:59 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > Now GTInspector can inspect objects that use custom Slot definitions. > > https://pharo.fogbugz.com/f/cases/14741/GTInspector-add-simple-slot-support > > create a class with he TestSlot (where the ivar lives in the Slot instance > and is thus shared > over all instances of A): > > Object subclass: #A > slots: { #iv => TestSlot } > classVariables: { } > category: âPlayground' > > > Inspect > > A new > > change âivâ to value (e.g. 5). > > inspect another "A newâ > > ==> it should show the value as 5. > > Thus both reading and writing now is done via the Slot. (as such this > require just a very simple change in GT, of course). > > The GT support of course needs to be improved later: > > -> we need a view that shows the object âas it really isâ (keep in mind, > this object has no VM level instance variable!). > -> In the view with the slots they should annotated so we see that it is a > slot and can easily navigate to the slot definition > -> â¦ I am sure more will be obvious as soon as we use it. > > Marcus >

Jan. 16, 2015

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

by Alexandre Bergel

Excellent! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jan 16, 2015, at 10:59 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > Now GTInspector can inspect objects that use custom Slot definitions. > > https://pharo.fogbugz.com/f/cases/14741/GTInspector-add-simple-slot-support <https://pharo.fogbugz.com/f/cases/14741/GTInspector-add-simple-slot-support> > > create a class with he TestSlot (where the ivar lives in the Slot instance and is thus shared > over all instances of A): > > Object subclass: #A > slots: { #iv => TestSlot } > classVariables: { } > category: âPlayground' > > > Inspect > > A new > > change âivâ to value (e.g. 5). > > inspect another "A newâ > > ==> it should show the value as 5. > > Thus both reading and writing now is done via the Slot. (as such this require just a very simple change in GT, of course). > > The GT support of course needs to be improved later: > > -> we need a view that shows the object âas it really isâ (keep in mind, this object has no VM level instance variable!). > -> In the view with the slots they should annotated so we see that it is a slot and can easily navigate to the slot definition > -> â¦ I am sure more will be obvious as soon as we use it. > > Marcus

Jan. 16, 2015

Re: [Pharo-dev] [ANN] Pharo Consortium New Academic Partner: Ecole des Mines de Douai

by Ben Coman

great to hear. cheers -ben On Fri, Jan 16, 2015 at 6:23 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > The Pharo Consortium is very happy to announce that the Ecole des Mines de > Douai has joined the Consortium as an Academic Partner. > > About > > - Ecole des Mines de Douai: http://www.mines-douai.fr > - Ecole des Mines de Douai, IA: http://ia.mines-douai.fr > - Pharo Consortium: http://consortium.pharo.org > > The goal of the Pharo Consortium is to allow companies and institutions to > support the ongoing development and future of Pharo. > Individuals can support Pharo via the Pharo Association: > http://association.pharo.org >

Jan. 16, 2015

[Pharo4] Slots: GTInspector support

by Marcus Denker

Hi, Now GTInspector can inspect objects that use custom Slot definitions. https://pharo.fogbugz.com/f/cases/14741/GTInspector-add-simple-slot-support <https://pharo.fogbugz.com/f/cases/14741/GTInspector-add-simple-slot-support> create a class with he TestSlot (where the ivar lives in the Slot instance and is thus shared over all instances of A): Object subclass: #A slots: { #iv => TestSlot } classVariables: { } category: âPlayground' Inspect A new change âivâ to value (e.g. 5). inspect another "A newâ ==> it should show the value as 5. Thus both reading and writing now is done via the Slot. (as such this require just a very simple change in GT, of course). The GT support of course needs to be improved later: -> we need a view that shows the object âas it really isâ (keep in mind, this object has no VM level instance variable!). -> In the view with the slots they should annotated so we see that it is a slot and can easily navigate to the slot definition -> â¦ I am sure more will be obvious as soon as we use it. Marcus

Jan. 16, 2015

Re: [Pharo-dev] Any Deep Learning Algorithm related lib in Pharo ?

by Serge Stinckwich

Hi CÃ©drick, I dunno what is deep learning but looks like neural networks. I remember there was some library for NN in Squeak/Smalltalk that you might find with Google. You can help us develop machine learning algorithms for SciSmalltalk also. Regards, On Fri, Jan 16, 2015 at 12:05 PM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > Hi all, > > The question is in the title. Iâm just journeying in this field and was > wandering if it exists something on deep learning algorithms. > > Some refs > an introduction: > http://www.toptal.com/machine-learning/an-introduction-to-deep-learning-fro… > Python lib: > http://www.pyimagesearch.com/2014/09/22/getting-started-deep-learning-pytho… > http://deeplearning.net/tutorial/ > Java lib (link in the tutorial) > ... > > Cheers and best wishes all for 2015, > > CÃ©drick -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Jan. 16, 2015

Re: [Pharo-dev] [Pharo4] Slots can now be saved with MC

by Tim Mackinnon

Maybe it wasnât a blog post - but I definitely recall reading something last year that introduced the idea and showed some sample code (it wasnât a pdf). I thought it was really handy, and wanted to go back a read it in the context of this thread. Tim On 15 Jan 2015, at 18:04, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> On 15 Jan 2015, at 13:04, Tim Mackinnon <tim(a)testit.works> wrote: >> >> Marcus, can you remind us where that Blog post you wrote about using slots is? A google search of âPharo Smalltalk slotsâ doesnât seem to find it, and I remember it being a great intro to what is possible. >> >> (Itâs worth considering tagging that post better - it should come up much higher in google search results). >> > > There is no blog post yetâ¦ I want to actually have it finished, else I would write a post about something not workingâ¦ which would be > hard. > > Marcus > >> Tim >> >> On 12 Jan 2015, at 14:59, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>>> On 11 Jan 2015, at 18:50, Chris Muller <asqueaker(a)gmail.com> wrote: >>>> >>>> It has been a while since I read the paper, but my memory is that >>>> Slots lets you define features and/or constraints on inst-var's. For >>>> example, assigning default values or restricting the set of valid >>>> values. >>>> >>>> This would probably be appealing for folks coming from languages like >>>> Java or C++, because they're used to all of their "slots" being >>>> statically typed. It does seem ironic that where those static >>>> languages have been trying to move toward being more dynamic, Pharo >>>> newbies would find themselves arrived at a language which is trying to >>>> make something that was purely dynamic into something more static. >>>> >>> >>> It is *possible* to implement a kind of TypedSlot, but I do not think that >>> this is what people will use Slots for. And for sure there will be no TypeSlot >>> by default in Pharo. >>> >>> For Slots there are two levels >>> >>> 1) having objects that describe variables instead of strings. This is very powerful >>> already and will allow us to e.g. do watchpoints/breakpoitns in variables very easily >>> >>> This is already in Pharo3, but Pharo4 enhances the API and provides with the LinkWrapper >>> slot a way to transparently hook into variable access. This will be very powerful. >>> >>> 2) provide a way to declare that a slot is described by a special subclass of Slot. This is what this >>> change is about >>> >>> This is what we use Slots for are three directions: >>> >>> 1) active slots that announce when the are set. Replacing the whole ValueHolder stuf to some extend. >>> (This is where Slots + their Meta Object Protocol allow one to implement the special variables in Tweak >>> very easily. It is interesting that there, one had to copy the whole compiler and do many, many hacks. >>> >>> 2) Allow optimizing memory representation. E.g. look at Morph. Many flags are needed, but each takes a >>> whole pinter to true of false. So we have MorphExtension. And then on top of that a property dictionary. >>> With Slots, flags (sots that can only store true or false) can be realised very efficiently (31 boolean slots >>> of the hierarchy map to one ivar). With a PropertySlot, one can have values that are used seldomely >>> encoded in a way that they take no space. >>> >>> 3) Slots + Magritte. Magritte now relies of conventions and methods added to the class side. But what it >>> is: meta descriptions for ivars. I think there will be something very powerful in combining Magritte and Slots. >>> >>> 4) Experiments. One way to see Pharo is that it is suppose to be flexible enough to allow experiments >>> to be done fast and easy so we can explore many ideas easily. >>> These experiments will often be just that: experiments. But some of them will be so good that they will >>> turn out to be useful. >>> >>>> My understanding is that specifying a certain Slot-type can save the >>>> need to write, i.e., initializing or validating methods. In exchange, >>>> the number of concepts inherent in the language that must be learned >>>> and remembered is increased. Standard Smalltalk is only about 2 or 3 >>>> concepts -- sending messages and assigning pointers. Period. There's >>>> something exciting about that because even Grandma can grok 2 or 3 >>>> concepts. No other language is so simple. >>>> >>> Slots do not really increase the concepts: they just are meta objects that have the >>> definition of the behaviour of assignment, turning assignment into message sends. >>> >>>> By introducing the implicit behaviors of slots, the number of >>>> different conceptual interactions between code and the slots it >>>> references increases exponentially with the number of slot-types. I >>>> fear trying to explain them to Grandma will have her eyes starting to >>>> glazeâ¦ >>>> >>> I do not see now an active slot is harder to understand than e.g. a ValueHolder. >>> or a BooleanSlot should be easier to understand than doing all that explicitely? >>> >>> >>> Marcus >>> >>> >> >> > >

Jan. 16, 2015