December 2008 - Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: [squeak-dev] [Ann] Monticello15 File support (alpha)

by Damien Cassou

---------- Forwarded message ---------- From: Keith Hodges <keith_hodges(a)yahoo.co.uk> Date: Sun, Dec 7, 2008 at 6:03 AM Subject: [squeak-dev] [Ann] Monticello15 File support (alpha) To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Seasons Greetings Everyone, Monticello 1.5 "FINALLY" supports files. I have set LevelPlayingField to load this new version of MC1.5 If anyone has any problems with it do let me know asap. Keith ======== PackageInfo comment reads: External Files Support ================ The default implementation of the two methods below considers all files and directories (with their contents) matching the package name to be part of the package. #externalFiles #externalFilesMatches e.g. package name 'Release'. files matching would include: Release.text Release/Introduction.text Release/Tutorial/ch1.text External Files Support - Monticello ======================================== *Only file based repositories (i.e. .mcz files) are supported at present Since your external files will change far less than your code, it is recommended that you use a separate package to manage files in order to save space and time. Files are included in the .mcz (which is a standard zip archive) as files/* according to the pattern files/<uuid>/<path>/<to>/<file> *note: the uuid will change with every snapshot, it is unique to that file in that snapshot *note: in changes browsers the file is considered to be changed if the fileSize has changed. Snapshotting a package with files uses a temporary directory in package-cache/files The #flushCachedVersions menu item deletes this directory. -- Damien Cassou http://damiencassou.seasidehosting.st

Dec. 8, 2008

[Pharo-project] Change in HandMorph and HandMorphForReplay causing primitive error

by Hilaire Fernandes

