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

Re: [Pharo-project] [Vm-dev] Primitive to set an identityHash

by Mariano Martinez Peck

On Wed, Jan 18, 2012 at 11:25 AM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > > I really don't see what good could come of it being available in generalâ¦ > > I think it is a nice feature to have. If you just have it in the VM nobody will see it unless the guy load all VM stuff and checks the code. For example, for certain hacky scenario, I wanted to create proxies which have exactly the same identitiHash as the object they proxify. That primitive let me do that. I was lucky that I asked in the mailing list, otherwise I would have miss it. And it is not that we do not have dangerous methods in the image because we do. So... I would include it since I think it could be useful for someone doing hacky stuff, but as Stef says, I would put a really really clear comment. > Cheers, > Henry > > On Jan 18, 2012, at 8:16 26AM, stephane ducasse wrote: > > > > > After the discussions we got and with a really big comment I would add > it. > > > > Stef > > On Jan 17, 2012, at 11:02 PM, Mariano Martinez Peck wrote: > > > >> > >> > >> On Tue, Jan 17, 2012 at 8:04 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> > >> > >> > >> On Tue, Jan 17, 2012 at 8:43 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> > >> Hi guys. Becuase of some work I am doing with proxies, I would like to > be able to set a specific identityHash to a proxy instance. I can add this > primitive in my VM, but I was thinking if this could be of a general > interest also? > >> > >> It already exists. See primitiveSetIdentityHash in > InterpreterPrimitives. Primitive # 161. > >> > >> Thank you so much Eliot. You even save my time of coding it ;) I > should have checked before...I always forget about InterpreterPrimitives > hahaha > >> So...Pharaoers... do you want the image side of the primitive and some > tests? I can provide that if desired (in my opinion I would include it) > >> > >> Cheers > >> > >> > >> > >> > >> > >> Cheers > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > >> > >> > >> > >> > >> -- > >> best, > >> Eliot > >> > >> > >> > >> > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > > > > -- Mariano http://marianopeck.wordpress.com

Jan. 18, 2012

Re: [Pharo-project] Misc. newbie questions

by Serge Stinckwich

