March 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] How to easily intercept messages sent to ALL objects ?

by StÃ©phane Ducasse

> Now for message receive, one could imagine a partial reification scheme: a tag bit on the object header, if it is there, the VM calls a receive > method instead of the method that would originally be called. So you would pay, in all casses, one bit-check on message send *and* you need > space to put this flag. Would anyone want to pay that? > > Perhaps we can be cleverer. What could we do if we introduced delegation into the language? Then we can add wrappers around objects and put the interception into the wrappers. This way there is no additional check. If one wants to intercept references to an object one creates a DNU wrapper and becomes the two objects. > > An execution model of delegation is that there are two slots for the receiver in a context, a state slot through which inst vars are accessed, and a self slot to which messages are sent. Normal sends merely duplicate the receiver into both slots. Delegating sends take state as an additional argument. > > An alternative model is to dispense with direct inst var access (assuming the JIT will inline simple accessors in PICs, or simply by virtue of the use of machine code render accessors affordable) and provide accessors for delegators that indirect through the delegate. Eliot indeed this kind of schem looks interesting. I would love a system where we can really experiment with that kind of infrastructural changes that open a lot of new space. Stef

March 27, 2010

Re: [Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by Adrian Lienhard

On Mar 26, 2010, at 22:11 , laurent laffont wrote: [...] > Fun story: if you don't have SecurityPlugin, LocaleTest>>testFontFullName > deletes your image :) WTF?! That's exactly what happened to me some time ago. I lost a lot of images that were stored in the same folder like the image. Let's get rid of this test. I created issue http://code.google.com/p/pharo/issues/detail?id=2215 Adrian > testFontFullName > "self debug: #testFontFullName" > | env dir | > env := (Locale isoLanguage: 'ja') languageEnvironment. > dir := FileDirectory on: SecurityManager default untrustedUserDirectory. > [dir recursiveDelete] <-------------- Cool !! > on: Error > do: [:e | e]. > env fontFullName. > self assert: dir exists > > > Cheers, > > Laurent Laffont > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 27, 2010

[Pharo-project] [update 1.1] #11297

by Marcus Denker

11297 ----- Issue 2214: tests for shadowing Issue 2212: some refactoring related to Smalltalk globals Issue 2206: Rename JPEGReadWriter2 to PluginBasedJPEGReadWriter Issue 2166: MethodProperties pending tasks -- Marcus Denker -- marcus(a)2denker.de http://www.2denker.de 2denker UG (haftungsbeschrÃ¤nkt) Sitz KÃ¶ln Amtsgericht - Registergericht - KÃ¶ln, HRB 65065 GeschÃ¤ftsfÃ¼hrer: Christian Denker und Dr. Marcus Denker

March 27, 2010

Re: [Pharo-project] Hello squeakers

by Andreas Raab

Hi Stef - Thank you for your kind words. I'm glad that we all seem to be ready to leave the past behind us and move on into the future. I fully understand (and appreciate) your decision to fork Pharo and I have most definitely no objections to its direction and goals. Talking about goals, I think there's a lot of overlap here. We all want a small system, a cool system, a clean system, a fast system, an innovative system. So there is a good number of things where we could and should work together. And obviously, we all appreciate the numerous contributions to both Squeak and Pharo; neither system would be where it is without the contributions from the community. How a more effective sharing might look like is a bit open to me though. I spend most of last week thinking about what kind of setup could serve both projects (this is what delayed my reply in the other conversation) in a way that doesn't require either side to make unacceptable compromises but unfortunately I drew a blank here. It seems to me that neither Squeak nor Pharo are yet at a point where it could sensibly (i.e., without needlessly increasing the burden of the contributors) utilize a straightforward sharing mechanism. Any meaningful ideas would be welcome. Perhaps a better way to go about it might be to identify important non-core packages that we both intend to support and convince their maintainers to keep an open and inclusive attitude. For example, having Filesystem and Xtreams available in both projects might be a good start. Other than that, let me remind you that Squeak has an open contribution process and that many Pharo developers, including you, Markus, Adrian, Michael, Lukas and many more have been invited to be part of the core-developers group of Squeak. All of you received an invitation to participate and improve Squeak when the trunk was initiated. The invitation is still open. Cheers, - Andreas On 3/26/2010 4:17 AM, stephane ducasse wrote: > Dear Squeakers > > I want to send you a message because I estimate Squeakers and I want to open the door to see how new relationship can be build. > So consider that as an open hand - even if my english may let you think otherwise. > > First, Pharo is not against Squeak. We forked because we believed that we could not make Squeak move in any coherent direction. We are sure > that you understand our reasons. Just think a moment about the amount of time and energy we invested in Squeak in the > past (I wrote more than anybody else books on squeak, build tutorials, lecture support, videos....- with esug over the years we spent more than > 30 kEuros in Squeak related actions) so deciding to go for Pharo was not an easy choice but a necessary one: At one point I was thinking to quit > Smalltalk and go to see Ruby and Python for real. Pharo is the only way that I get back my fun in Smalltalk. > > So what are my dreams? > > For Pharo > ====== > We want a clean, lean and fast Smalltalk. An implementation that makes other dynamic language jealous. > We want a place where we/you can innovate. We want people to be able to invent THEIR future. > We want a place where people can make money with it and build robust applications. > > Being able to experiment fast is important but for that the system should be clean, robust and flexible. > Having a platform for experimentation requires that the platform is not experimental. > > About innovation I mean in no order: > Support for multitouch screen, bootstrappable Smalltalk, immutability bit and its impact, ephemerons, > new module system?, first class instance variables, using traits for real (like in ruby where any class can be a model > without inheriting from model), VAT-like system?, event system like in AmbiantTalk?, > I put ? because some of these should be implemented assessed tested... and understood deeply. > > About clean > Clean network, clean event system, clean object kernel, better compiler (open - we got first class instance > variable with no runtime penalties in one afternoon). Clean class builder... > > Now enough about Pharo. http://www.pharo-project.org/ > > About Etoys > ======== > I love Etoys (we translated the book and did more presentations of etoys than most squeakers) but I do not like its implementation. > Why? Because it is bad. Any body that looks at it knows it. When I removed Etoys part from Pharo I'm sad but there is no other choices. Now it > does not mean that I'm against Etoys and Etoys has the Etoys 40 image (note that we collected in 3.9 most of the etoys fixes with little support from Etoyers which forked way before, we did the same with the fixes of diego of Smalltalk). But again you can judge otherwise. > > > About the ranting or the little war between Squeak and Pharo > ====================================== > Frankly I'm tired about us ranting against Squeak/andreas/... and the inverse. For example Traits are cool, Javascript and PHP > will probably have them as Perl-6, Scala, Fortress. Now Squeak can remove them. I have no problem with that. Seriously this is your decision. > People in squeak-dev can freely say negative points about me if this helps. I decided that I will not rant nor get negative feelings about that. I > found the red pill :) > > *I* decided that I want to head to the future. So we will not rant nor make any bad statement about the past anymore. Not even report history or > on old facts: if you were there you should remember, else there is the archive :). This is my last mail on the past. > Frankly I have the best job I can dream about. I'm lucky just check my h-index for the fun, I have more than most researchers I know. In addition, I loved working and learning from people like lukas, adrian, nicolas, levente, marcus, ..... The next 10 years should be the best of my life and I > will take advantage of that. I want to have **10/15** years of pure fun and I will do it. I want and will create positive energy. Look at ESUG > we are doing a great job. > > About cross dialect energy > ================= > Now the key point of this mail. I **deeply** appreciate the attitude of people like nicolas, levente, and igor that do not bash us and help Pharo > but also Squeak. I sent this message mainly because of their attitude. I'm sad to see all this (their) energy duplicated. We cleaned and improved a > lot Pharo over the last two years (more than you may think) and we will continue. Squeak could have benefitted from it. Nicolas luckily for you > pushed a lot of our fixes in Squeak already. I'm getting the fixes of Squeak that are interesting for Pharo. Now depending on the Squeak vision > we could share some common things. May be we can build a better future together but not at all price. You see our goals is to get a clean, lean, flexible and robust system. If you want to share something with us let us know. You know now the vision of Pharo. > Squeak may want to compete with us too. This is ok too. > > If you want to help us building our vision you are welcome. Our logo is a lighthouse and it means that it will stand and last long because it has to guide boats. So we will continue Pharo against tempests and giant waves :) > > https://gforge.inria.fr/frs/download.php/26678/pharoVideo.zip > http://www.youtube.com/watch?v=m2LeNBY_5gk > The video is really cool (dan this is the one you wanted on waves). > > Stef

