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

Re: [Pharo-project] Object Buffer (implementation tryout)

by StÃ©phane Ducasse

John I think that we agree to put FFI in 1.1 now we were wondering if Alien was not better. But the support for Alien on different platform is not clear. Stef On Jan 13, 2010, at 6:42 AM, John M McIntosh wrote: > I was trying to rework the clipboard logic last fall but I couldn't find any window users to test it. Things like supporting cut/copy/paste of graphics objects. > But it also required FFI in Pharo and I don't think anyone reached a decision on that. If anyone would like to take that task on I"ll give them an image to > work with... > > I'll note in Sophie we support the cut/copy/paste of complex objects (chunks of books). A matter of checking what the object was, either > text or a complex object. > > PS if anyone is interested the Undo/Redo Logic that Impara did for Sophie was very well received, easy to use, and we could build a book from scratch > then undo the entire creation, then redo it. This sounds complex, it was. However the framework made it easy, one piece at a time... > Perhaps someone should harvest that since it *was* generic. > > > On 2010-01-12, at 1:10 AM, CÃ©drick BÃ©ler wrote: > >> >> Perhaps a unified clipboard would be nicer... objects or text (or, >> potentially converible to host OS things...). >> >> yes that would be really great (copy name seems useless to me... better to have copy object and paste name eventually) ! >> But I don't have the expertise to do it I guess. For now we have in the image: >> >> Clipboard >> ExternalClipboard (from Sophie) >> MacOSClipboard >> SqueakClipboard (empty !) > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 13, 2010

Re: [Pharo-project] I cannot believe that Browser is relying on Object>>initialExtent

by StÃ©phane Ducasse

Yes I was implying anything else. On Jan 13, 2010, at 8:47 AM, Schwab,Wilhelm K wrote: > Stef, > > Agreed - Object is not a good home for methods that clearly have no place there. I'm not excusing the poor practice, but I _think_ I understand how it came about. > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Wednesday, January 13, 2010 2:33 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] I cannot believe that Browser is relying on Object>>initialExtent > > :) > > I really think that putting a method in object just because may be at one point a wrong object may receive a message should be avoided. Just already puting initialExtent into CodeHolder fixes some use cases.... > >> Stef, >> >> And you were ready to give up on Pharo... :) > > :) > Now I start to have fun and I feel that the board is moving and ready for several turn around the earth (funny for a lighthouse). > >> A lot of Squeak code looks like it was written w/o thought of exceptions. There is probably good reason for that, in that much of it comes from before the days of structured exception handling, weak collections, etc. In fairness, having a browser, or worse yet a debugger, quit over a bad receiver problem can turn ugly. By putting things in Object, those types of bugs would be largely avoided. I'm not saying it is a good way to work, but it is wide spread in Squeak. >> >> Bill >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> StÃ©phane Ducasse >> Sent: Tuesday, January 12, 2010 4:36 PM >> To: Pharo-project(a)lists.gforge.inria.fr Development >> Subject: [Pharo-project] I cannot believe that Browser is relying on >> Object>>initialExtent >> >> argh....... >> May be not putting everything in Object would help. >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 13, 2010

Re: [Pharo-project] clone vs shallowCopy

by StÃ©phane Ducasse