On Sat, Jan 7, 2012 at 10:28 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 7 January 2012 15:11, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> 2012/1/7 Frank Shearar <frank.shearar(a)gmail.com>: >>> On 7 January 2012 14:14, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> 2012/1/6 Lukas Renggli <renggli(a)gmail.com>: >>>>> On 6 January 2012 11:20, Peter Hugosson-Miller <oldmanlink(a)gmail.com> wrote: >>>>>> On 6 jan 2012, at 06:41, "Gerry Weaver" <gerryw(a)compvia.com> wrote: >>>>>> >>>>>> 2. There appear to be some tool choices in the Pharo image. I would like to >>>>>> be able to create a class and it's methods in an editor in one go. I like >>>>>> being able to see all of the class code at once. Is there a way to do this? >>>>>> Â I just want to be able to type it all in and accept (evaluate?) all at >>>>>> once. >>>>>> >>>>>> This is an interesting question to me personally. After 15 years of working >>>>>> exclusively in Smalltalk I've recently been forced to start programming in >>>>>> Java, where the source code is always (as far as I know) arranged in the way >>>>>> you describe. >>>>>> >>>>>> This organization just emphasizes the dead and compiled nature of Java (and >>>>>> similar languages), compared to the living objects of Smalltalk, where even >>>>>> methods are objects, created by sending messages to other objects. Source >>>>>> code is relegated to being a mere artifact, which can be saved and organized >>>>>> in any way one wishes, and preferably never shows its ugly face to the coder >>>>>> :-p >>>>> >>>>> Which of course is no argument why Smalltalk code could not be >>>>> displayed in a more programmer friendly way as a continuous block of >>>>> text. There is no technical reason why source ranges in text box >>>>> couldn't correspond to life method objects. Compared to other >>>>> languages it is extremely tedious in Smalltalk to get an overview over >>>>> a project, a package, or even a single class or to navigate between >>>>> entities. >>>>> >>>>>> And yes, I really *really* miss a good, object oriented class browser! >>>>> >>>>> Eclipse is pretty good, especially with the Java Browsing Perspective. >>>>> >>>>> Lukas >>>>> >>>> >>>> As soon as you would display the code for many methods in a single text pane, >>>> you will find file-based-educated people making large refactorings in >>>> a single pass... >>>> Imagine this leads to many syntax errors, they will soon be willing to >>>> save their changes for a later rework... >>>> This would be a complete change in programming flow and if we really >>>> want to support this, we would have to: >>>> - add a way to save syntactically incorrect code >>>> - let IDE tools work on partially correct code (syntax highlighting, >>>> navigation, etc...) >>>> >>>> IMHO, these features add a lot of complexity... Is it really worth? >>>> I like the discipline of focusing on a single method until it is at >>>> least syntactically correct. >>> >>> The Pharo community has extremely limited resources so it seems quite >>> fair to me for Pharo to say "yes, but it's up to you because we have >>> no time". It _is_ very useful to be able to see and edit long reams of >>> text: my favourite text editor's been beaten on since the late 70s. It >>> is now very, very good at manipulating text, in multiple programming >>> languages, in multiple human languages, on many platforms. That I >>> can't use this text editor to manipulate a textual representation of >>> my favourite language is extremely annoying! >>> >>> frank >> >> Yeah, but my take was that re-inventing a very narrow subset of these >> 40 years old text editors in Smalltalk would likely be a failure... >> (or a big project) > > It would be a fairlly big piece of work although we do have lots of > pieces lying around: > * Coral's working on a scripting/REPL-like interface, > * the Common Lisp community has been using SLIME to provide a REPL to > a running image for years while also using files to store their code, > * we have Gitocello (which also translates Squeak/Pharo to gst), > * we have LanguageBoxes (*) allowing us to permit craziness like > storing code outside the image in one format without affecting the > entire language (letting us store Smalltalk code in something other > than chunk format) > > (*) watch this space: I'm making progress on breaking up the Helvetia > image into a bootstrappable bunch of packages Did you commit your code somewhere ? Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Jan. 18, 2012

Re: [Pharo-project] A BlockEventHandler is xxxxxxxxx.

by StÃ©phane Ducasse

;) On Jan 18, 2012, at 10:31 AM, Igor Stasenko wrote: > On 18 January 2012 08:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Looks to me like HashTableSubclass is crying to get born and usedâ¦ > > maybe. But definitely not in case of BlockEventHandler. > This class, and all of its uses should simply die. > Because it is wrong pattern to have pluggable behavior. > Every time one may want to introduce new kind of event he should patch > this class again and again.. > no way :) > > > P.S. why do people producing such code? Don't they think before doing > it, that there are something inherently wrong with such approach? > For me there are things, which i will never do, even if paid well for > job done. Because they are against my nature. > >> >> Stef >> >> >> A BlockEventHandler is xxxxxxxxx. >> >> Instance Variables >> allRecipientsBlocOrSelector: <Object> >> clickBlocOrSelector: <Object> >> doubleClickBlocOrSelector: <Object> >> doubleClickTimeoutBlocOrSelector: <Object> >> firstMouseSelectorBlocOrSelector: <Object> >> fixReversedValueMessagesBlocOrSelector: <Object> >> handlesClickOrDragBlocOrSelector: <Object> >> handlesGestureStartBlocOrSelector: <Object> >> handlesKeyboardBlocOrSelector: <Object> >> handlesMouseDownBlocOrSelector: <Object> >> handlesMouseMoveBlocOrSelector: <Object> >> handlesMouseOverBlocOrSelector: <Object> >> handlesMouseOverDraggingBlocOrSelector: <Object> >> handlesMouseStillDownBlocOrSelector: <Object> >> keyStrokeBlocOrSelector: <Object> >> messageListBlocOrSelector: <Object> >> methodRefListBlocOrSelector: <Object> >> mouseDownBlocOrSelector: <Object> >> mouseDownSelectorBlocOrSelector: <Object> >> mouseEnterBlocOrSelector: <Object> >> mouseEnterDraggingBlocOrSelector: <Object> >> mouseLeaveBlocOrSelector: <Object> >> mouseLeaveDraggingBlocOrSelector: <Object> >> mouseMoveBlocOrSelector: <Object> >> mouseStillDownBlocOrSelector: <Object> >> mouseStillDownRecipientBlocOrSelector: <Object> >> mouseStillDownSelectorBlocOrSelector: <Object> >> mouseUpBlocOrSelector: <Object> >> mouseUpSelectorBlocOrSelector: <Object> >> onBlocOrSelector: <Object> >> onGestureSendBlocOrSelector: <Object> >> printOnBlocOrSelector: <Object> >> replaceSendsInBlocOrSelector: <Object> >> sendBlocOrSelector: <Object> >> startDragBlocOrSelector: <Object> >> veryDeepFixupWithBlocOrSelector: <Object> > > > > -- > Best regards, > Igor Stasenko.

