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

Re: [Pharo-project] RBSpelling errors when class has Pool Dictionary - Re: [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2

by Lukas Renggli

>> They are all not flagged on my machine. Neither with the internal nor >> with the mac spelling. >> > Still flagged here. Seem to be extra ' characters in the check strings. > See Â http://www.flickr.com/photos/8185994@N03/4303501422/sizes/o/ search > strings screen print on Flickr The words you show are simply not in the dictionary: - These words I don't know, but I am not a native speaker: ftmch drepehs - The implementation excepts to have natural language in comments, not code. Thus this is not split: goodVariable - I don't know about apostrophes at the end of the word. Should they be removed? methods'' don't' RB' IT' OK' Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 25, 2010

Re: [Pharo-project] [newbee] How do I save the contents of aWorkspace?

by Gary Chambers

The base UIManager code has no accessors for file saving, though Polymorph does support such a dialog... Try UITheme builder fileSave: "Your dialog title here' Regards, Gary ----- Original Message ----- From: "George Herolyants" <george.herolyants(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, January 25, 2010 11:07 AM Subject: Re: [Pharo-project] [newbee] How do I save the contents of aWorkspace? Bill, Mariano thanks for the feedback! 2010/1/21 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Thanks for doing this! How did you modify the menu? I have *no* clue how > to do that. There is a method addModelItemsToWindowMenu:, which do the job. > Two comments, the first horribly pedantic. The prompt for the file name > reads "Enter file name to save the workspace to" - we have no shortage of > dangling prepositions. "Ener file name" would be preferable. I agree. > More substantively, it does not prompt for a directory. I agree that the > image directory is the most likely default, but Pinesoft probably > has > given us a suitable file dialog, and if not, we should identify the > omission. There is such a dialog. FileDialogWindow. I use it when I ask user for file name to open. But I didn't find any way to force this dialog to ask for the new file name. I may be wrong, but it only allows user to choose from existing file names. Some comments from more experienced people would be helpful though. George _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 25, 2010

Re: [Pharo-project] [newbee] How do I save the contents of a Workspace?

by Schwab,Wilhelm K

George, Thanks for the tip on the menus. If FileDialogWindow is indeed missing a way to create a new name, I suspect Gary will eventually add that ability because it is important for end users wanting to save files. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of George Herolyants Sent: Monday, January 25, 2010 6:07 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [newbee] How do I save the contents of a Workspace? Bill, Mariano thanks for the feedback! 2010/1/21 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Thanks for doing this! Â How did you modify the menu? Â I have *no* clue how to do that. There is a method addModelItemsToWindowMenu:, which do the job. > Two comments, the first horribly pedantic. Â The prompt for the file name reads "Enter file name to save the workspace to" - we have no shortage of dangling prepositions. Â "Ener file name" would be preferable. I agree. > More substantively, it does not prompt for a directory. Â I agree that the image directory is the most likely default, but Pinesoft probably > has given us a suitable file dialog, and if not, we should identify the omission. There is such a dialog. FileDialogWindow. I use it when I ask user for file name to open. But I didn't find any way to force this dialog to ask for the new file name. I may be wrong, but it only allows user to choose from existing file names. Some comments from more experienced people would be helpful though. George _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 25, 2010

Re: [Pharo-project] [newbee] How do I save the contents of a Workspace?

by George Herolyants

Bill, Mariano thanks for the feedback! 2010/1/21 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Thanks for doing this! Â How did you modify the menu? Â I have *no* clue how to do that. There is a method addModelItemsToWindowMenu:, which do the job. > Two comments, the first horribly pedantic. Â The prompt for the file name reads "Enter file name to save the workspace to" - we have no shortage of dangling prepositions. Â "Ener file name" would be preferable. I agree. > More substantively, it does not prompt for a directory. Â I agree that the image directory is the most likely default, but Pinesoft probably > has given us a suitable file dialog, and if not, we should identify the omission. There is such a dialog. FileDialogWindow. I use it when I ask user for file name to open. But I didn't find any way to force this dialog to ask for the new file name. I may be wrong, but it only allows user to choose from existing file names. Some comments from more experienced people would be helpful though. George

Jan. 25, 2010

Re: [Pharo-project] Monticello diff between chosen revisions isbroken

by Gary Chambers

The "Diff" button on the Monticello repository browser does what its balloon help says... 'Create an equivalent version based on an earlier release'. This is a diff version. I never use them as they can be confusing :-) If you want to compare two existing versions you should: 1. Open Monticello Browser 2. Select a repo 3. click open 4. Select a revision, not the latest one 5. Click HISTORY 6. chose an ancestor from the list Regards, Gary ----- Original Message ----- From: Mariano Martinez Peck To: Pharo-project(a)lists.gforge.inria.fr Cc: Lukas Renggli Sent: Sunday, January 24, 2010 12:59 PM Subject: Re: [Pharo-project] Monticello diff between chosen revisions isbroken On Sat, Jan 23, 2010 at 9:51 PM, Stefan Marr <pharo(a)stefan-marr.de> wrote: Hi: In the current dev image (10508), Monticello is broken with respect to showing the differences of between chosen revisions. However, that seems to be broken already in 10496. (and maybe earlier) To reproduce: 1. Open Monticello Browser 2. Select a repo 3. click open 4. Select a revision, not the latest one 5. Click diff 6. chose an ancestor from the list Now you got a window 'Version: ...5' Saying (Diff against ...2) Here I would expect the changes button to open a window showing the changes between the chosen revisions, but it always diffs against the latest version. Yes, I could reproduce the problem. Can you open a ticket ? Maybe Lukas Monticello guru can help us ? hahaha Cheers Mariano Best 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 3956 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 ------------------------------------------------------------------------------ _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 25, 2010