Now it would be nice to clean that because in VW you have copy, shallowCopy and postCopy and it works. They removed veryDeepCopy and other friends even when they were at the time were they could burn engineering time on that. So for me clone is one too many. And worse cloning and object cannot be a shallowCopy semantics. it should be more a veryDeepInnerVeryCopy (I could not resist sorry) Of course we already clean and remove the veryDeepInnerCopy.... No comment. >>> - #copy is the normal copy operation. It should be used by default and >>> never overridden. It calls #postCopy that can be overridden to have >>> class specific copy semantics. >>> >>> - #shallowCopy does a shallow copy. It should never be overridden and >>> only be used if you want to get these very specific semantics. >>> >>> - #deepCopy does a deep copy. It should never be overridden and only >>> be used if you want to get these very specific semantics. >>> >>> - #clone comes from eToys and Morphic (AFAIK). It implements some >>> other copy semantics than #copy. I don't think that anybody should >>> call this method, other than code that depends on this particular copy >>> behavior. >> >> we should copy that in Object class comment and all the methods >> >> >> where do you see that it is morphic related for me clone is only implemented >> on character, Boolean, Object, SMalltInt symbol, UndefinedObject > > Back in the old days, Squeak 1.1 didn't have primitive 148 (which is now used by both #shallowCopy and #clone). #shallowCopy was the way to create a "one-level copy" of an Object. It had the same code as today, but with no primitive. > Primitive 148 was introduced somewhere between 1.1 and 1.19 (note that 1.2 came after 1.19). 1.19 (and probably earlier versions, but not 1.1) had #clone which was primitive only and #shallowCopy which didn't use the primitive. Morphic was being ported to Squeak at the time and it was the only user of #clone. Morphs were copied by #clone which was pretty fast, while other objects used #shallowCopy. Later the use of #clone started to spread, until primitive 148 was added to #shallowCopy. Sends of #clone were replaced with #shallowCopy and #copy, but #clone was kept, probably for backwards compatibility. > > #clone and #shallowCopy have a difference in their semantics. If the vm cannot allocate enough space for the new object, #clone raises an error immediately, while #shallowCopy signals the low space semaphore, so the image or the user can do something, then retries the copying. > > > Levente > >> >>> >>> This is exactly the same problematic as with #=. There can't be just >>> one #=. Other clients might consider other things when comparing >>> objects. >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 13, 2010

Re: [Pharo-project] clone vs shallowCopy

by Lukas Renggli

> #clone and #shallowCopy have a difference in their semantics. If the vm > cannot allocate enough space for the new object, #clone raises an error > immediately, while #shallowCopy signals the low space semaphore, so the > image or the user can do something, then retries the copying. Do we really need that? It would be cool to merge #clone and #shallowCopy, and all the different #deepCopy* instances. Also the implementation of #deepCopy might need some cleanup, it seems to be rather complicated for such a trivial task of copying a object graph. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 13, 2010

Re: [Pharo-project] [ANN] WorkingSet

by StÃ©phane Ducasse

On Jan 13, 2010, at 2:56 AM, Romain Robbes wrote: > > On Jan 12, 2010, at 5:59 PM, Simon Denier wrote: > >> >> Yes! Many thanks Romain, I wanted something like that for the past 6 months (cf ESUG'09 ;)) >> >> It's good to see that now, dev tools are also starting to move. >> >> Two remarks: >> - it seems like it replaces a bit Algernon in its features and user interaction. Am I right? Is this intended? > > hum ... I didn't try Algernon, actually. What I know is that it replaces my antique "Teleporter", which was included in BrowserBooster. > >> - do you plan to have multiple working sets (only one being active at any time)? This would allow one for switching between different contexts/projects while working in a image, and perhaps even sharing with other users (a bit like Mylyn) > > Yes, that would be nice. It's on the radar :-) > >> Future work: integration in the browser :) >> > > How do you envision that? I tried to not be too browser-specific, as these things are moving targets. I would not integrate that in browser because it makes the state machine of this brittle tools brittler and like that you can focus on working set functionality vs browser bugs :) > > Romain > >> >> >> On 11 janv. 2010, at 16:42, Romain Robbes wrote: >> >>> Dear list, >>> >>> I've been working on a small tool to help people navigate their code in Pharo. >>> WorkingSet tracks the entities you've changed recently, and lets you access them quickly. >>> >>> Load WorkingSet with: >>> Gofer new >>> squeaksource: 'WorkingSet'; >>> package: 'WorkingSet'; >>> load. >>> >>> Once loaded, press CMD-1 to activate or dismiss it. A User interface pops up, with the following key mappings: >>> -H to get this help message. >>> -1-9 to select a recently changed class or method (depending on which list is highlighted). >>> -TAB to select methods, or the text field. >>> -Left/Right arrow keys to select classes, methods, or text field. >>> -Up/Down arrow keys to select an item in the list of classes or methods. >>> -ENTER in the text field to navigate to the entity you typed. >>> -ENTER or SPACE in a class or method list to select the selected item. >>> -U to browse the users of an entity (methods: senders, classes: references). >>> -S to browse the siblings of an entity (methods: implementors, classes: hierarchy). >>> -K to close all windows opened by WorkingSet. >>> -L & R to shift the WorkingSet window left or right. (in case you use several screens). >>> -ESC or CMD-1 to dismiss WorkingSet. >>> >>> The text field allows you to enter classes and methods which are not present in your working >>> set. You can enter multiple classes/methods at once by separating them with spaces. >>> >>> Enjoy! >>> Romain >>> -- >>> Romain Robbes >>> http://www.inf.unisi.ch/phd/robbes >>> >>> >>> _______________________________________________ >>> 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 > > -- > Romain Robbes > http://www.inf.unisi.ch/phd/robbes > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 13, 2010