Jan. 18, 2012

Re: [Pharo-project] [Vm-dev] Primitive to set an identityHash

by Henrik Johansen

I really don't see what good could come of it being available in generalâ¦ Cheers, Henry On Jan 18, 2012, at 8:16 26AM, stephane ducasse wrote: > > After the discussions we got and with a really big comment I would add it. > > Stef > On Jan 17, 2012, at 11:02 PM, Mariano Martinez Peck wrote: > >> >> >> On Tue, Jan 17, 2012 at 8:04 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> >> >> On Tue, Jan 17, 2012 at 8:43 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> Hi guys. Becuase of some work I am doing with proxies, I would like to be able to set a specific identityHash to a proxy instance. I can add this primitive in my VM, but I was thinking if this could be of a general interest also? >> >> It already exists. See primitiveSetIdentityHash in InterpreterPrimitives. Primitive # 161. >> >> Thank you so much Eliot. You even save my time of coding it ;) I should have checked before...I always forget about InterpreterPrimitives hahaha >> So...Pharaoers... do you want the image side of the primitive and some tests? I can provide that if desired (in my opinion I would include it) >> >> Cheers >> >> >> >> >> >> Cheers >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> >> >> >> -- >> best, >> Eliot >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >

Jan. 18, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Igor Stasenko

On 18 January 2012 07:19, Friedrich Dominicus <frido(a)q-software-solutions.de> wrote: > Jimmie Houchin <jlhouchin(a)gmail.com> writes: > >> I am all for improving our editing experience. But I want it in my >> image and not in Emacs/vi. I would rather see our world improved than >> to see it require an external editor which sees code as text, not >> objects, where different external editors have differing features. > Well I suggest then to start with adding an Editor which deserves that > name. By all means the Â editors in any Smalltalk are poor. And now that > you mention Emacs. There is nothing comparable to this Editor for Text > editing in any Smalltalk world-wide. So yes you an live within the live > "objects!" but you have to leave them whenever you want to write > something more but 5 lines of code. >> >> And yes, I am thoroughly pro Pharo. Do I believe there are >> deficiencies. Yes. I just don't believe the GUI being non-standard, >> the image, and the editor being in the image are not among them. And I >> don't believe that challenges to those things should go unchallenged >> and accepted just because somebody > Ah yes another thing which wouuld be nice to have something with one can > understand without studying it for years and repeated tries. A simple > way of building somewhat resembling GUI applications in Pharo/Squeak. Ah > yes flame me that I do appreciate the fantastic Morph world. It's Â so > fantastic that just the developers can build a somewhat "usable" > interface with it. Tell me about the "great" applicatons using Morph > (anything besides yet another Browser please) >> >> And yes, I am just as opinionated about my perceptions of the >> deficiencies of Python, Clojure, Ruby, Eclipse, Netbeans, ... >> Or my frustrations when using them. >> I just don't go into those communities expecting them to shape their >> favorite tool to my vision. I rather try to use their tools and >> attempt to learn their values and ways, assuming they have reason and >> purpose for their language and tools. > Well at least you get an Editor with Eclipse and Netbeans. But yeah we > don't need not stinking Editor. The editor in Pharo suits my needs pretty well. I do not use it for editing rich text , i use it for coding. 5 lines of code per method. Period. No need for code folding, no need for sophisticated regex search/replace. No need bookmarks No need for (put your favorite). Just because it is there for coding in smalltalk. If you want an editor which can edit books, feel free to implement it. I am using bicycle to get to work. It is comfortable, fast and reliable for daily use. Now what you would think about a guy on street who attempting to laugh at me because my bike don't have jet engine to travel to Earth's orbit? > Regards > Friedrich > > > -- > Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim > Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus > -- Best regards, Igor Stasenko.