Hello, I am using a modified version of the EventRecorderMoprh to record learners activities. With latest Pharo (#183) I am facing several problems (compatibilty ones as I expected it). The most serious one is about primitive error with something related to hardware cursor throught the VM. The enclosed debug log may be more meaning full. Does it recall something to the Pharo hackers I can dig into? -- http://blog.ofset.org/hilaire

Dec. 7, 2008

[Pharo-project] Alien on powerpc

by John M McIntosh

I've check in a number of changes into the main SVN tree, and into the Alien MC to start to providing support for PowerPC. I do have a somewhat functional api on the cpu type now, we are still working some details about how to deal with Float/Double versus integer, and I've yet to tackle the callback logic assembler. Tomorrow if I make more progress I'll check in the assembler/glue code for the PowerPC call pattern. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Dec. 7, 2008

Re: [Pharo-project] Magma + FreeType font

by Hilaire Fernandes

Some correction, the VM also crashes with former (original) image. I guess I did not see the crash on the original image because the Morph was still in memory when I was fetching it from the database. So it is very likely there is something wrong from me in the way I extended the LogicalFont persistence with proxy. I will look at that code but I don't understand much the persistence mechanism of the object, I will need some light from Chris. Hilaire 2008/12/6 Hilaire Fernandes <hilaire(a)ofset.org>: > Hello Andrew, > > Thanks for you tips and to take time to answer to me. > > I may need to describe the context of the second image I am using to > fetch the persisted Morph. > It is the same image, in a different folder, without source and change files. > But when fetching the Morph from this image, the whole VM crash (see > the previous log file). > If I fetch the morph from the former image, it is fine. > > Does it indicate to you some causes of the problem? > > Hilaire > > > 2008/12/6 Andrew Tween <amtween(a)hotmail.com>: >> Hi Hilaire, >> >>> Date: Sat, 6 Dec 2008 12:42:16 +0100 >>> From: hilaire(a)ofset.org >>> To: amtween(a)hotmail.com; pharo-project(a)lists.gforge.inria.fr >>> Subject: Magma + FreeType font >>> >>> I am now using Pharo with FreeType fonts + Magmar41.1. >>> >>> The font I am using use the LogicalFont class (this is how I declare in >>> my code the TT font I am using). >>> >>> I have extended LogicalFont to get it persisted: >>> >>> First with a new way to instantiate it: >>> >>> LogicalFont class>>familyName: familyName pointSize: pointSize emphasis: >>> code >>> >>> ^ (self familyName: pointSize pointSize: pointSize) emphasis: code; >>> yourself >>> >>> Then three methods for persistence, I copied the existing TType class >>> persistence methods: >>> >>> maAsStorageObject >>> "I am about to be written on an object file. Write a >>> reference to a known FontSet in the other system instead." >>> "a path to me" >>> ^ DiskProxy >>> global: #LogicalFont >>> selector: #familyName:pointSize:emphasis: >>> args: { >>> (self familyName). >>> (self pointSize). >>> (self emphasis) >>> } >>> >> >> Have a look at LogicalFont>>#objectForDataStream: >> It is doing something similar to your method, and is creating a DiskProxy >> for DataStreams... >> DiskProxy global: #LogicalFont selector: >> #familyName:fallbackFamilyNames:pointSize:stretchValue:weightValue:slantValue: >> args: {self familyName. self fallbackFamilyNames. self pointSize. self >> stretchValue. self weightValue. self slantValue}. >> >> Your code looks ok to me and should work fine; but you might try creating a >> DiskProxy in the manner above, and see if that cures your problem. >> >> If that doesn't fix it, then do you have an image (+ database) that you can >> share so I can investigate further? >> >> Thanks, >> Andy >> >> >>> maUsesStandardStorage >>> >>> ^ false >>> >>> maWantsPreSerialization >>> ^ true >>> >>> >>> Basically these methods are used when I am persisting in the Magma >>> Database a morph with some text. >>> >>> Now when I am fetching such Morph from the Magma data base in another >>> image (with the same code extension) I got a Segmentation fault (the >>> trace is included there). >>> >>> The crash is clearly happening in FreeType code, in the primitive >>> called from FT2Face>setPixelWidth:height: >>> >>> Probably I got something wrong in my persistence code, I will be more >>> than happy with any kind of tips. >>> >>> Thanks, >>> >>> Hilaire >> >> >> ________________________________ >> Win John Lewis vouchers with BigSnapSearch.com Search now > > > > -- > http://blog.ofset.org/hilaire > -- http://blog.ofset.org/hilaire

Dec. 6, 2008

Re: [Pharo-project] Magma + FreeType font

by Hilaire Fernandes

Hello Andrew, Thanks for you tips and to take time to answer to me. I may need to describe the context of the second image I am using to fetch the persisted Morph. It is the same image, in a different folder, without source and change files. But when fetching the Morph from this image, the whole VM crash (see the previous log file). If I fetch the morph from the former image, it is fine. Does it indicate to you some causes of the problem? Hilaire 2008/12/6 Andrew Tween <amtween(a)hotmail.com>: > Hi Hilaire, > >> Date: Sat, 6 Dec 2008 12:42:16 +0100 >> From: hilaire(a)ofset.org >> To: amtween(a)hotmail.com; pharo-project(a)lists.gforge.inria.fr >> Subject: Magma + FreeType font >> >> I am now using Pharo with FreeType fonts + Magmar41.1. >> >> The font I am using use the LogicalFont class (this is how I declare in >> my code the TT font I am using). >> >> I have extended LogicalFont to get it persisted: >> >> First with a new way to instantiate it: >> >> LogicalFont class>>familyName: familyName pointSize: pointSize emphasis: >> code >> >> ^ (self familyName: pointSize pointSize: pointSize) emphasis: code; >> yourself >> >> Then three methods for persistence, I copied the existing TType class >> persistence methods: >> >> maAsStorageObject >> "I am about to be written on an object file. Write a >> reference to a known FontSet in the other system instead." >> "a path to me" >> ^ DiskProxy >> global: #LogicalFont >> selector: #familyName:pointSize:emphasis: >> args: { >> (self familyName). >> (self pointSize). >> (self emphasis) >> } >> > > Have a look at LogicalFont>>#objectForDataStream: > It is doing something similar to your method, and is creating a DiskProxy > for DataStreams... > DiskProxy global: #LogicalFont selector: > #familyName:fallbackFamilyNames:pointSize:stretchValue:weightValue:slantValue: > args: {self familyName. self fallbackFamilyNames. self pointSize. self > stretchValue. self weightValue. self slantValue}. > > Your code looks ok to me and should work fine; but you might try creating a > DiskProxy in the manner above, and see if that cures your problem. > > If that doesn't fix it, then do you have an image (+ database) that you can > share so I can investigate further? > > Thanks, > Andy > > >> maUsesStandardStorage >> >> ^ false >> >> maWantsPreSerialization >> ^ true >> >> >> Basically these methods are used when I am persisting in the Magma >> Database a morph with some text. >> >> Now when I am fetching such Morph from the Magma data base in another >> image (with the same code extension) I got a Segmentation fault (the >> trace is included there). >> >> The crash is clearly happening in FreeType code, in the primitive >> called from FT2Face>setPixelWidth:height: >> >> Probably I got something wrong in my persistence code, I will be more >> than happy with any kind of tips. >> >> Thanks, >> >> Hilaire > > > ________________________________ > Win John Lewis vouchers with BigSnapSearch.com Search now -- http://blog.ofset.org/hilaire

Dec. 6, 2008

Re: [Pharo-project] Magma + FreeType font

by Andrew Tween

Hi Hilaire,> Date: Sat, 6 Dec 2008 12:42:16 +0100> From: hilaire(a)ofset.org> To: amtween(a)hotmail.com; pharo-project(a)lists.gforge.inria.fr> Subject: Magma + FreeType font> > I am now using Pharo with FreeType fonts + Magmar41.1.> > The font I am using use the LogicalFont class (this is how I declare in > my code the TT font I am using).> > I have extended LogicalFont to get it persisted:> > First with a new way to instantiate it:> > LogicalFont class>>familyName: familyName pointSize: pointSize emphasis: > code> > ^ (self familyName: pointSize pointSize: pointSize) emphasis: code; yourself> > Then three methods for persistence, I copied the existing TType class > persistence methods:> > maAsStorageObject> "I am about to be written on an object file. Write a> reference to a known FontSet in the other system instead."> "a path to me"> ^ DiskProxy> global: #LogicalFont> selector: #familyName:pointSize:emphasis:> args: {> (self familyName).> (self pointSize).> (self emphasis)> }> Have a look at LogicalFont>>#objectForDataStream: It is doing something similar to your method, and is creating a DiskProxy for DataStreams... DiskProxy global: #LogicalFont selector: #familyName:fallbackFamilyNames:pointSize:stretchValue:weightValue:slantValue: args: {self familyName. self fallbackFamilyNames. self pointSize. self stretchValue. self weightValue. self slantValue}. Your code looks ok to me and should work fine; but you might try creating a DiskProxy in the manner above, and see if that cures your problem. If that doesn't fix it, then do you have an image (+ database) that you can share so I can investigate further? Thanks, Andy > maUsesStandardStorage> > ^ false> > maWantsPreSerialization> ^ true> > > Basically these methods are used when I am persisting in the Magma > Database a morph with some text.> > Now when I am fetching such Morph from the Magma data base in another > image (with the same code extension) I got a Segmentation fault (the > trace is included there).> > The crash is clearly happening in FreeType code, in the primitive > called from FT2Face>setPixelWidth:height:> > Probably I got something wrong in my persistence code, I will be more > than happy with any kind of tips.> > Thanks,> > Hilaire _________________________________________________________________ Imagine a life without walls.Â See the possibilities. http://clk.atdmt.com/UKM/go/122465943/direct/01/

Dec. 6, 2008

Re: [Pharo-project] Removing a trait from a class

by StÃ©phane Ducasse

I think that the trait should be used in multiple classes :) > I already tried, but I still cannot reproduce the problem. I take a > fresh 185 image and create a class with two traits and remove a trait > and everything works as expected. > > This is really strange. I wonder where the method with the comment > "This method does not exist." comes from. May be the browser > > > One problem I found occurs when you remove a trait on the class side. > The reason is that Metaclass recently was modified. But this is > something else (and the tests document the problem). > > I think the simplest way to track that down is if you can give me an > image in this state so that I can dig into it. Or even better, if > possible, to explain me how I can reproduce the problem. Take a collection tests and remove a trait stef > > > Adrian > > On Dec 5, 2008, at 16:56 , StÃ©phane Ducasse wrote: > >> adrian when you will work on traits, you should really add two traits >> to a class and remove one to see >> the problem. >> Now I have the traits method inside the class with probably something >> generated. >> >> testCopyEmpty >> "This method does not exist." >> self halt. >> >> On Dec 2, 2008, at 10:18 PM, StÃ©phane Ducasse wrote: >> >>> I was using the package browser >>> >>> Stef >>> >>> On Dec 2, 2008, at 10:11 PM, Adrian Lienhard wrote: >>> >>>> ok, we need to take a closer look at this, >>>> Do you remember which browser you used? If Omnibrowser, do you also >>>> know which one? >>>> Adrian >>>> >>>> On Dec 2, 2008, at 13:58 , StÃ©phane Ducasse wrote: >>>> >>>>> Adrian >>>>> I got some problems during the last smalltalk party at paris. >>>>> my pair programmer quitted the image without saving and when I >>>>> reloaded the changes it was a mess. >>>>> I could not remove methods from a class. The methods were not in >>>>> the method dictionary but their names showed >>>>> up in the browser.... The class organizer had them in. I would >>>>> love to check the classorganizer concept :) >>>>> I could not remove the traits from the class. >>>>> >>>>> Stef >>>>> >>>>> On Dec 2, 2008, at 11:26 AM, Adrian Lienhard wrote: >>>>> >>>>>> Hi Hilaire, >>>>>> >>>>>> Which UI tools do you use? Omnibrowser or the old browser that is >>>>>> shipped with the Core image. >>>>>> Could you try to reproduce the problem in a newer version of >>>>>> Pharo? (10050 is *very* old). >>>>>> >>>>>> I'd like to take a look then. It's strange because we have been >>>>>> using traits for two years now without seeing this problem. So it >>>>>> may indeed be a problem related to the UI that somehow brings >>>>>> traits into an inconsistent state. >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> On Dec 2, 2008, at 11:08 , Hilaire Fernandes wrote: >>>>>> >>>>>>> I can't remove a trait from a class using UI tools. (pharo >>>>>>> 10050) >>>>>>> How can I remove it programmatically ? >>>>>>> >>>>>>> Next with this same class, message from this trait are not >>>>>>> reachable, >>>>>>> the MNU is raised but the hierarchy is not right as IFIETayage1 >>>>>>> is not >>>>>>> a subclass of IFIExoMorph. However IFIExoMorph is using the same >>>>>>> trait >>>>>>> as IFIEtayage. >>>>>>> It looks like there is mismatch in the classes with traits. (see >>>>>>> screenshot) >>>>>>> >>>>>>> Now I realize my last istoa release suffer from this problem :) >>>>>>> >>>>>>> Hilaire >>>>>>> >>>>>>> -- >>>>>>> http://blog.ofset.org/hilaire >>>>>>> <bug-trait.png>_______________________________________________ >>>>>>> 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 >>>> >>> >>> >>> _______________________________________________ >>> 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 >