Re: [Pharo-project] I cannot believe that Browser is relying on Object>>initialExtent

by Schwab,Wilhelm K

Stef, Agreed - Object is not a good home for methods that clearly have no place there. I'm not excusing the poor practice, but I _think_ I understand how it came about. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Wednesday, January 13, 2010 2:33 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] I cannot believe that Browser is relying on Object>>initialExtent :) I really think that putting a method in object just because may be at one point a wrong object may receive a message should be avoided. Just already puting initialExtent into CodeHolder fixes some use cases.... > Stef, > > And you were ready to give up on Pharo... :) :) Now I start to have fun and I feel that the board is moving and ready for several turn around the earth (funny for a lighthouse). > A lot of Squeak code looks like it was written w/o thought of exceptions. There is probably good reason for that, in that much of it comes from before the days of structured exception handling, weak collections, etc. In fairness, having a browser, or worse yet a debugger, quit over a bad receiver problem can turn ugly. By putting things in Object, those types of bugs would be largely avoided. I'm not saying it is a good way to work, but it is wide spread in Squeak. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > StÃ©phane Ducasse > Sent: Tuesday, January 12, 2010 4:36 PM > To: Pharo-project(a)lists.gforge.inria.fr Development > Subject: [Pharo-project] I cannot believe that Browser is relying on > Object>>initialExtent > > argh....... > May be not putting everything in Object would help. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 13, 2010

Re: [Pharo-project] Undo/Redo [was: Re: Object Buffer (implementation tryout)]

by John M McIntosh

Er yes, that would be because it works? There is some 2.0 video at http://sophiecommons.blip.tv/ which appears to work. The old site is at http://sophieproject.cntv.usc.edu/, open site at http://opensophie.com/ We could have used media like below 2 years ago. At ESUG I'm sure someone remarked why don't folks doing presentations at smalltalk conferences use Sophie? On 2010-01-12, at 11:16 PM, Serge Stinckwich wrote: > It look like there are still using the 1.0 version for Sophie advertisement : > http://www.youtube.com/watch?v=KLTcdffTigA > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 13, 2010

Re: [Pharo-project] MC case sensitity and sub-packages

by StÃ©phane Ducasse

On Jan 13, 2010, at 1:39 AM, Schwab,Wilhelm K wrote: > Brian and others have told me that I could expect to define packages such as > > DolphinCompatibility-ODBC > DolphinCompatibility-Streams > > and save them all using DolphinCompatibility, or save just one specific part by giving the full name, such as DolphinCompatibility-ODBC. I was unable to make it work reliably, and I think I might have just figured out why. I really encourage you to save them as separate packages if you want to load and save them all build a metacelloConfig (not difficult and worth). don;t define a package DolphinCompatibility in addition (else you will get in trouble because your classes will be saved somehow twice)., I hate this pattern matching behavior. > Assertion: package names and class names must agree up to case; method categories (*packageName-etc) appear to be more forgiving. > > It further appears that once one messes up by naming a category and package Dolphincompatibility instead of DolphinCompatibility, the only way to fix it is to delete the working copy of the package and re-create it with the correct case after renaming the category, or something like that. probably I do not like that part of the system > > Does that sound right? Am I missing something that might cost me later? > > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 13, 2010

Re: [Pharo-project] I cannot believe that Browser is relying on Object>>initialExtent

by StÃ©phane Ducasse