Jan. 18, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Igor Stasenko

On 17 January 2012 06:34, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > > I have limited rights to be heard here because I have been a part of the > Squeak/Pharo community for a long time. I have less rights than others > because I haven't contributed anything of consequence. Others who have been > here far less time but have contributed a lot more, have greater rights. > I don't think there should be any "rights" related to level of contribution. But it is true, you are much likely will be heard and your ideas taken into account, if you will show others your dedication. And of course a simplest way of showing it is to contribute :) > Just my opinions. But I think that they are reasonably founded. I spend a > lot more time with people than programming. > > Jimmie > > -- Best regards, Igor Stasenko.

Jan. 18, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Igor Stasenko

On 16 January 2012 11:15, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 16 January 2012 09:59, Lawson English <lenglish5(a)cox.net> wrote: >> On 1/15/12 6:44 PM, Jimmie Houchin wrote: >>> >>> On 1/15/2012 6:55 AM, Gerry Weaver wrote: >>>> >>>> Hi Andreas, >>>> >>>>> I am not comfortable with the idea to write parts of an application in >>>>> different languages. >>>>> Typically the disadvantages overweigh the advantages to do so as you >>>>> would have different languages and systems to master and update. >>>>> Interoperability with other systems and languages should be easy and >>>>> Squeak/Pharo are still lacking in this area. This is well known and >>>>> hopefully there will be some improvements in the future. >>>> >>>> >>>> I guess I would have to disagree with you here. Most of the editors and >>>> IDEs of other languages are not maintained by the language proper. There >>>> are many editors and IDEs that support many languages in addition to the >>>> one they are written in. I think the benefits of using a full featured >>>> GUI toolkit to create an IDE would be significant. >>> >>> >>> And I have to disagree with you here. You lack the imagination and >>> knowledge to understand the significant advantage of having a single >>> language, environment and toolset that Smalltalk provides. >> >> >> I agree that there is an advantage to having a unified IDE/environment/etc, >> but Smalltalk IS stuck in the past in that it doesn't take advantage of >> multiple cores. I'm not talking about multi-threading in the usual sense, >> but things like the ability to debug one image from another so that the >> errors that pop up in the application under development don't affect the >> environment being used TO development that application. This issue pops up >> most obviously when trying to debug Cobalt/Croquet in a multi-user >> configuration, but arises all the time, especially when external libraries >> (e.g. OpenGL) are being used and errors occur that the current toolset isn't >> designed to accommodate. >> >> We need to develop better ways of doing things, both for individual and >> collaborative environments. IOW, we need spoon and teatime and various other >> solutions to mature and work together. > > If only we knew some folks working on the problem... > http://marcusdenker.de/publications/Casa09aObjectSpaces.pdf :) > > Of course, there's a bit of elbow grease required to turn a research > topic into a production-ready system. > yes, yes yes.. we dreaming a lot about it. conceptually there are not too much new: you can always run two images aside and establish communication between them and so they are effectively a two separate object spaces. but what is different is to make a VM which aware of it and makes use of it, like HydraVM or kind of. > frank -- Best regards, Igor Stasenko.

Jan. 18, 2012

Re: [Pharo-project] A BlockEventHandler is xxxxxxxxx.

by Igor Stasenko