Dec. 5, 2008

Re: [Pharo-project] Removing a trait from a class

by Adrian Lienhard

I already tried, but I still cannot reproduce the problem. I take a fresh 185 image and create a class with two traits and remove a trait and everything works as expected. This is really strange. I wonder where the method with the comment "This method does not exist." comes from. One problem I found occurs when you remove a trait on the class side. The reason is that Metaclass recently was modified. But this is something else (and the tests document the problem). I think the simplest way to track that down is if you can give me an image in this state so that I can dig into it. Or even better, if possible, to explain me how I can reproduce the problem. Adrian On Dec 5, 2008, at 16:56 , StÃ©phane Ducasse wrote: > adrian when you will work on traits, you should really add two traits > to a class and remove one to see > the problem. > Now I have the traits method inside the class with probably something > generated. > > testCopyEmpty > "This method does not exist." > self halt. > > On Dec 2, 2008, at 10:18 PM, StÃ©phane Ducasse wrote: > >> I was using the package browser >> >> Stef >> >> On Dec 2, 2008, at 10:11 PM, Adrian Lienhard wrote: >> >>> ok, we need to take a closer look at this, >>> Do you remember which browser you used? If Omnibrowser, do you also >>> know which one? >>> Adrian >>> >>> On Dec 2, 2008, at 13:58 , StÃ©phane Ducasse wrote: >>> >>>> Adrian >>>> I got some problems during the last smalltalk party at paris. >>>> my pair programmer quitted the image without saving and when I >>>> reloaded the changes it was a mess. >>>> I could not remove methods from a class. The methods were not in >>>> the method dictionary but their names showed >>>> up in the browser.... The class organizer had them in. I would >>>> love to check the classorganizer concept :) >>>> I could not remove the traits from the class. >>>> >>>> Stef >>>> >>>> On Dec 2, 2008, at 11:26 AM, Adrian Lienhard wrote: >>>> >>>>> Hi Hilaire, >>>>> >>>>> Which UI tools do you use? Omnibrowser or the old browser that is >>>>> shipped with the Core image. >>>>> Could you try to reproduce the problem in a newer version of >>>>> Pharo? (10050 is *very* old). >>>>> >>>>> I'd like to take a look then. It's strange because we have been >>>>> using traits for two years now without seeing this problem. So it >>>>> may indeed be a problem related to the UI that somehow brings >>>>> traits into an inconsistent state. >>>>> >>>>> Adrian >>>>> >>>>> >>>>> On Dec 2, 2008, at 11:08 , Hilaire Fernandes wrote: >>>>> >>>>>> I can't remove a trait from a class using UI tools. (pharo 10050) >>>>>> How can I remove it programmatically ? >>>>>> >>>>>> Next with this same class, message from this trait are not >>>>>> reachable, >>>>>> the MNU is raised but the hierarchy is not right as IFIETayage1 >>>>>> is not >>>>>> a subclass of IFIExoMorph. However IFIExoMorph is using the same >>>>>> trait >>>>>> as IFIEtayage. >>>>>> It looks like there is mismatch in the classes with traits. (see >>>>>> screenshot) >>>>>> >>>>>> Now I realize my last istoa release suffer from this problem :) >>>>>> >>>>>> Hilaire >>>>>> >>>>>> -- >>>>>> http://blog.ofset.org/hilaire >>>>>> <bug-trait.png>_______________________________________________ >>>>>> 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 >>> >> >> >> _______________________________________________ >> 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

