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

Re: [Pharo-dev] Are #explorerContents and #hasContentsInExplorer obsolete ?

by Tudor Girba

I know. This is why I am arguing that we should make the optional tools not optional. It would be a more profitable approach :). Cheers, Doru On Mon, Dec 30, 2013 at 11:02 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On 28 Dec 2013, at 13:36, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Thanks for raising this :). > > > > I now added a simple implementation in the GTInspector to have Pointers > available for all objects. Perhaps it is overdoing it to have it by default > on all objects, but it was cheap to implement in a crude way. I still do > not eliminate all inspector related objects that point to the current > object, but it's a start (see attached the pointers to Smalltalk). > > > > If the inspector that is in Pharo gets a solution for pointers, then we > can directly clean up a lot of old code. > With this being done for tools that are just loadable optionally â> we > still have to keep the old code of the Explorer around. > > Marcus > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 30, 2013

Re: [Pharo-dev] Pharo3 issues

by Nicolai Hess

for issue 12223 <https://pharo.fogbugz.com/default.asp?12223> please revert the changes done for editing history in Nautilus. It makes more trouble than it helps. It is a nice feature, but it is implementation has too many side effects (discard changes on close, lose changes when jump through the history, history has a limit) If no one has the time to revert this, just give me a GO, and I'll do it :-) Nicolai 2013/12/30 Marcus Denker <marcus.denker(a)inria.fr> > > On 30 Dec 2013, at 12:38, jannik.laval <jannik.laval(a)gmail.com> wrote: > > > Hi all, > > > > I am porting Phratch in Pharo 3.0 and I have some problems with the > interface. > > I uses a one-click Pharo3.0 #30664 > > > > Here is a list of what I have: > > > > - in a debugger, it is not possible to do a Cmd-p to evaluate an > expression. This appears only if I select with the mouse. If I make the > selection with shift-arrow it works. > > It means that the selection with mouse or with shift-arrow are not the > same. > > > yes, known bug. Introduced by 12144 TextModel>>getSelection. The only > solution seems to be to revert tag for now: > > https://pharo.fogbugz.com/f/cases/12521/Undo-12144-TextModel-getSelection > > This will be in the next update. (I was offline more or less since > thursday due to helping my brother moving, so this is not integrated yet) > > > - In monticello browser: when I select my project, all the repositories > available in Pharo are shown. As in Pharo 2.0, it should show only the > concerned repositories (2 or 3 max). > > > Yes, this was made on purpose and there is an issue that questions if that > idea was good: > > > https://pharo.fogbugz.com/f/cases/10551/All-Monticello-Repositories-are-add… > (this issue is from July) > > > > - In a browser, when I did a change in the source code of a method, then > I select another method, the changes are lost, without asking if I want to > save changes. > > > > https://pharo.fogbugz.com/f/cases/12223/Nautilus-loses-changes > (issue date: 22/11) > > In short: if there would be more people *actively* helping on the issue > tracker front, you would not even have seen those problems. > > > Marcus >

Dec. 30, 2013

Re: [Pharo-dev] MessageBrowser doesn't play well with RGCommentDefinition as search results

by Marcus Denker