Re: [Pharo-project] RBSpelling errors when class has Pool Dictionary - Re: [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2

by Stan Shepherd

Lukas Renggli wrote: > > 'rong' is in the dictionary as a correct word thus it is correct. ... > OK, when I use a different misspelling those tests pass. >> 'IT' 'OK and 'don't' are all flagged - don't is not flagged. Is this your >> preferred behaviour? > > They are all not flagged on my machine. Neither with the internal nor > with the mac spelling. > Still flagged here. Seem to be extra ' characters in the check strings. See http://www.flickr.com/photos/8185994@N03/4303501422/sizes/o/ search strings screen print on Flickr ...Stan -- View this message in context: http://n2.nabble.com/BetaTesting-ANN-Pharo1-0-10507-rc2dev10-01-2-tp4440307… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 25, 2010

Re: [Pharo-project] about imageSegments

by Adrian Lienhard

On Jan 25, 2010, at 10:24 , Igor Stasenko wrote: > 2010/1/25 Adrian Lienhard <adi(a)netstyle.ch>: >> On Jan 25, 2010, at 09:57 , Mariano Martinez Peck wrote: >> >>> On Mon, Jan 25, 2010 at 9:02 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>> >>>> Hi Stef >>>> >>>> We can move the few classes related to image segments into a separate >>>> package in SqueakSource. The system (ideally) does not depend on them so it >>>> should not be too hard to package them separately. >>>> >>>> >>> There are several things I would like to say: >>> >>> - The ImageSegment code really suc.. and it is very difficult to understand, >>> maintain and test. It is full of etoys, morphic, project and other stuff. >>> - There are a lot of methods that do a lot of black magic >>> - The code is VERY fragile and may be broke any time (if it is not already >>> broken) >>> >>> However, >>> >>> - Some people use it >>> - It is fast >> >> I think image segments is a very nice idea and it works very well if you know how to use them. The core, which is used for basic store/load, is not that complicated. But image segments have been hacked in ugly ways for project persistency. Hence, there is a lot of complexity that is not needed. >> > > Just one question: Why it is an ImageSegments which been hacked, but > not a Project themselves? Probably because it was easier that way ;). As far as I understand a lot of code deals with storing presenters (Etoys) and projects/morphs in clever ways. This is additional behavior that you don't need (anymore). I think if we remove this, we get a very small class that is much simpler to understand and use. Adrian