On 18 January 2012 08:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Looks to me like HashTableSubclass is crying to get born and usedâ¦ maybe. But definitely not in case of BlockEventHandler. This class, and all of its uses should simply die. Because it is wrong pattern to have pluggable behavior. Every time one may want to introduce new kind of event he should patch this class again and again.. no way :) P.S. why do people producing such code? Don't they think before doing it, that there are something inherently wrong with such approach? For me there are things, which i will never do, even if paid well for job done. Because they are against my nature. > > Stef > > > A BlockEventHandler is xxxxxxxxx. > > Instance Variables > Â Â Â Â allRecipientsBlocOrSelector: Â Â Â Â Â Â <Object> > Â Â Â Â clickBlocOrSelector: Â Â Â Â Â Â <Object> > Â Â Â Â doubleClickBlocOrSelector: Â Â Â Â Â Â Â <Object> > Â Â Â Â doubleClickTimeoutBlocOrSelector: Â Â Â Â Â Â Â <Object> > Â Â Â Â firstMouseSelectorBlocOrSelector: Â Â Â Â Â Â Â <Object> > Â Â Â Â fixReversedValueMessagesBlocOrSelector: Â Â Â Â <Object> > Â Â Â Â handlesClickOrDragBlocOrSelector: Â Â Â Â Â Â Â <Object> > Â Â Â Â handlesGestureStartBlocOrSelector: Â Â Â Â Â Â Â <Object> > Â Â Â Â handlesKeyboardBlocOrSelector: Â Â Â Â Â <Object> > Â Â Â Â handlesMouseDownBlocOrSelector: Â Â Â Â <Object> > Â Â Â Â handlesMouseMoveBlocOrSelector: Â Â Â Â <Object> > Â Â Â Â handlesMouseOverBlocOrSelector: Â Â Â Â <Object> > Â Â Â Â handlesMouseOverDraggingBlocOrSelector: Â Â Â Â <Object> > Â Â Â Â handlesMouseStillDownBlocOrSelector: Â Â Â Â Â Â <Object> > Â Â Â Â keyStrokeBlocOrSelector: Â Â Â Â Â Â Â Â <Object> > Â Â Â Â messageListBlocOrSelector: Â Â Â Â Â Â Â <Object> > Â Â Â Â methodRefListBlocOrSelector: Â Â Â Â Â Â <Object> > Â Â Â Â mouseDownBlocOrSelector: Â Â Â Â Â Â Â Â <Object> > Â Â Â Â mouseDownSelectorBlocOrSelector: Â Â Â Â Â Â Â Â <Object> > Â Â Â Â mouseEnterBlocOrSelector: Â Â Â Â Â Â Â <Object> > Â Â Â Â mouseEnterDraggingBlocOrSelector: Â Â Â Â Â Â Â <Object> > Â Â Â Â mouseLeaveBlocOrSelector: Â Â Â Â Â Â Â <Object> > Â Â Â Â mouseLeaveDraggingBlocOrSelector: Â Â Â Â Â Â Â <Object> > Â Â Â Â mouseMoveBlocOrSelector: Â Â Â Â Â Â Â Â <Object> > Â Â Â Â mouseStillDownBlocOrSelector: Â Â Â Â Â <Object> > Â Â Â Â mouseStillDownRecipientBlocOrSelector: Â Â Â Â Â <Object> > Â Â Â Â mouseStillDownSelectorBlocOrSelector: Â Â Â Â Â <Object> > Â Â Â Â mouseUpBlocOrSelector: Â Â Â Â Â <Object> > Â Â Â Â mouseUpSelectorBlocOrSelector: Â Â Â Â Â <Object> > Â Â Â Â onBlocOrSelector: Â Â Â Â Â Â Â <Object> > Â Â Â Â onGestureSendBlocOrSelector: Â Â Â Â Â Â <Object> > Â Â Â Â printOnBlocOrSelector: Â Â Â Â Â <Object> > Â Â Â Â replaceSendsInBlocOrSelector: Â Â Â Â Â <Object> > Â Â Â Â sendBlocOrSelector: Â Â Â Â Â Â <Object> > Â Â Â Â startDragBlocOrSelector: Â Â Â Â Â Â Â Â <Object> > Â Â Â Â veryDeepFixupWithBlocOrSelector: Â Â Â Â Â Â Â Â <Object> -- Best regards, Igor Stasenko.

Jan. 18, 2012

Re: [Pharo-project] Putting source code in method trailer [WAS] Re: Speeding up Finder string search

by Igor Stasenko