On 26 Dec 2013, at 17:55, Nicolai Hess <nicolaihess(a)web.de> wrote: > Hi, > > I am about to file in a whole bunch of issues regarding MessageBrowser. > All are related to search result of the kind RGCommentDefinition. These > are collected by SystemNavigation or doing a search: "class comments with it" or "method source with it". > > Most of you may not recognize these bugs, as the typically "senders of it", "implementors of it" > search results doesn't suffer from these. > (and doing search "class comments with it" isn't used that often from all, I think) > > But for newcomers searching strings through "method source with it" is an handy > task for exploring the image. And this search mixes search results of RGCommentDefinition > and RGMethodDefinition. And it is annoying for newcomers to stumble of not working > buttons/menus without realizing that there is actually a difference in the search results. > > These bugs are: > In MessageBrowser, search results of kind RGCommentDefinition > - have no working context menu > - use syntax highlighting for a class comment text > - can not be changed (raising an error on accept) > - Browse button opens the Systembrowser but it does not show the > comment text, but the class definition > - Senders button opens a MessageBrowser for selectors containing the > symbol #Comment > - Implementors button searches for implementors of a "Comment" selector (no search results) > - Version button raises an error > - switch source formatter to "Byte Code" or "Time stamp" raises an error > > I would add all issues under one parent issue (MessageBrowser doesn't play well > with RGCommentDefinition) > > I don't consider all issues as "must fix", some are real bugs (all that raising > an error) and some are more like enhancements (useless syntax highlight for comment text) > > But I would like to fix them all and maybe even all at once. > > What do you think? > > All for Pharo3, none for Pharo3, split them by bugfixes for 3 and > "nice to have" for 4? > good question.. right now I see a bit the thread that we are drowning in issuesâ¦ even with closing hundreds in December, the amount of reported issues is growing. So I would not strive for extreme perfectionâ¦ but be guided by what we can do for realâ¦ Marcus

Dec. 30, 2013

Re: [Pharo-dev] Pharo3 issues

by Marcus Denker

On 30 Dec 2013, at 12:38, jannik.laval <jannik.laval(a)gmail.com> wrote: > Hi all, > > I am porting Phratch in Pharo 3.0 and I have some problems with the interface. > I uses a one-click Pharo3.0 #30664 > > Here is a list of what I have: > > - in a debugger, it is not possible to do a Cmd-p to evaluate an expression. This appears only if I select with the mouse. If I make the selection with shift-arrow it works. > It means that the selection with mouse or with shift-arrow are not the same. > yes, known bug. Introduced by 12144 TextModel>>getSelection. The only solution seems to be to revert tag for now: https://pharo.fogbugz.com/f/cases/12521/Undo-12144-TextModel-getSelection This will be in the next update. (I was offline more or less since thursday due to helping my brother moving, so this is not integrated yet) > - In monticello browser: when I select my project, all the repositories available in Pharo are shown. As in Pharo 2.0, it should show only the concerned repositories (2 or 3 max). > Yes, this was made on purpose and there is an issue that questions if that idea was good: https://pharo.fogbugz.com/f/cases/10551/All-Monticello-Repositories-are-add… (this issue is from July) > - In a browser, when I did a change in the source code of a method, then I select another method, the changes are lost, without asking if I want to save changes. > https://pharo.fogbugz.com/f/cases/12223/Nautilus-loses-changes (issue date: 22/11) In short: if there would be more people *actively* helping on the issue tracker front, you would not even have seen those problems. Marcus

Dec. 30, 2013

Re: [Pharo-dev] Pharo3 issues

by Esteban Lorenzano

On 30 Dec 2013, at 12:37, jannik.laval <jannik.laval(a)gmail.com> wrote: > Hi all, > > I am porting Phratch in Pharo 3.0 and I have some problems with the interface. > I uses a one-click Pharo3.0 #30664 > > Here is a list of what I have: > > - in a debugger, it is not possible to do a Cmd-p to evaluate an expression. This appears only if I select with the mouse. If I make the selection with shift-arrow it works. > It means that the selection with mouse or with shift-arrow are not the same. yes, this is a known bug (I donât remember number) > > - In monticello browser: when I select my project, all the repositories available in Pharo are shown. As in Pharo 2.0, it should show only the concerned repositories (2 or 3 max). Nope, there is a change with this. There is no more relation 1->N in MC, now is N->N. There is a preference if you want the old behaviour. > > - In a browser, when I did a change in the source code of a method, then I select another method, the changes are lost, without asking if I want to save changes. yepâ¦ also a known bug. so, 2 bugs, 1 âfeatureâ :) Esteban > > Could one confirm that they are bugs (not new features) ? and if they are already reported. > > Cheers, > Jannik

Dec. 30, 2013

Pharo3 issues

by jannik.laval