Jan. 25, 2010

Re: [Pharo-project] about imageSegments

by Igor Stasenko

2010/1/25 Adrian Lienhard <adi(a)netstyle.ch>: > On Jan 25, 2010, at 09:57 , Mariano Martinez Peck wrote: > >> On Mon, Jan 25, 2010 at 9:02 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> >>> Hi Stef >>> >>> We can move the few classes related to image segments into a separate >>> package in SqueakSource. The system (ideally) does not depend on them so it >>> should not be too hard to package them separately. >>> >>> >> There are several things I would like to say: >> >> - The ImageSegment code really suc.. and it is very difficult to understand, >> maintain and test. It is full of etoys, morphic, project and other stuff. >> - There are a lot of methods that do a lot of black magic >> - The code is VERY fragile and may be broke any time (if it is not already >> broken) >> >> However, >> >> - Some people use it >> - It is fast > > I think image segments is a very nice idea and it works very well if you know how to use them. The core, which is used for basic store/load, is not that complicated. But image segments have been hacked in ugly ways for project persistency. Hence, there is a lot of complexity that is not needed. > Just one question: Why it is an ImageSegments which been hacked, but not a Project themselves? >> If you ask if we should remove it form core, I would say: >> >> - It won't very VERY easy to completely remove them. There are some places >> where ImageSegment are inside the code and won't be easy to remove. Or at >> least, leave the code with Smalltalk at: #ImageSegment ifPresent: [blah..] >> Look for example, >> Behavior >> allInstancesEverywhereDo: >> ClassDescription >> updateInstancesFrom: >> All those doGently and isInMemory > > I don't think it is very hard. Methods such as allInstancesEverywhereDo: can be deleted. They implement iterating over object in segments that may be stored on disk. This is too much magic in my eyes. I would only keep the core to do basic segment store/load. > >> So...remove then would be easy, but put them in a separate package, still >> working and without Smalltalk at: ifPresent Â I think it would be difficult. >> >> I have already clean, fix and test it as much as possible. I will let them >> in Pharo and as Martin said, getting it better when someone has time and is >> willing to do it. > > When I find some time I'll try to continue from your work and extract them into a separate package. > >> Another problem is that if we remove ImageSegment to an external package, >> will be soon outdated and nobody will maintain it. > > I believe it may be even the other way round. If image segments (or any other package) is external to the image, it is easier to commit changes. Even though image segments have been around for 10 years inside Squeak they have not been maintained, so it can only get better ;) > > Cheers, > Adrian > >> >> Cheers >> >> Mariano >> >> >> Adrian >>> >>> On Jan 22, 2010, at 21:35 , StÃ©phane Ducasse wrote: >>> >>>> hi guys >>>> >>>> the more I read about imageSegments the more I would like to remove them >>> (or to package them >>>> carefully - not sure that this is possible) and may be Â add a new class >>> to >>>> just have one simple way of invoking the save (but not swapping back in) >>>> >>>> I think that mariano diving into them is a great phd exercise but on the >>> long run >>>> I see it as a brittle mechanism. >>>> >>>> what do you think? >>>> >>>> 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 > -- Best regards, Igor Stasenko AKA sig.

Jan. 25, 2010

Re: [Pharo-project] about imageSegments

by Adrian Lienhard

