April 2015 - Pharo-dev - lists.pharo.org

Find & replace a dot

by Franck Warlouzet

Hi, For some reason I had to replace a dot with another character, but in the Find & Replace window, searching a dot is actually a bad idea (especially in order to replace it) because for the window all the characters are dots. It selects and replaces the whole text. I know this kind of thing only happens to me, but is there a way to fix it ? I searched in FindReplaceService and I didn't find where the problem is (by the way, never put an halt in FindReplaceService>>findText: then do a request, if you do, prepare yourself to restart Pharo). Cheers, Franck

April 7, 2015

Pharo 4 release & Pharo50Inbox

by Peter UhnÃ¡k

Hi, is the date of Pharo 4 release pushed to fixed date, or to "when ready"? Also, am I free to push into Pharo50Inbox, or is that only after release? (I'm assuming in either case it won't be integrated until the release.) Thanks, Peter

April 7, 2015

Re: [Pharo-dev] Can Monticello version message be a Text?

by Yuriy Tymchuk

Hi, thank you very much for investigating this. These are the steps to reproduce: 1. Clone a git repo (e.g. https://github.com/Uko/VnaExporter.git <https://github.com/Uko/VnaExporter.git>) 2. Add it as gitfiletree repo to the pharo image. 3. Change something, commit part of the changes with Komitter. 4. Change something more. 5. Open Komitter, you should see a strange diff. 6. Select 1 or 2 methods & commit them. 7. Now you should have only 2 methods in your repo. Uko > On 07 Apr 2015, at 07:26, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Uko, > > I had a look at Komitter and couldn't find anything wrong there. Yes, it base the patch on an ancestor as per Monticello, prepare the snapshot and save it to the repository; but the only way the repository would loose some methods is that inside MC, the ancestor is already wrong. > > Could you show me or help me reproduce the effect? > > Thierry > > Le 06/04/2015 19:37, Yuriy Tymchuk a Ã©crit : >> I guess so. Also partially because how monticello works and how >> komitter uses it. As far as I understand, Komitter generates a diff, >> then you select which changes you want to commit and then it somehow >> commits the ancestor with selected changes applied. So if you say >> that the actual ancestor in a wrong one and user will deselect some >> changes - Komitter will commit the old thing + selected new changes. >> >> Maybe itâs a problem of Komitter. On the other hand maybe doing it >> correctly is too complicated because of how monticello works. >> >> Uko >> >>> On 06 Apr 2015, at 18:58, Thierry Goubier >>> <thierry.goubier(a)gmail.com> wrote: >>> >>> Hi Uko, >>> >>> Le 06/04/2015 18:48, Yuriy Tymchuk a Ã©crit : >>>> Actually there is a bigger problemâ¦ Because of hot gitfiletree >>>> finds the ancestor (which is one of the previous ancestors) >>>> Komitter commits the changes related to that ancestor. >>>> >>>> E.g. it shows you that youâve added two methods (while in fact >>>> youâve modified them, but they were not present in the previous >>>> ancestor) and you select to commit only one of them, then one >>>> method will be committed and one deleted. >>> >>> Can you explain a bit? Is it because GitFileTree only uses git to >>> determine the ancestors? >>> >>> Thierry >>> >> >> >> >> > >

April 7, 2015

Re: [Pharo-dev] Anonymous Subclasses and Slots

by Marcus Denker

> On 02 Apr 2015, at 14:23, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > > Hi: > > Is the following expression supposed to work? > > Class new compile: âfoo: a ^ aâ > I think people use the classbuilder/classInstaller for creating classes. #newAnonymousSubclass uses it: e.g. Object newAnonymousSubclass compile: âfoo: a ^ aâ > > The issue is that the `layout` of the result of `Class new` is nil, which cases the compiler to fail, when it sends #allSlots when determining the instanceScope. We should fix thatâ¦ âClass newâ should return a class with valid default values. Marcus

April 7, 2015

Re: [Pharo-dev] Can Monticello version message be a Text?

by Thierry Goubier

Hi Uko, I had a look at Komitter and couldn't find anything wrong there. Yes, it base the patch on an ancestor as per Monticello, prepare the snapshot and save it to the repository; but the only way the repository would loose some methods is that inside MC, the ancestor is already wrong. Could you show me or help me reproduce the effect? Thierry Le 06/04/2015 19:37, Yuriy Tymchuk a Ã©crit : > I guess so. Also partially because how monticello works and how > komitter uses it. As far as I understand, Komitter generates a diff, > then you select which changes you want to commit and then it somehow > commits the ancestor with selected changes applied. So if you say > that the actual ancestor in a wrong one and user will deselect some > changes - Komitter will commit the old thing + selected new changes. > > Maybe itâs a problem of Komitter. On the other hand maybe doing it > correctly is too complicated because of how monticello works. > > Uko > >> On 06 Apr 2015, at 18:58, Thierry Goubier >> <thierry.goubier(a)gmail.com> wrote: >> >> Hi Uko, >> >> Le 06/04/2015 18:48, Yuriy Tymchuk a Ã©crit : >>> Actually there is a bigger problemâ¦ Because of hot gitfiletree >>> finds the ancestor (which is one of the previous ancestors) >>> Komitter commits the changes related to that ancestor. >>> >>> E.g. it shows you that youâve added two methods (while in fact >>> youâve modified them, but they were not present in the previous >>> ancestor) and you select to commit only one of them, then one >>> method will be committed and one deleted. >> >> Can you explain a bit? Is it because GitFileTree only uses git to >> determine the ancestors? >> >> Thierry >> > > > >

April 7, 2015

Re: [Pharo-dev] Can Monticello version message be a Text?

by Thierry Goubier

Le 06/04/2015 19:37, Yuriy Tymchuk a Ã©crit : > I guess so. Also partially because how monticello works and how > komitter uses it. As far as I understand, Komitter generates a diff, > then you select which changes you want to commit and then it somehow > commits the ancestor with selected changes applied. So if you say > that the actual ancestor in a wrong one and user will deselect some > changes - Komitter will commit the old thing + selected new changes. Then I don't understand, because: - git, and gitfiletree, doesn't give a damn about the ancestry. The full package is written to disk; ancestry and diff is determined later, by reading from the repository. - The only thing I could understand would be that komitter shows you the diff to a given version (say v.X), let you select which changes are applied, then read the top version from a repo (say v.Y) and apply the diff to it. > Maybe itâs a problem of Komitter. On the other hand maybe doing it > correctly is too complicated because of how monticello works. As described, I don't see any difficulty, really. I'll look into Komitter to see what it does (and how it does it). Thierry

April 6, 2015

Re: [Pharo-dev] UpdatedPharoByExample for 3.0, 4.0, 5.0

by Sean P. DeNigris

stepharo wrote > My point is... Just plain time to update the contents. Iâm not suggesting we commit to maintain previous versions. But simply place a flag in the ground before we start to update for the next version. ----- Cheers, Sean -- View this message in context: http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514p48178… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 6, 2015

Re: [Pharo-dev] Can Monticello version message be a Text?

by Yuriy Tymchuk

I guess so. Also partially because how monticello works and how komitter uses it. As far as I understand, Komitter generates a diff, then you select which changes you want to commit and then it somehow commits the ancestor with selected changes applied. So if you say that the actual ancestor in a wrong one and user will deselect some changes - Komitter will commit the old thing + selected new changes. Maybe itâs a problem of Komitter. On the other hand maybe doing it correctly is too complicated because of how monticello works. Uko > On 06 Apr 2015, at 18:58, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Uko, > > Le 06/04/2015 18:48, Yuriy Tymchuk a Ã©crit : >> Actually there is a bigger problemâ¦ Because of hot gitfiletree finds >> the ancestor (which is one of the previous ancestors) Komitter >> commits the changes related to that ancestor. >> >> E.g. it shows you that youâve added two methods (while in fact youâve >> modified them, but they were not present in the previous ancestor) >> and you select to commit only one of them, then one method will be >> committed and one deleted. > > Can you explain a bit? Is it because GitFileTree only uses git to determine the ancestors? > > Thierry >

April 6, 2015

Re: [Pharo-dev] Can Monticello version message be a Text?

by Thierry Goubier

Hi Uko, Le 06/04/2015 18:48, Yuriy Tymchuk a Ã©crit : > Actually there is a bigger problemâ¦ Because of hot gitfiletree finds > the ancestor (which is one of the previous ancestors) Komitter > commits the changes related to that ancestor. > > E.g. it shows you that youâve added two methods (while in fact youâve > modified them, but they were not present in the previous ancestor) > and you select to commit only one of them, then one method will be > committed and one deleted. Can you explain a bit? Is it because GitFileTree only uses git to determine the ancestors? Thierry

April 6, 2015

Re: [Pharo-dev] Can Monticello version message be a Text?

by Yuriy Tymchuk

Actually there is a bigger problemâ¦ Because of hot gitfiletree finds the ancestor (which is one of the previous ancestors) Komitter commits the changes related to that ancestor. E.g. it shows you that youâve added two methods (while in fact youâve modified them, but they were not present in the previous ancestor) and you select to commit only one of them, then one method will be committed and one deleted. Uko > On 06 Apr 2015, at 17:51, stepharo <stepharo(a)free.fr> wrote: > > please fix Komitter :) > > > Le 6/4/15 13:44, Yuriy Tymchuk a Ã©crit : >> Hi, in gitfiletree there is a piece of code like this: >> >> aVersion info message convertToSystemString >> >> But if you commit using Komitter `aVersion info message` is an instance of Text. Is this ok? I.e. should we fix Komitter to assign String as version message, or should gitfiletree convert message to string explicitly? >> > >

April 6, 2015