March 27, 2010

[Pharo-project] Recovering lost changes

by Schwab,Wilhelm K

Hello all, I had some type of melt-down today and ended up with an image that won't load. I have a backup from a few days ago, but a lot has happened since then. Recent change logs seem to be readable, but the "Recover lost changes" GUI has not been terribly helpful. Is there a way to filter to things like most recent versions of a any given methods, and/or sort on the types of chunks? One surprising weakness I noted was that many do-it chunks involve things that were in context in the debugger, are "now" nil and ended up breaking the file-in command. I put an error handler around the evaluatations which helped, but things are still somewhat slow thanks to other do-its that do a LOT of work. I might start chipping away from the most recent chunks until it recovers enough that I can cut my loses. Ian Bartholomew's Chunk Browser for Dolphin would be an ideal tool to emulate. With what we have now, any workarounds for the things above would be greatly appreciated. Is there a way to do extended selection (e.g. shift-select to select a range of chunks)? Bill

March 27, 2010

Re: [Pharo-project] Error parsing XML File

by Alexandre Bergel

Hi Fabrizo, I think you're in the right place to talk about that. I haven't been able to reproduce your error. I added a test: XMLParserTest>>testNonUTF8Characters self shouldnt: [XMLDOMParser parseDocumentFrom: '<foo>Bean BLABLABLA EidgenÃ¶ssisches Institut fÃ¼r BLABLALBLA</foo>' readStream] raise: Error. It goes green in my image. Do you have a different way to get the readStream from the String? Cheers, Alexandre On 26 Mar 2010, at 12:14, Fabrizio Perin wrote: > Hi, > I was parsing an XML File with the last version of XML Parser (XML- > Parser-JAAyer.68) and i get an error related to a not UTF-8 > character that the parser found into the document. The XML document > contains some german character: > > <![CDATA[SES: Bean BLABLABLA EidgenÃ¶ssisches Institut fÃ¼r > BLABLALBLA]]> > > Actually i'm not sure if the error is which is in the > UTF8TextConverter or something is wrong in the invokation from the > parser. Anyway i parse several time the same document with older > versions of the XML-Parser (XML-Parser-JAAyer.57) and it always > works well. I'm not sure if the mailing list of Pharo is the right > place to report this problem in the case i'm i'm sorry. > > Here the trace from the log: > > Error: Invalid utf8 input detected > 26 March 2010 4:14:07 pm > > VM: Mac OS - intel - 1062 - Squeak3.8.1 of '28 Aug 2006' [latest > update: #6747] Squeak VM 4.2.2b1 > Image: Pharo-1.0-10515-rc3 [Latest update: #10515] > > SecurityManager state: > Restricted: false > FileAccess: true > SocketAccess: true > Working Dir /Users/fabrizioperin/development/Pharo/WORKINGONNOW/ > MooseJEE_64 > Trusted Dir /foobar/tooBar/forSqueak/bogus > Untrusted Dir /Users/fabrizioperin/Library/Preferences/Squeak/ > Internet/My Squeak > > UTF8TextConverter(Object)>>error: > Receiver: an UTF8TextConverter > Arguments and temporary variables: > aString: 'Invalid utf8 input detected' > Receiver's instance variables: > an UTF8TextConverter > > UTF8TextConverter>>errorMalformedInput > Receiver: an UTF8TextConverter > Arguments and temporary variables: > > Receiver's instance variables: > an UTF8TextConverter > > UTF8TextConverter>>nextFromStream: > Receiver: an UTF8TextConverter > Arguments and temporary variables: > aStream: MultiByteFileStream: '/Users/fabrizioperin/development/ > Pharo/WORKINGON...etc... > character1: $Â¶ > value1: 182 > character2: $s > value2: 115 > unicode: nil > character3: $s > value3: 115 > character4: nil > value4: nil > Receiver's instance variables: > an UTF8TextConverter > > MultiByteFileStream>>next > Receiver: MultiByteFileStream: '/Users/fabrizioperin/development/ > Pharo/WORKINGONNOW/MooseJEE_64/src/...etc... > Arguments and temporary variables: > char: nil > secondChar: nil > state: nil > Receiver's instance variables: > > > XMLStreamReader>>basicNext > Receiver: a XMLStreamReader > Arguments and temporary variables: > nextChar: nil > Receiver's instance variables: > stream: MultiByteFileStream: '/Users/fabrizioperin/development/ > Pharo/WORKINGONN...etc... > nestedStreams: nil > peekChar: nil > buffer: a WriteStream 'SES: Bean zum Einlesen und updaten der > Stako relevanten ...etc... > > XMLStreamReader>>next > Receiver: a XMLStreamReader > Arguments and temporary variables: > nextChar: nil > Receiver's instance variables: > stream: MultiByteFileStream: '/Users/fabrizioperin/development/ > Pharo/WORKINGONN...etc... > nestedStreams: nil > peekChar: nil > buffer: a WriteStream 'SES: Bean zum Einlesen und updaten der > Stako relevanten ...etc... > > XMLStreamReader>>upToAll: > Receiver: a XMLStreamReader > Arguments and temporary variables: > aDelimitingString: ']]>' > Receiver's instance variables: > stream: MultiByteFileStream: '/Users/fabrizioperin/development/ > Pharo/WORKINGONN...etc... > nestedStreams: nil > peekChar: nil > buffer: a WriteStream 'SES: Bean zum Einlesen und updaten der > Stako relevanten ...etc... > > SAXDriver(XMLTokenizer)>>nextCDataContent > Receiver: a SAXDriver > Arguments and temporary variables: > cdata: nil > Receiver's instance variables: > streamReader: a XMLStreamReader > streamWriter: a XMLStreamWriter > entities: nil > externalEntities: nil > parameterEntities: nil > isValidating: false > parsingMarkup: false > saxHandler: an OPOpaxHandler > openTags: <ejb-jar>, <enterprise-beans>, <session>, <description> > nestedScopes: nil > useNamespaces: false > validateAttributes: nil > languageEnvironment: nil > > SAXDriver(XMLTokenizer)>>nextCDataOrConditional > Receiver: a SAXDriver > Arguments and temporary variables: > nextChar: $C > conditionalKeyword: nil > Receiver's instance variables: > streamReader: a XMLStreamReader > streamWriter: a XMLStreamWriter > entities: nil > externalEntities: nil > parameterEntities: nil > isValidating: false > parsingMarkup: false > saxHandler: an OPOpaxHandler > openTags: <ejb-jar>, <enterprise-beans>, <session>, <description> > nestedScopes: nil > useNamespaces: false > validateAttributes: nil > languageEnvironment: nil > > SAXDriver(XMLTokenizer)>>nextMarkupToken > Receiver: a SAXDriver > Arguments and temporary variables: > nextChar: $[ > Receiver's instance variables: > streamReader: a XMLStreamReader > streamWriter: a XMLStreamWriter > entities: nil > externalEntities: nil > parameterEntities: nil > isValidating: false > parsingMarkup: false > saxHandler: an OPOpaxHandler > openTags: <ejb-jar>, <enterprise-beans>, <session>, <description> > nestedScopes: nil > useNamespaces: false > validateAttributes: nil > languageEnvironment: nil > > SAXDriver(XMLTokenizer)>>nextToken > Receiver: a SAXDriver > Arguments and temporary variables: > whitespace: '' > Receiver's instance variables: > streamReader: a XMLStreamReader > streamWriter: a XMLStreamWriter > entities: nil > externalEntities: nil > parameterEntities: nil > isValidating: false > parsingMarkup: false > saxHandler: an OPOpaxHandler > openTags: <ejb-jar>, <enterprise-beans>, <session>, <description> > nestedScopes: nil > useNamespaces: false > validateAttributes: nil > languageEnvironment: nil > > OPOpaxHandler(SAXHandler)>>parseDocument > Receiver: an OPOpaxHandler > Arguments and temporary variables: > > Receiver's instance variables: > driver: a SAXDriver > eod: false > stack: an OrderedCollection(<?xml version="1.0" encoding="utf-8"?> > <ejb-jar id=...etc... > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 26, 2010

[Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by laurent laffont

Hi, Finally I've managed to build squeak vm rev. 2135 (current stable) with FT2Plugin which makes all tests green on Pharo 1.0 rc3 image........ on my machine :) If some Linux users can test it on their distro, thanks. The clean binary archive: http://lolgzs.free.fr/pharo/squeak-vm/Squeak-3.11.3.2135-pharo-bin.tar.gz The generated source archive: http://lolgzs.free.fr/pharo/squeak-vm/Squeak-3.11.3.2135-pharo-src.tar.gz PharoCore-1.0 + configured VMMaker 1.2 image (for new vm builders, to have a known working base): http://lolgzs.free.fr/pharo/squeak-vm/PharoCore-1.0-VMMaker-1.2.tar.gz To build from source archive: ======================= wget http://lolgzs.free.fr/pharo/squeak-vm/Squeak-3.11.3.2135-pharo-src.tar.gz tar -xvzf Squeak-3.11.3.2135-pharo-src.tar.gz cd Squeak-3.11.3.2135-pharo-src/ mkdir build && cd build ../unix/cmake/configure make sudo make install Internal plugins: ====================== UUIDPlugin External plugins: ====================== ADPCMCodecPlugin AioPlugin AsynchFilePlugin B2DPlugin B3DAcceleratorPlugin BMPReadWriterPlugin BitBltPlugin CroquetPlugin DSAPrims DropPlugin FFTPlugin FT2Plugin FileCopyPlugin FilePlugin FloatArrayPlugin FloatMathPlugin GeniePlugin HostWindowPlugin JPEGReadWriter2Plugin JPEGReaderPlugin JoystickTabletPlugin Klatt LargeIntegers LocalePlugin MIDIPlugin Matrix2x3Plugin MiscPrimitivePlugin Mpeg3Plugin QuicktimePlugin RePlugin SecurityPlugin SerialPlugin SocketPlugin SoundCodecPrims SoundGenerationPlugin SoundPlugin Squeak3D SqueakFFIPrims StarSqueakPlugin SurfacePlugin UnixOSProcessPlugin XDisplayControlPlugin ZipPlugin Fun story: if you don't have SecurityPlugin, LocaleTest>>testFontFullName deletes your image :) testFontFullName "self debug: #testFontFullName" | env dir | env := (Locale isoLanguage: 'ja') languageEnvironment. dir := FileDirectory on: SecurityManager default untrustedUserDirectory. [dir recursiveDelete] <-------------- Cool !! on: Error do: [:e | e]. env fontFullName. self assert: dir exists Cheers, Laurent Laffont

March 26, 2010

Re: [Pharo-project] Stateful Traits Literature

by StÃ©phane Ducasse

On Mar 26, 2010, at 11:40 AM, Simon Denier wrote: > > On 25 mars 2010, at 23:26, Alexandre Bergel wrote: > >> I agree. Most of our extensions are really complex. >> >> In my opinion, traits must define variable. Else it defeats the whole purpose of having a better modularity. Each time I use traits, I need variables. >> >> The solution of Visualworks was quite simple, and I think it makes sense in most of the practical cases: when you compose traits, you simply concatenate the variables defined in the composed traits with the variables defined in the class. Duplicated names are then removed. Easy. > > > Funny, I also need state when I use traits, but in a more conservative approach: by default, I prefer states to be separated and possibly duplicated. I think it's easier to notice that state needs to be shared than to notice a weird bug happens because state is shared in a wrong way. If you need state to be shared, it's easy to refactor the accessors to access the same state. But it's my completely insubstantial opinion Come on I like it. This is a cool remark. I will think about that. > (it's a deal between sharing states to have easy consistency and having compatible constraints (pre/post conditions) on shared state) > > As for the argument with recompiling methods, it's the same deal right now because required methods need to be overridden right? The rule of thumb is that you should not access state directly, but only through pure accessors. So only pure accessors need to be recompiled. But the stuff discussed by Markus could be helpful. > > As for traitInitialization, I have my ideas but I guess there is no silver bullet. > > >> >> Cheers, >> Alexandre >> >> >> On 25 Mar 2010, at 17:19, Stefan Marr wrote: >> >>> Hi Alexandre: >>> >>> >>> Thanks. >>> I have read all these papers already, but kind of hoped that there is something I missed so far. >>> >>> On 25 Mar 2010, at 23:00, Alexandre Bergel wrote: >>>> "Stateful Traits and their Formalization" http://scg.unibe.ch/scgbib?_k=OiaJOIuA&query=Berg08e&display=abstract >>>> => It describes stateful traits >>>> >>>> "User-Changeable Visibility: Resolving Unanticipated Name Clashes in Traits" http://scg.unibe.ch/scgbib?_k=NNRwidu5&query=freezable+traits&display=abstr… >>>> =>Freezable traits >>>> >>>> "Adding State and Visibility Control to Traits using Lexical Nesting" http://scg.unibe.ch/scgbib?_k=J-wbMltV&query=tom+cutsem+bergel >>>> => Traits for a class-less language >>> My problem is, that these proposals involve a lot additional complexity. >>> And, Tom's paper is not really applicable to PHP. PHP just does not have a real notion of lexical context. >>> >>> Thanks >>> Stefan >>> >>> >>> >>> -- >>> Stefan Marr >>> Software Languages Lab >>> Vrije Universiteit Brussel >>> Pleinlaan 2 / B-1050 Brussels / Belgium >>> http://soft.vub.ac.be/~smarr >>> Phone: +32 2 629 2974 >>> Fax: +32 2 629 3525 >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 26, 2010