:) I really think that putting a method in object just because may be at one point a wrong object may receive a message should be avoided. Just already puting initialExtent into CodeHolder fixes some use cases.... > Stef, > > And you were ready to give up on Pharo... :) :) Now I start to have fun and I feel that the board is moving and ready for several turn around the earth (funny for a lighthouse). > A lot of Squeak code looks like it was written w/o thought of exceptions. There is probably good reason for that, in that much of it comes from before the days of structured exception handling, weak collections, etc. In fairness, having a browser, or worse yet a debugger, quit over a bad receiver problem can turn ugly. By putting things in Object, those types of bugs would be largely avoided. I'm not saying it is a good way to work, but it is wide spread in Squeak. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Tuesday, January 12, 2010 4:36 PM > To: Pharo-project(a)lists.gforge.inria.fr Development > Subject: [Pharo-project] I cannot believe that Browser is relying on Object>>initialExtent > > argh....... > May be not putting everything in Object would help. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 13, 2010

Re: [Pharo-project] Undo/Redo [was: Re: Object Buffer (implementation tryout)]

by Serge Stinckwich

It look like there are still using the 1.0 version for Sophie advertisement : http://www.youtube.com/watch?v=KLTcdffTigA 2010/1/13 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > Yes, it's in the category "Sophie-Undo" > > If I consider the class AbstractUndoRecord > We hung 67 subclasses off it, which gives you an idea of the complexity of Â we what were doing (60 some UI actions), but also the fact it could handle it.. > > UndoManager class comment: > > UndoManager manages execution and storing of UndoRecords through #doAndAddRecord:. > It allows hierarchical grouping of UndoRecords through #openRecordGroup, #openRecordGroupNamed: and #closeRecordGroup. > Undo and redo is invoked by #undo and #redo. > > See UndoManagerTest for someExamples. > > Structure: > Â undoHistory Â Â Â Â Â Â OrderedCollection -- holds UndoRecords for undo > Â redoHistory Â Â Â Â Â Â Â Â Â Â OrderedCollection -- holds UndoRecords for redo > Â maxHistoryLength Â Â Â Integer -- Old UndoRecords in undoHistory are removed to keep it within given limits (0 for no Limit) > Â groupStack Â Â Â Â Â Â Â Â Â Â OrderedCollection -- temporary dataStructure to manage hierarchical grouping of UndoRecords > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â by #openRecordGroup and closeRecordGroup > Â historyInvalid Â Â Â Â Boolean -- flag to indicate, that the history is invalid and it must be deleted including the groupStack > > > On 2010-01-12, at 9:52 PM, Martin McClure wrote: > >> John M McIntosh wrote: >> >> [...] >>> >>> PS if anyone is interested the Undo/Redo Logic that Impara did for >>> Sophie was very well received, easy to use, and we could build a book >>> from scratch >>> then undo the entire creation, then redo it. This sounds complex, it >>> was. However the framework made it easy, one piece at a time... >>> Perhaps someone should harvest that since it *was* generic. >> >> Ooh, nice. A good undo/redo framework would be *so* *very* good to have. >> I'm afraid I can't be the one to harvest it, not anytime soon anyhow, >> but I hope someone picks it up. >> >> >> Regards, >> >> -Martin > > > > Â Â Â Â AbstractUndoRecord #() > Â Â Â Â Â Â Â Â Â Â Â Â SophieAddContentRootRecord #('contentRoot' 'book') > Â Â Â Â Â Â Â Â Â Â Â Â SophieAddDeleteStickyRecord #('sticky' 'page') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieAddStickyRecord #() > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieDeleteStickyRecord #() > Â Â Â Â Â Â Â Â Â Â Â Â SophieAddEmbedBookRecord #('book' 'bookToEmbed') > Â Â Â Â Â Â Â Â Â Â Â Â SophieAddLeafNodeRecord #('book' 'leafNode' 'contentIndexPosition') > Â Â Â Â Â Â Â Â Â Â Â Â SophieAddStickiesRecord #('stickies' 'book') > Â Â Â Â Â Â Â Â Â Â Â Â SophieApplyFrameLocationStyleAttributesRecord #('bookModel' 'anchor' 'styleAttributes' 'oldStyleAttributes' 'page') > Â Â Â Â Â Â Â Â Â Â Â Â SophieApplyPageTemplateRecord #('page' 'template' 'undoData' 'redoData' 'allRemovedFrames') > Â Â Â Â Â Â Â Â Â Â Â Â SophieApplyParagraphStyleAttributesRecord #('book' 'marker' 'styleAttributes' 'oldStylesAttributes') > Â Â Â Â Â Â Â Â Â Â Â Â SophieApplyParagraphStyleRecord #('book' 'marker' 'style' 'oldStyles') > Â Â Â Â Â Â Â Â Â Â Â Â SophieApplyStyleToRangeRecord #('book' 'marker' 'styleAttributes' 'oldRangesStylesCollection') > Â Â Â Â Â Â Â Â Â Â Â Â SophieBookExtentUndoRecord #('bookModel' 'newExtent' 'oldExtent') > Â Â Â Â Â Â Â Â Â Â Â Â SophieBookStatisticRecord #('book' 'newStatistic' 'oldStatistic') > Â Â Â Â Â Â Â Â Â Â Â Â SophieDeleteContentRangeRecord #('book' 'marker' 'positionAfter' 'partialTree') > Â Â Â Â Â Â Â Â Â Â Â Â SophieEmbeddedBookUndoRecord #('ebook' 'embeddedBookResource' 'embeddedBookMapEntry') > Â Â Â Â Â Â Â Â Â Â Â Â SophieEmbeddedLinkedToBookUndoRecord #('ebook' 'embeddedBookMapEntry' 'embeddedBookResource') > Â Â Â Â Â Â Â Â Â Â Â Â SophieFrameRecord #('bookModel' 'frame') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieFrameZOrderRecord #('page' 'forward') > Â Â Â Â Â Â Â Â Â Â Â Â SophieFrameStyleUndoRecord #('bookModel' 'frame' 'attributes' 'state') > Â Â Â Â Â Â Â Â Â Â Â Â SophieFrameToTemplateRecord #('bookModel' 'frame' 'page' 'zIndex' 'reversed') > Â Â Â Â Â Â Â Â Â Â Â Â SophieInsertCharacterRecord #('book' 'character' 'position' 'positionAfter' 'style') > Â Â Â Â Â Â Â Â Â Â Â Â SophieInsertPageBreakRecord #('book' 'position' 'marker') > Â Â Â Â Â Â Â Â Â Â Â Â SophieInsertParagraphBreakRecord #('book' 'position' 'marker' 'characterStyle') > Â Â Â Â Â Â Â Â Â Â Â Â SophieLinkActionRecord #('book' 'target' 'action' 'actionIndex') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieLinkActionAddRecord #() > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieLinkActionRemoveRecord #() > Â Â Â Â Â Â Â Â Â Â Â Â SophieLinkRecord #('book' 'target') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieFrameTriggerCleanupRecord #('cleanupStuff') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieLinkActionCloneRecord #('source' 'oldActions') > Â Â Â Â Â Â Â Â Â Â Â Â SophieMarkerAddDeleteRecord #('marker' 'book') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieMarkerAddMarkersRecord #() > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieMarkerAddRecord #() > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieMarkerDeleteRecord #('actions' 'markerSet') > Â Â Â Â Â Â Â Â Â Â Â Â SophieMarkerRangeRecord #('book' 'marker' 'newStart' 'newStop' 'oldStart' 'oldStop') > Â Â Â Â Â Â Â Â Â Â Â Â SophiePageRecord #('bookModel' 'page') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieFlowOrderChangeRecord #('frame' 'index' 'flow') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophiePageStyleRecord #('styleAttributes') > Â Â Â Â Â Â Â Â Â Â Â Â SophiePageUndoRecord #('spine' 'index' 'page') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieInsertPageRecord #() > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieMovePageRecord #('oldIndex') > Â Â Â Â Â Â Â Â Â Â Â Â SophiePasteFromImporterRecord #('book' 'importer' 'position' 'marker' 'partialTree') > Â Â Â Â Â Â Â Â Â Â Â Â SophiePromoteTemplateOverridesRecord #('book' 'pageTemplateFrame' 'page' 'frameMap' 'deletedTemplateFrames' 'overrideFrames' 'templateFrameFramesFromOverideFrames' 'frameOverrides' 'frameStyleOverrides' 'frameActionsOverrides' 'oldTemplateFrameFrames' 'oldPageFlowMap' 'oldTemplateFlowMap' 'oldPageTemplate' 'newTemplateFrameFrames' 'newPageFlowMap' 'newPageTemplate' 'allRemovedFrames' 'removedOverrideFrameContents') > Â Â Â Â Â Â Â Â Â Â Â Â SophieRegisterFlowRecord #('spine' 'flowID' 'content' 'contentID' 'flow') > Â Â Â Â Â Â Â Â Â Â Â Â SophieRemoveContentRootRecord #('contentRoot' 'book') > Â Â Â Â Â Â Â Â Â Â Â Â SophieRemoveFlowRecord #('spine' 'flow') > Â Â Â Â Â Â Â Â Â Â Â Â SophieRemoveFrameRecord #('bookModel' 'page' 'frame' 'wasLocalOverride') > Â Â Â Â Â Â Â Â Â Â Â Â SophieRemoveLeafNodeRecord #('book' 'leafNode' 'oldContentIndexPosition') > Â Â Â Â Â Â Â Â Â Â Â Â SophieRemovePagesRecord #('spine' 'indices' 'pages') > Â Â Â Â Â Â Â Â Â Â Â Â SophieReplaceLibraryTemplateRecord #('book' 'template' 'newTemplate') > Â Â Â Â Â Â Â Â Â Â Â Â SophieReplaceTemplateRecord #('book' 'template' 'oldTemplateCopy' 'newTemplate') > Â Â Â Â Â Â Â Â Â Â Â Â SophieResourceUndoRecord #('resources') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieResourceDeleteRecord #('player') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieResourceImportStreamRecord #('resourceManager' 'mimeType' 'stream') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieResourceImportURIRecord #('resourceManager' 'uri') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieResourceLinkToURIRecord #() > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieResourceStoreRecord #('book' 'object' 'metaKey') > Â Â Â Â Â Â Â Â Â Â Â Â SophieSpineStateDeltaRecord #('book' 'spine' 'addedPages' 'removedPages') > Â Â Â Â Â Â Â Â Â Â Â Â SophieSpineStateRecord #('book' 'spine' 'prevState' 'postState') > Â Â Â Â Â Â Â Â Â Â Â Â SophieTimelineUndoRecord #('timelinePlayer') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieTimelineUndoAbstractEventsRecord #('events') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieTimelineUndoAddEventsRecord #() > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieTimelineUndoDeleteEventsRecord #() > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieTimelineUndoAddTimeline #('timeline' 'book') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieTimelineUndoDeleteTimeline #() > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieTimelineUndoEventsMoveRecord #('undoData') > Â Â Â Â Â Â Â Â Â Â Â Â SophieTriggerObjectCleanupRecord #('triggerObject' 'undoInformations') > Â Â Â Â Â Â Â Â Â Â Â Â SophieUpdateLibraryStyleRecord #('book' 'newStyle' 'styleName' 'oldStyle') > Â Â Â Â Â Â Â Â Â Â Â Â UndoRecord #('undoable' 'doMessage' 'undoMessage' 'description') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieFrameUndoRecord #('bookModel' 'frame') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieLibraryResourceUndoRecord #('bookModel') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophiePageInvalidationRecord #('bookModel' 'page') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieFrameAlignmentUndoRecord #('groupFrame' 'framesAndOldPositions' 'framesAndNewPositions') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieTriggerMarkerUndoRecord #('bookModel' 'marker') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â UndoRecordWithPostMessage #('postMessage') > Â Â Â Â Â Â Â Â Â Â Â Â UndoRecordGroup #('description' 'subRecords') > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SophieFrameGroupUndoRecord #('frameGroup' 'bookModel') > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Â Twitter: Â squeaker68882 > Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

Jan. 13, 2010