Dec. 5, 2008

Re: [Pharo-project] Removing a trait from a class

by StÃ©phane Ducasse

adrian when you will work on traits, you should really add two traits to a class and remove one to see the problem. Now I have the traits method inside the class with probably something generated. testCopyEmpty "This method does not exist." self halt. On Dec 2, 2008, at 10:18 PM, StÃ©phane Ducasse wrote: > I was using the package browser > > Stef > > On Dec 2, 2008, at 10:11 PM, Adrian Lienhard wrote: > >> ok, we need to take a closer look at this, >> Do you remember which browser you used? If Omnibrowser, do you also >> know which one? >> Adrian >> >> On Dec 2, 2008, at 13:58 , StÃ©phane Ducasse wrote: >> >>> Adrian >>> I got some problems during the last smalltalk party at paris. >>> my pair programmer quitted the image without saving and when I >>> reloaded the changes it was a mess. >>> I could not remove methods from a class. The methods were not in >>> the method dictionary but their names showed >>> up in the browser.... The class organizer had them in. I would >>> love to check the classorganizer concept :) >>> I could not remove the traits from the class. >>> >>> Stef >>> >>> On Dec 2, 2008, at 11:26 AM, Adrian Lienhard wrote: >>> >>>> Hi Hilaire, >>>> >>>> Which UI tools do you use? Omnibrowser or the old browser that is >>>> shipped with the Core image. >>>> Could you try to reproduce the problem in a newer version of >>>> Pharo? (10050 is *very* old). >>>> >>>> I'd like to take a look then. It's strange because we have been >>>> using traits for two years now without seeing this problem. So it >>>> may indeed be a problem related to the UI that somehow brings >>>> traits into an inconsistent state. >>>> >>>> Adrian >>>> >>>> >>>> On Dec 2, 2008, at 11:08 , Hilaire Fernandes wrote: >>>> >>>>> I can't remove a trait from a class using UI tools. (pharo 10050) >>>>> How can I remove it programmatically ? >>>>> >>>>> Next with this same class, message from this trait are not >>>>> reachable, >>>>> the MNU is raised but the hierarchy is not right as IFIETayage1 >>>>> is not >>>>> a subclass of IFIExoMorph. However IFIExoMorph is using the same >>>>> trait >>>>> as IFIEtayage. >>>>> It looks like there is mismatch in the classes with traits. (see >>>>> screenshot) >>>>> >>>>> Now I realize my last istoa release suffer from this problem :) >>>>> >>>>> Hilaire >>>>> >>>>> -- >>>>> http://blog.ofset.org/hilaire >>>>> <bug-trait.png>_______________________________________________ >>>>> 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 5, 2008

[Pharo-project] about merge tool

by StÃ©phane Ducasse

Hi I got some problems with the new merge tool - I do not succeed to say which changes I want to keep and reject all the actions are grey - when I click on the small green arrow in bteween the two panes I get an error - the modal interaction make difficult to copy and paste changes in case we want to do that. Stef

Dec. 5, 2008