Re: [Pharo-project] How to easily intercept messages sent to ALL objects ?

by Eliot Miranda

On Fri, Mar 26, 2010 at 1:15 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Mar 25, 2010, at 5:50 PM, Mariano Martinez Peck wrote: > > > Hi folks. I want to intercept (and do something) for all objects. I know > few approaches, for example: > > > > 1) using method wrappers (implementing run: aSelector with: arguments > in: aReceiver) I can wrap all compiled methods of all classes and there I > have the receiver. > > > > 2) become all objects to some kind of hacky object that stores the > original object and that redefines the doesNotUnderstand: > > > > But in 1) I need to change all CompiledMehtod of all classes. > > in 2) I have to become all the objects to another object > > > > Then my question is, is there an easier way to intercept all messages > send to all objects from the image side (not going to vm) and with a lower > cost ? > > No. > > So the MOP (meta object protocol), the "reflective API" of Smalltalk does > not allow for "reifying" message receive. > > Historically, after Reflection was discovered and people started to > generalize it, of cource they added that. For example, there is CODA: > > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.108.6885&rep=rep1&… > > which made the whole "message send" explicit and interceptable. > > This means it is decomposed into Send, Receive, Lookup, Apply. Very nice. > Very general. One can override Lookup when one wants to do > e.g. Multiple inheritance. Or Apply, when the language of the method is not > smalltalk. Or Receive, if you want to hook into "does an object get > a message?". Futures, non-blocking messages. All easy to be done. > > But: it's slow. Dog slow. So people started to think about: how to speed > up? Sadly the idea of optimizing at runtime (partially evaluating the MOP) > has seen not much work. What was done is "partial reflection": only reifiy > those opereation at exactly those spots that one is interested in. > This was done in MetaClassTalk (it checks if the MetaClass overrides > message sending, else it uses normal bytecodes) and to the extreme in > Reflex. > > Now if you want to change reflective behavior *per object* the other > important thing is that you need to be able to define changed behavior at > the level of Objects vs. Classes. CLOS style MOPS like MetaClassTalk allow > *only* for a per-Class-change. > > Enter Eric Tanter's Relex. Reflex generalized the MOP idea to not be bound > to classes/metaclasses but you can select *per instruction* what to reify. > And that reification is only done when needed, keeping the code you are not > interested in fast. > (Reflex is what happens when you bring the lessons of AOP back into MOPs. > That is, the good parts of AOP). > > http://portal.acm.org/citation.cfm?id=949309 > > Of course, message receive is not easy to achive other than reifying > method-execute on all methods+doesNotUnderstand. > This can be made a bit more efficient for all the objects of the class you > are not interested in by using Object-specific Behavior > (the anonymous subclass trick). Phillippe did that in TreeNurse... > But all in all, this is more of a hack. > > Now for message receive, one could imagine a partial reification scheme: a > tag bit on the object header, if it is there, the VM calls a receive > method instead of the method that would originally be called. So you would > pay, in all casses, one bit-check on message send *and* you need > space to put this flag. Would anyone want to pay that? > Perhaps we can be cleverer. What could we do if we introduced delegation into the language? Then we can add wrappers around objects and put the interception into the wrappers. This way there is no additional check. If one wants to intercept references to an object one creates a DNU wrapper and becomes the two objects. An execution model of delegation is that there are two slots for the receiver in a context, a state slot through which inst vars are accessed, and a self slot to which messages are sent. Normal sends merely duplicate the receiver into both slots. Delegating sends take state as an additional argument. An alternative model is to dispense with direct inst var access (assuming the JIT will inline simple accessors in PICs, or simply by virtue of the use of machine code render accessors affordable) and provide accessors for delegators that indirect through the delegate. > In general, I would like to experiment with a MOP that can reify message > receive in a meaningful *and efficient* way. But the current VM can't do it. > In addition, there is always the problem that reflection leads to loops > (your code will use the code it will used on). > > http://scg.unibe.ch/archive/papers/Denk08bMetaContextLNBIP.pdf > > Wich needs to be solved, too, if you ever want to be able to use reflection > on everything (even the things you implement reflectively). > > Alternatively, one could use a proxy. Now if you don't use a subclass of > ProtoObject, but something with VM support int the Style of Adrian > Lienhard's > Aliases: > > > http://scg.unibe.ch/archive/papers/Lien08bBackInTimeDebugging.pdf > > or the Handle (we need a better word!!!) stuff that JB is working on, maybe > this would not be too bad. The Alias is *hidden*, you can put it > (eventually, > after all engineering done) on any object (even Integers)... and than, > after you swap out something, you need a proxy anyway for the "outpointer". > > > And if going to vm, how ? > > The OOPSLA paper of 2008 on tolerating memory leaks has scheme where they > use the GC of Jikes. So compared to LOOM, they have a modern > GC without an object table, and it seems much simpler. > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 26, 2010

[Pharo-project] Student internships at INRIA

by Marcus Denker

Hi, Besides Postdocs, PhDs and Engineers, we are looking for student interns. INRIA has a program for Students to work in a research group as an Intern. Application is open now. http://www-direction.inria.fr/international/PROGRAMMES/internship/indexAPPE… More information in english: http://www-direction.inria.fr/international/Page_Programmes_en.php?prog=int… Subjects: http://www-direction.inria.fr/international/PHP/Internship/CandidatsII.php The ones of RMoD are: - Flexible Modules for Dynamic Languages - Layer Identification and Diagnotics - Trait-based Remodularisation - Minimal Smalltalk Runtime Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 26, 2010