On 18 January 2012 10:22, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 17 January 2012 19:22, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> >> On Tue, Jan 17, 2012 at 6:31 PM, Mariano Martinez Peck >> <marianopeck(a)gmail.com> wrote: >>> >>> >>>> If you don't bother about being slow, you can also make it much easier: >>>> >>>> >>>> |trailer source m | >>>> m := (Gofer>>#load). >>>> trailer := m trailer. >>>> source := m getSource. >>>> trailer sourceCode: source. >>>> m becomeForward: (m copyWithTrailerBytes: trailer) >>>> >>>> and if you want to do it for the whole image you can use one bulk become >>>> and it will be fast. >>>> >>>> I will experiment and see if it is working. >>>> >>> >> >> >> Well, with the following script it seems I am able to embed all source code >> in trailers: >> >> | trailer source key dict classes | >> Â dict := IdentityDictionary new. >> CompiledMethod allInstances do: [:aMethod | >> Â Â Â trailer := aMethod trailer. >> Â Â Â source := aMethod getSource. >> Â Â Â trailer sourceCode: source. >> Â Â Â dict at: aMethod put:Â (aMethod copyWithTrailerBytes: trailer). >> ]. >> dict keys asArray elementsExchangeIdentityWith: dict values asArray. >> >> > you doing it a little bit wrong > > Â CompiledMethod allInstances do: [:aMethod | > Â Â source := aMethod getSource. > Â Â trailer := CompiledMethodTrailer new sourceCode: source. > Â Â dict at: aMethod put: Â (aMethod copyWithTrailerBytes: trailer). > Â ]. > > > As for what we should encode in method trailer and what we shouldn't, i think > we should put an id there, and then have a source code manager > which will work as key-value storage to retrieve stuff at given key. > And stuff can be not just a source code, but more compound object > which will also carry things like, author, timestamp, link to previous > version etc etc etc. Just thought that you can use Fuel to serialize such object and materialize it by demand by taking an id. :) > Now, if we could have such abstraction at first place, then it is no > longer relevant where the actual data is stored, in files, in image, > or in networked database, > because you can have any of them. > > I would really like to invest some time to that, or find someone who > could do that, so i can help with it :) > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

Jan. 18, 2012

Re: [Pharo-project] Putting source code in method trailer [WAS] Re: Speeding up Finder string search

by Igor Stasenko

On 17 January 2012 19:22, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Tue, Jan 17, 2012 at 6:31 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> >> >>> If you don't bother about being slow, you can also make it much easier: >>> >>> >>> |trailer source m | >>> m := (Gofer>>#load). >>> trailer := m trailer. >>> source := m getSource. >>> trailer sourceCode: source. >>> m becomeForward: (m copyWithTrailerBytes: trailer) >>> >>> and if you want to do it for the whole image you can use one bulk become >>> and it will be fast. >>> >>> I will experiment and see if it is working. >>> >> > > > Well, with the following script it seems I am able to embed all source code > in trailers: > > | trailer source key dict classes | > Â dict := IdentityDictionary new. > CompiledMethod allInstances do: [:aMethod | > Â Â Â trailer := aMethod trailer. > Â Â Â source := aMethod getSource. > Â Â Â trailer sourceCode: source. > Â Â Â dict at: aMethod put:Â (aMethod copyWithTrailerBytes: trailer). > ]. > dict keys asArray elementsExchangeIdentityWith: dict values asArray. > > you doing it a little bit wrong CompiledMethod allInstances do: [:aMethod | source := aMethod getSource. trailer := CompiledMethodTrailer new sourceCode: source. dict at: aMethod put: (aMethod copyWithTrailerBytes: trailer). ]. As for what we should encode in method trailer and what we shouldn't, i think we should put an id there, and then have a source code manager which will work as key-value storage to retrieve stuff at given key. And stuff can be not just a source code, but more compound object which will also carry things like, author, timestamp, link to previous version etc etc etc. Now, if we could have such abstraction at first place, then it is no longer relevant where the actual data is stored, in files, in image, or in networked database, because you can have any of them. I would really like to invest some time to that, or find someone who could do that, so i can help with it :) -- Best regards, Igor Stasenko.

Jan. 18, 2012