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

Re: [Pharo-dev] Commit right to PharoInbox 3

by StÃ©phane Ducasse

done and thanks!!! On 03 Jan 2014, at 00:22, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Hello, > > I want to commit a slice. > username: HilaireFernandes > > Thanks > > > -- > Dr. Geo http://drgeo.eu > >

Jan. 3, 2014

Re: [Pharo-dev] Pharo3 issues

by StÃ©phane Ducasse

> Now, that the issue was fixed without me doing anything, I can reply. > > I think we are going too much in the direction of discouraging opinions and ideas on the basis that no code comes with them. Let us try to understand a bit. we have a LOT LOT LOT of duties for Pharo and in addition we have our normal work. Now people can express whatever they want. Now Marcus just mentionned that if people wants a chance to get their ideas getting real then they are not that many options. If people thinking that something is important do not put the energy on the table then why would other people with different agendas would do it. > In our particular case, it seems to me that it was my little suggestion that triggered the energy to produce the actual solution. Sometimes, the obvious solution is not so obvious (actually, I posted my remark precisely because I finally figured out what was bothering me about the issue). We should encourage people to think out loud and we might end up with better solutions at the end. Yes but doru I have a HUGE HUGE wish list. So should I send all the items to the list and do nothing? No I should take a little one and do it even slowly. Then go to the next one. And continue. For example, even you when is the last time that you submit a fix for Pharo? Stef > Cheers, > Doru > > > > On Tue, Dec 31, 2013 at 5:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Doru > > The point of marcus is that we cannot take into account all wishes of everybody: else we would not do anything else. > So if somebody thinks that something that is not in our critical path should be changed he should submit code. > I have tons of ideas that could be implemented now since we do not have infinite ressources we focus on the important > ones. > > Stef > >> I do not understand this reaction :( >> >> Doru >> >> >> On Tue, Dec 31, 2013 at 12:01 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On 31 Dec 2013, at 11:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> I think this should not be a global preference at all. Most of the time, you actually want to commit in the same repository where you always do. Only from time to time do you need to switch and copy to another repo. So, the preference should be per browser, not global. >>> >> >> consider that the issue was open since July. How likely is it that what you describe will ever be done? >> >>> Cheers, >>> Doru >>> >>> >>> On Tue, Dec 31, 2013 at 11:55 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> On 30 Dec 2013, at 14:42, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> >>> > Marcus Denker-4 wrote >>> >>> - 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) >>> > >>> > I commented in the issue: >>> > +1. I don't like this change at all. Would someone comment on whether there >>> > is an unseen purpose or this is a bug? >>> > >>> >>> I think we should set the default of the preference to be the opposite, then itâs fixed with no >>> problems for those wanting the other behaviour. >>> >>> Marcus >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Jan. 3, 2014

Don't make me think (the one thing you shouldn't ignore about user interfaces)

by Sebastian Sastre

Guys is no mystery that we have some issues with UI. It's not so bad either, we have many things that are light years ahead of other but we consistently miss some really basic stuff from the Human-Computer-Interactcion point of view. The community is biased towards engineering and unbalanced regarding to design so this is no surprise (why this happens is another interesting conversation). UI is not that hard when you know what to pay attention to but we need first to decide if we care about usability and the developer experience at all. This fantastic talk from Steve Krug exposes what's the least you can do for the usability of any software. http://blip.tv/business-of-software/steve-krug-on-the-least-you-can-do-abou… sebastian o/

Jan. 3, 2014

Re: [Pharo-dev] [Issue tracker] Help needed for reviews

by Sebastian Sastre

Changes reads Merge writes In order to make safe a potentially "dangerous" operation, the write is done in two steps so the user can confirm what is going to be written (or have a chance to check if changes are the ones expected or not and abort without modifying the code). It's functionally correct but the UI can be soooo much better with some tuning. I'll post something that might help us on this subject On Jan 2, 2014, at 9:04 PM, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Le 02/01/2014 20:37, Marcus Denker a Ã©crit : >> I always use âmergeâ. âChangesâ will e.g. show all the changes towards everything changed >> in between, too. > > > For me this is weird, I can't understand the logic. > Merge: shows you the changes then let your merge > Change: shows some other sort of changes I don't understand. > > > -- > Dr. Geo http://drgeo.eu > >

Jan. 3, 2014

Commit right to PharoInbox 3

by Hilaire Fernandes

Hello, I want to commit a slice. username: HilaireFernandes Thanks -- Dr. Geo http://drgeo.eu

Jan. 2, 2014

Re: [Pharo-dev] DateModel label width

by Sean P. DeNigris

Benjamin Van Ryseghem-2 wrote > A dirty patch in the meantime would be to specify the policy to the morph > when built. A workaround would be fine for the moment. Were you suggesting a mess ( ;-) ) like the following? â¦ open | windowModel paperworkDateWidget labelWidget | windowModel := self new openWithSpec. paperworkDateWidget := windowModel window submorphs last firstSubmorph submorphs seventh firstSubmorph firstSubmorph. paperworkDateWidget hResizing: #spaceFill; changeTableLayout; listDirection: #rightToLeft. labelWidget := paperworkDateWidget submorphs second. labelWidget hResizing: #shrinkWrap. labelWidget width: 155. ----- Cheers, Sean -- View this message in context: http://forum.world.st/DateModel-label-width-tp4733674p4733757.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 2, 2014