Hi all, I am porting Phratch in Pharo 3.0 and I have some problems with the interface. I uses a one-click Pharo3.0 #30664 Here is a list of what I have: - in a debugger, it is not possible to do a Cmd-p to evaluate an expression. This appears only if I select with the mouse. If I make the selection with shift-arrow it works. It means that the selection with mouse or with shift-arrow are not the same. - In monticello browser: when I select my project, all the repositories available in Pharo are shown. As in Pharo 2.0, it should show only the concerned repositories (2 or 3 max). - In a browser, when I did a change in the source code of a method, then I select another method, the changes are lost, without asking if I want to save changes. Could one confirm that they are bugs (not new features) ? and if they are already reported. Cheers, Jannik

Dec. 30, 2013

Re: [Pharo-dev] FogBugz status change

by Marcus Denker

On 29 Dec 2013, at 23:34, btc(a)openinworld.com wrote: > Esteban Lorenzano wrote: >> >> thatâs usually done by the integrators, but nothing prevents you to do it :) >> > I thought wider community involvement was encouraged for anyone to provide the peer review to move items to status Resolved Fix To Include > with the integrators then moving it to status Resolved Fix Included (and then usually straight to Closed status) > Yes, but for a real working system we would need a voting schemeâ¦ right now it matters not much as everything is manual, but of it would be automatic, it would be nice to have something like âtwo people who are commuters say itâs goo then it is good to be integrated automaticallyâ.] Right now the idea is that people can set the âfix to includeâ if they are 150% sure that is is a good change. Itâs better to just add a note to the âfix review neededâ so then someone else will say âhe thinks itâs good, I double checked, so itâs goodâ. So, in short: we need a better system, but for now it kind of works. Marcus

Dec. 30, 2013

Re: [Pharo-dev] pharo 3.0 image

by Marcus Denker

On 30 Dec 2013, at 09:51, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 30 Dec 2013, at 08:29, Johan Brichau <johan(a)inceptive.be> wrote: > >> On 29 Dec 2013, at 22:16, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> yeah, but I also remember a discussion of ânow, sources should be always (and just there) with vmâ¦ or the oppositeââ¦ >> >> imho, it seems more appropriate to keep them with the image since itâs the image that determines the Pharo version and not the vm. > > Keeping them with the VM makes for easier sharing (just one copy, never think of it again, run images from everywhere). These are different styles I guess. We need to get rid of it. The mental overhead it produces is costing far more then the memory it saves (and now we soon have 2014, so if it was âtoo much memoryâ for Pharo3, it will by definition not be for Pharo4 thanks to time passingâ¦) Marcus

Dec. 30, 2013

Re: [Pharo-dev] pharo 3.0 image

by Marcus Denker

On 29 Dec 2013, at 22:16, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yeah, but I also remember a discussion of ânow, sources should be always (and just there) with vmâ¦ or the oppositeââ¦ > but I do not remember the result of that discussion and this could be a consequence of that. Marcus will know better for sure (letâs wait he is back from his holidays :) ) > I am back and going through lots of mailsâ¦. So: I thought this was fixed. Seemingly there was a regressionâ¦ There is another issue that we need to have a look at related (not the same): https://pharo.fogbugz.com/f/cases/11908/Need-to-show-warning-when-no-change…

Dec. 30, 2013

Re: [Pharo-dev] pharo 3.0 image

by Esteban Lorenzano

On 30 Dec 2013, at 09:54, Johan Brichau <johan(a)inceptive.be> wrote: > > On 30 Dec 2013, at 09:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>> imho, it seems more appropriate to keep them with the image since itâs the image that determines the Pharo version and not the vm. >> >> Keeping them with the VM makes for easier sharing (just one copy, never think of it again, run images from everywhere). These are different styles I guess. > > I guess it does not hurt to look at both places. > In 10 years from now, you might no longer have the V10.sources anymore with your vm but you might want to dive into a 2011 image of Zinc on Pharo1.4 for good âol times sake ;-) in 10 months from now (not years), if everything goes fine, sources will come inside image (also changes)â¦ in an unique super-file :) but well, we are not still in that pointâ¦ and 10 months is just a desire than a fact :) Esteban > > cheers > Johan

Dec. 30, 2013