On Jan 25, 2010, at 09:57 , Mariano Martinez Peck wrote: > On Mon, Jan 25, 2010 at 9:02 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > >> Hi Stef >> >> We can move the few classes related to image segments into a separate >> package in SqueakSource. The system (ideally) does not depend on them so it >> should not be too hard to package them separately. >> >> > There are several things I would like to say: > > - The ImageSegment code really suc.. and it is very difficult to understand, > maintain and test. It is full of etoys, morphic, project and other stuff. > - There are a lot of methods that do a lot of black magic > - The code is VERY fragile and may be broke any time (if it is not already > broken) > > However, > > - Some people use it > - It is fast I think image segments is a very nice idea and it works very well if you know how to use them. The core, which is used for basic store/load, is not that complicated. But image segments have been hacked in ugly ways for project persistency. Hence, there is a lot of complexity that is not needed. > If you ask if we should remove it form core, I would say: > > - It won't very VERY easy to completely remove them. There are some places > where ImageSegment are inside the code and won't be easy to remove. Or at > least, leave the code with Smalltalk at: #ImageSegment ifPresent: [blah..] > Look for example, > Behavior >> allInstancesEverywhereDo: > ClassDescription >> updateInstancesFrom: > All those doGently and isInMemory I don't think it is very hard. Methods such as allInstancesEverywhereDo: can be deleted. They implement iterating over object in segments that may be stored on disk. This is too much magic in my eyes. I would only keep the core to do basic segment store/load. > So...remove then would be easy, but put them in a separate package, still > working and without Smalltalk at: ifPresent I think it would be difficult. > > I have already clean, fix and test it as much as possible. I will let them > in Pharo and as Martin said, getting it better when someone has time and is > willing to do it. When I find some time I'll try to continue from your work and extract them into a separate package. > Another problem is that if we remove ImageSegment to an external package, > will be soon outdated and nobody will maintain it. I believe it may be even the other way round. If image segments (or any other package) is external to the image, it is easier to commit changes. Even though image segments have been around for 10 years inside Squeak they have not been maintained, so it can only get better ;) Cheers, Adrian > > Cheers > > Mariano > > > Adrian >> >> On Jan 22, 2010, at 21:35 , StÃ©phane Ducasse wrote: >> >>> hi guys >>> >>> the more I read about imageSegments the more I would like to remove them >> (or to package them >>> carefully - not sure that this is possible) and may be add a new class >> to >>> just have one simple way of invoking the save (but not swapping back in) >>> >>> I think that mariano diving into them is a great phd exercise but on the >> long run >>> I see it as a brittle mechanism. >>> >>> what do you think? >>> >>> 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. 25, 2010

Re: [Pharo-project] about imageSegments

by StÃ©phane Ducasse

So the plan would be - try to group as much as possible imageSegment related code in a package (without unloading it for now) - may be offer a simple ImageSlice (going in the direction of what nestyle did) - get ready to throw them away. Stef On Jan 25, 2010, at 9:57 AM, Mariano Martinez Peck wrote: > > > On Mon, Jan 25, 2010 at 9:02 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi Stef > > We can move the few classes related to image segments into a separate package in SqueakSource. The system (ideally) does not depend on them so it should not be too hard to package them separately. > > > There are several things I would like to say: > > - The ImageSegment code really suc.. and it is very difficult to understand, maintain and test. It is full of etoys, morphic, project and other stuff. > - There are a lot of methods that do a lot of black magic > - The code is VERY fragile and may be broke any time (if it is not already broken) > > However, > > - Some people use it > - It is fast > > If you ask if we should remove it form core, I would say: > > - It won't very VERY easy to completely remove them. There are some places where ImageSegment are inside the code and won't be easy to remove. Or at least, leave the code with Smalltalk at: #ImageSegment ifPresent: [blah..] > Look for example, > Behavior >> allInstancesEverywhereDo: > ClassDescription >> updateInstancesFrom: > All those doGently and isInMemory > > So...remove then would be easy, but put them in a separate package, still working and without Smalltalk at: ifPresent I think it would be difficult. > > I have already clean, fix and test it as much as possible. I will let them in Pharo and as Martin said, getting it better when someone has time and is willing to do it. > > Another problem is that if we remove ImageSegment to an external package, will be soon outdated and nobody will maintain it. > > Cheers > > Mariano > > > Adrian > > On Jan 22, 2010, at 21:35 , StÃ©phane Ducasse wrote: > > > hi guys > > > > the more I read about imageSegments the more I would like to remove them (or to package them > > carefully - not sure that this is possible) and may be add a new class to > > just have one simple way of invoking the save (but not swapping back in) > > > > I think that mariano diving into them is a great phd exercise but on the long run > > I see it as a brittle mechanism. > > > > what do you think? > > > > 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. 25, 2010