Re: [Pharo-dev] [Issue tracker] Help needed for reviews

by Hilaire Fernandes

Le 02/01/2014 20:37, Marcus Denker a Ã©crit : > I always use âmergeâ. âChangesâ will e.g. show all the changes towards everything changed > in between, too. For me this is weird, I can't understand the logic. Merge: shows you the changes then let your merge Change: shows some other sort of changes I don't understand. -- Dr. Geo http://drgeo.eu

Jan. 2, 2014

Re: [Pharo-dev] [Issue tracker] Help needed for reviews

by StÃ©phane Ducasse

Hi sven We got an internal discussion on this topic with the same concerns. Komitter was pushed because it does not touch existing code and because people like mariano where starting to code it in parallel. So we thought it was important for people. The idea is that we have some bugs to fix due to the changes we did in nautilus to support. Stef > That also means that we have to finish what we started. > > I have seen some changes being rejected because of the âcode freezeâ while I also see lots of stuff being committed (for example, Komitter), sometimes with little review, that is potentially quite dangerous. > > So letâs be flexible and use common sense judgement, if it was a good/bad idea two months ago, it still is. > > I think the current phase weâre in means: letâs focus on quality and not on new stuff. > >> -> is the change good? >> >> Marcus > >

Jan. 2, 2014

Re: [Pharo-dev] debugger broken?

by Alexandre Bergel

Cool! Alexandre On Jan 2, 2014, at 4:59 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Indeed, I tried in the latest Pharo and it seems to work just fine there, too. > > Doru > > > On Thu, Jan 2, 2014 at 8:57 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 02 Jan 2014, at 20:49, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Yes, it worked. I just tried in a #30664 image. >> > Ok, then my guess is that this is a special case that nobody has yet run intoâ¦ maybe related to > contexts that had been serialised? > >> Doru >> >> >> On Thu, Jan 2, 2014 at 8:36 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On 02 Jan 2014, at 20:25, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >> >>> Evaluating works now but I'm seeing this on #30668 doing cmd-s to accept code changes >>> >> did it ever work on Pharo3? Just to know if this is a regression... >> >>> <Screen Shot 2014-01-02 at 5.09.41 PM.png> >>> >>> >>> >>> >>> >>> On Dec 31, 2013, at 5:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>>> Alex this is not the debugger this is the selection >>>> >>>> Have a look at issue 12144 load it and tell us. Now we have a problem of instability of the latest vm on our servers >>>> so the integration is stalled. I spent 3 hours yesterday trying to move on and we will rollback to an older VM. >>>> >>>> >>>> Stef >>>> >>>> On 30 Dec 2013, at 23:02, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>> >>>>> Hi! >>>>> >>>>> I have faced a serious situation with the debugger today with Pharo 3.0: >>>>> 1 - Open a workspace, and doit on the expression: 1 + 4. self halt >>>>> 2 - Open the debugger, select with the mouse the expression 1 + 4 and press Cmd-p >>>>> 3 - the debugger apparently consider the word halt as a variable. >>>>> >>>>> https://pharo.fogbugz.com/f/cases/12545/Debugger-broken >>>>> >>>>> Since I am using GTDebugger (in the Moose image), I have not seen it before... >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 2, 2014

Re: [Pharo-dev] Pharo3 issues

by Tudor Girba

Now, that the issue was fixed without me doing anything, I can reply. I think we are going too much in the direction of discouraging opinions and ideas on the basis that no code comes with them. In our particular case, it seems to me that it was my little suggestion that triggered the energy to produce the actual solution. Sometimes, the obvious solution is not so obvious (actually, I posted my remark precisely because I finally figured out what was bothering me about the issue). We should encourage people to think out loud and we might end up with better solutions at the end. Cheers, Doru On Tue, Dec 31, 2013 at 5:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Doru > > The point of marcus is that we cannot take into account all wishes of > everybody: else we would not do anything else. > So if somebody thinks that something that is not in our critical path > should be changed he should submit code. > I have tons of ideas that could be implemented now since we do not have > infinite ressources we focus on the important > ones. > > Stef > > I do not understand this reaction :( > > Doru > > > On Tue, Dec 31, 2013 at 12:01 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >> >> On 31 Dec 2013, at 11:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> I think this should not be a global preference at all. Most of the time, >> you actually want to commit in the same repository where you always do. >> Only from time to time do you need to switch and copy to another repo. So, >> the preference should be per browser, not global. >> >> >> consider that the issue was open since July. How likely is it that what >> you describe will ever be done? >> >> Cheers, >> Doru >> >> >> On Tue, Dec 31, 2013 at 11:55 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: >> >>> >>> On 30 Dec 2013, at 14:42, Sean P. DeNigris <sean(a)clipperadams.com> >>> wrote: >>> >>> > Marcus Denker-4 wrote >>> >>> - 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) >>> > >>> > I commented in the issue: >>> > +1. I don't like this change at all. Would someone comment on whether >>> there >>> > is an unseen purpose or this is a bug? >>> > >>> >>> I think we should set the default of the preference to be the opposite, >>> then itâs fixed with no >>> problems for those wanting the other behaviour. >>> >>> Marcus >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 2, 2014