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

Re: [Pharo-dev] Do you want to accept???????? Discard???????

by kilon alios

Photoshop well deserves its monopoly, and its GUI played a vital role in it. Its your right to think that Photoshop is not good and my right to think that Photoshop GUI should be taught in seminars and lectures about GUI design. I dont use Photoshop I use GIMP. I prefer to support open source. GIMP's GUI is bad, it was very bad , fortunately it has improved a bit. But there are like thousand of opinions out there that will show you what average user thinks about PS. PS did not earn its monopoly by accident or marketing, its there because artists just love it. You say you care about GUI , can you show me how exactly you care ? Because I love coding in pharo and I like the GUI, but its not very good , but its better than other IDEs. Pharo has barely changed GUI wise, sure it has Athens and Spec and Glamour and many other nice things, but the GUI itself is still very similar to squeak. For example monticello, common repos for all packages , really ? System browser , only recently got a tab system. Why a three panel should be forced down my throat, i want to maximise the view for seeing the code itself. Fullscreen not working as fullscreen in macos which is the dominant platform of pharo. Nautilus has strange blue box appearing for packages . A billion of windows to browse through classes and methods is that good GUI design. I know you worked on Nativeboost and Athens but I have seen no GUI work from you. I love your work and thank you but I am surprised to hear you say that you care about GUI. And you are debating about whether we should have confirm dialogs or not. The way I see it , there is so many issues you have to address even before worrying about this. You say that is better to let the baby burn to learn that fire is bad, Maybe you should let the baby die to learn death is not good. If I have a tool that is easy to use and another that want to "teach me" the hard way, I rather go with the easy one. We live in world that makes life very complex , why make it even more complex than it needs to be ? I dont need a stupid software to tell me that I need to sit down and learn to improve. But then even if you learn an app really well, a bad GUI will always remain a bad GUI, even if you have found a thousands workarounds and will hinder your workflow every single day. On Thu, Jan 9, 2014 at 1:29 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 9 January 2014 12:11, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > >> Well, truth be told, the editors are really a pain in the current form. >> And in some ways are worse than in the past, especially with selection bugs >> etc. Now, given that we are using principles that date back 30+ years, it >> is astonishing that we went so far without massive changes. >> >> There are efforts ongoing and getting TextEditors "right" is really hard. >> I really look forward to the new editor and dark theme. >> >> Now, yeah, I should move my ass and contribute more to this. Putting >> bread on the table is getting in my way at the moment, but that's forseen >> to change soon. >> >> (And Photoshop is a pain in the assets as well - GIMP isn't any better. >> What matters is that one invests time in learning the quirks to get the >> results. Always like that. Currently working with Varicad for some design >> project and the UI isn't simple either, see for yourself: >> > > > yeah.. GUI typically falls victim of too many functionality fighting with > too little screen space :) > > I just want that everyone understands my point: lets not surrender and > keep making progress. > yes, we will suffer in the process, but that should serve as a stimulus to > do things right, instead of doing nothing by reverting everything back. > I am fully understand and accepting that everyone has own preferences and > different workflow, and i never assuming that my workflow is the only one > which should prevail above everyone's else. > Well except the modal things :P > > > >> [image: Inline image 1] >> >> >> >> >> On Thu, Jan 9, 2014 at 11:59 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >> >>> >>> >>> On 9 January 2014 11:10, kilon alios <kilon.alios(a)gmail.com> wrote: >>> >>>> I was the one that worked on CMD+L dialog. I posted my slice here and >>>> it was discussed. I tried to implement undo, but trying to understand undo >>>> was a pain in the ass. >>>> >>>> And yes Igor I am no pro coder, I code like 30 minutes a day max. I am >>>> a lawyer that tries to become a pro 2d/3d artist. >>>> I enjoy coding and an IDE that punishes me for my mistakes does not >>>> make coding enjoyable for me. >>>> >>> >>> because punishment is a HUGE part of process as one of the stimulus for >>> learning things you wouldn't learn the other way. Without it, i doubt you >>> can learn anything at all. >>> You can give a candy to baby each time it does not try touching fire, >>> and the only thing which baby will learn is that to get a candy it needs to >>> pretend that its about to touch fire. >>> Only after baby will touch it, it can learn why touching it is bad >>> idea.. no candies will help. >>> >>> I think maybe an easy solution is to set all modals to a preference >>>> setting so they can be easily disabled, thus making everyone happy. >>>> >>>> Yes, that could be a way to go. >>> >>> >>>> Igor I will be frank with you, coders have no idea how to design good >>>> GUIs. They see GUIs as nothing more than an inconvenience and extra coding >>>> effort from their part. >>>> >>> >>> really? i do not belong to those who think GUI is secondary. A >>> well-designed GUI is very important for efficient workflow. Same as >>> well-designed language, like smalltalk is. >>> >>> They usually put out the excuse "I am no designer" yet the truth is that >>>> they dont care because they cant understand the importance of a great GUI >>>> to the user. Applications like Photoshop are rare example of good GUI >>>> design. >>>> >>> >>> you lost me on that. I never considered Photoshop as one that has good >>> GUI design.. >>> The main merit of Photoshop is that it is killed all other really good >>> graphics editors and established monopoly. It's easy to say 'we are best' >>> when there's nothing to compare with. >>> >>> >>> >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > -- > Best regards, > Igor Stasenko. >

Jan. 9, 2014

Re: [Pharo-dev] Athens SVG Import

by J.F. Rick

'self changed' logic is the thing that triggers drawing. Before Athens, various different morphs would register that their part of the screen needed to be updated with a 'self changed' thing. Then, once a UI cycle, the sum of the areas needing to be changed was determined and those morphs within that area would be redrawn. So, you could have a 100 'self changed' things happening before drawing happens. It seems like with Athens that each 'self changed' causes a redraw. So, having 25 times as many self changed messages causes 25 times as many drawing cycles. While Athens is faster than BitBlt rendering, it may not be 25 times faster. Cheers, Jeff On Thu, Jan 9, 2014 at 10:36 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 9 January 2014 10:26, J.F. Rick <self(a)je77.com> wrote: > >> OK. I've made a little headway in diagnosing the problem. It seems that >> one culprit is that the "self changed" thing works differently with Athens >> than previously. Correct me if I'm wrong, but it seems like sending that >> method immediately causes the canvas to draw. In contrast, before, it just >> marked that area as needing to be redrawn and then, on an update cycle, it >> would redraw the total area that changed. I was using a model-view pattern >> that had 25 components to it. When each got the update command, it seems to >> have launched the canvas to draw. When I changed it so that only one >> changed command was given, the interface became immediately much snappier. >> Adding a factor of 25 to rendering could cause even fast rendering to be >> quite noticeable. So, it is not an inherent problem with drawing forms but >> rather one with changing the programming paradigm. Forms are just >> noticeably slower to draw than vector components and that exacerbated my >> problem. >> >> > Hmm.. Can you explain me, how Athens is related to that? :) > > 'self changed' logic and its handling is related to Morphic and used by it. > there's no way how you can change it by changing something in Athens. > > > >> Cheers, >> >> Jeff >> >> >> On Thu, Jan 9, 2014 at 8:18 AM, J.F. Rick <self(a)je77.com> wrote: >> >>> Hmm. Weird. Could it be a linux thing? Bit order or something? Could it >>> be a transparency issue? Could it be a size of the form? I have forms of >>> size around 200 x 200. At this point, I haven't numerically investigated >>> it. I just notice a significant difference in rendering speed as I switch >>> from forms to SVGs. Perhaps it is having to redraw the entire interface >>> very often. I'll investigate a bit more when I have some time. >>> >>> Cheers, >>> >>> Jeff >>> >>> >>> On Thu, Jan 9, 2014 at 2:08 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>> >>>> >>>> >>>> >>>> On 8 January 2014 08:59, J.F. Rick <self(a)je77.com> wrote: >>>> >>>>> In good news, I was able to implement the S/s functionality and both >>>>> of my SVGs now load properly. I'll try some more soon and commit the >>>>> changes once I have tested it a bit more. >>>>> >>>>> In bad news, the cacheing was working properly, so I still suspect >>>>> that rendering forms as a paint is too intensive to be practical for many >>>>> applications. I'll try to evaluate it a bit more as I replace forms with >>>>> SVGs. If the forms are causing the problem, then performance should >>>>> noticeably increase. >>>>> >>>>> >>>> I just did a little comparison: >>>> >>>> | surface time | >>>> surface := AthensCairoSurface extent: 200@200. >>>> >>>> surface drawDuring: [ :canvas| >>>> canvas setPaint: Color red. >>>> canvas setShape: (0@0 extent: 100@100). >>>> time := [ 10000 timesRepeat: [ canvas draw ] ] timeToRun. >>>> ]. >>>> time >>>> 0:00:00:00.115 >>>> ============= >>>> >>>> same as above but with: >>>> canvas setPaint: (ThemeIcons current backIcon). >>>> >>>> time >>>> 0:00:00:00.093 >>>> =========== >>>> >>>> same as above but with: >>>> (canvas setPaint: (ThemeIcons current backIcon)) repeat. >>>> >>>> time >>>> 0:00:00:00.956 >>>> >>>> as you can see, even in slowest case, the throughput is: >>>> >>>> 100*100*10000 = 100'000'000 pixels (texels) per second. >>>> >>>> >>>> >>>>> Cheers, >>>>> >>>>> Jeff >>>>> >>>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >>> >>> -- >>> Jochen "Jeff" Rick, Ph.D. >>> http://www.je77.com/ >>> Skype ID: jochenrick >>> >> >> >> >> -- >> Jochen "Jeff" Rick, Ph.D. >> http://www.je77.com/ >> Skype ID: jochenrick >> > > > > -- > Best regards, > Igor Stasenko. > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Jan. 9, 2014

Re: [Pharo-dev] Do you want to accept???????? Discard???????

by Igor Stasenko

On 9 January 2014 12:13, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 9 January 2014 11:27, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 09 Jan 2014, at 11:11, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> I was the one that worked on CMD+L dialog. I posted my slice here and it >> was discussed. I tried to implement undo, but trying to understand undo was >> a pain in the ass. >> >> >> I reviewed it and you are not to blame: A key combination that *loses >> code* is not acceptable, and as we discussed in the past, this >> change was needed and good. >> >> Yes, and i agreed on that. > My only complaint is that instead of making things work, we reversed it > and made things even worse. > > >> The people who use the (undocumented!) cmd-L can easily get rid of the >> warning by implementing Undo. >> >> how many modern editors document that pressing home key will move cursor > to beginning of line? or pressing cmd-v will paste things from clipboard? > i do not think this is a good criteria to disable feature(s) only because > they either not documented properly or that someone has no idea it exists. > yes, to be fair, the Cmd-L was not disabled, but *crippled* , enough that its usefulness become very low. because before i knew that i can type any garbage in any editor window and undo all with single keystroke, and now i have to be interrupted with yes/no popup. Can i ask, why consoles do not ask you are you sure you want to face consequences of you pressed ctrl-c? and in same way, i do not remember myself learning about ctrl-c functionality by reading some docs.. i leaned it by interacting with console and pressing random keys and see what happens. > >> Marcus >> >> And yes Igor I am no pro coder, I code like 30 minutes a day max. I am a >> lawyer that tries to become a pro 2d/3d artist. >> I enjoy coding and an IDE that punishes me for my mistakes does not make >> coding enjoyable for me. >> I think maybe an easy solution is to set all modals to a preference >> setting so they can be easily disabled, thus making everyone happy. >> >> Igor I will be frank with you, coders have no idea how to design good >> GUIs. They see GUIs as nothing more than an inconvenience and extra coding >> effort from their part. >> They usually put out the excuse "I am no designer" yet the truth is that >> they dont care because they cant understand the importance of a great GUI >> to the user. Applications like Photoshop are rare example of good GUI >> design. >> >> >> On Thu, Jan 9, 2014 at 12:00 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: >> >>> >>> On 09 Jan 2014, at 10:50, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> >>> On 09 Jan 2014, at 10:45, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> >>> >>> >>> On 9 January 2014 10:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> The history hack did totally not work for end users, many people, >>>> including myself, lost code, often without noticing or understanding it at >>>> first. >>>> >>>> This 'warning, you did not accept' is/was important and solid, if you >>>> want to replace that the solution should be really good - it was not. >>>> >>>> Don't shoot on Nicolai, he tried to fix it, after asking around. >>>> >>>> i'm not shooting anyone, i just sad there is no progress :) >>> and instead even regress, because now i should also answer 'yes/no' when >>> i press >>> cmd-L.. >>> >>> If some people will need to be asked are they really really really >>> fucking sure they wanted to press a key they pressed, each time they >>> pressing the key, why others, who don't need such stupidity should suffer? >>> >>> >>> These are two different issue: >>> >>> 1) CMD-L >>> >>> >>> The real solution is to implement undo for cmd-L... >>> >>> 2) Not asking in general and rely on history. >>> >>> This is a good idea but it needs to *work* >>> >>> Marcus >>> >> >> >> > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Jan. 9, 2014

Re: [Pharo-dev] Do you want to accept???????? Discard???????

by phil＠highoctane.be

Amen, brother. The future is bright. Nothing touches Pharo in terms of pleasure of coding anyway. And I mean it. Now, back to work in order to collect the cash to pay for my 2014 consortium membership :-) Phil On Thu, Jan 9, 2014 at 12:29 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 9 January 2014 12:11, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > >> Well, truth be told, the editors are really a pain in the current form. >> And in some ways are worse than in the past, especially with selection bugs >> etc. Now, given that we are using principles that date back 30+ years, it >> is astonishing that we went so far without massive changes. >> >> There are efforts ongoing and getting TextEditors "right" is really hard. >> I really look forward to the new editor and dark theme. >> >> Now, yeah, I should move my ass and contribute more to this. Putting >> bread on the table is getting in my way at the moment, but that's forseen >> to change soon. >> >> (And Photoshop is a pain in the assets as well - GIMP isn't any better. >> What matters is that one invests time in learning the quirks to get the >> results. Always like that. Currently working with Varicad for some design >> project and the UI isn't simple either, see for yourself: >> > > > yeah.. GUI typically falls victim of too many functionality fighting with > too little screen space :) > > I just want that everyone understands my point: lets not surrender and > keep making progress. > yes, we will suffer in the process, but that should serve as a stimulus to > do things right, instead of doing nothing by reverting everything back. > I am fully understand and accepting that everyone has own preferences and > different workflow, and i never assuming that my workflow is the only one > which should prevail above everyone's else. > Well except the modal things :P > > > >> [image: Inline image 1] >> >> >> >> >> On Thu, Jan 9, 2014 at 11:59 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >> >>> >>> >>> On 9 January 2014 11:10, kilon alios <kilon.alios(a)gmail.com> wrote: >>> >>>> I was the one that worked on CMD+L dialog. I posted my slice here and >>>> it was discussed. I tried to implement undo, but trying to understand undo >>>> was a pain in the ass. >>>> >>>> And yes Igor I am no pro coder, I code like 30 minutes a day max. I am >>>> a lawyer that tries to become a pro 2d/3d artist. >>>> I enjoy coding and an IDE that punishes me for my mistakes does not >>>> make coding enjoyable for me. >>>> >>> >>> because punishment is a HUGE part of process as one of the stimulus for >>> learning things you wouldn't learn the other way. Without it, i doubt you >>> can learn anything at all. >>> You can give a candy to baby each time it does not try touching fire, >>> and the only thing which baby will learn is that to get a candy it needs to >>> pretend that its about to touch fire. >>> Only after baby will touch it, it can learn why touching it is bad >>> idea.. no candies will help. >>> >>> I think maybe an easy solution is to set all modals to a preference >>>> setting so they can be easily disabled, thus making everyone happy. >>>> >>>> Yes, that could be a way to go. >>> >>> >>>> Igor I will be frank with you, coders have no idea how to design good >>>> GUIs. They see GUIs as nothing more than an inconvenience and extra coding >>>> effort from their part. >>>> >>> >>> really? i do not belong to those who think GUI is secondary. A >>> well-designed GUI is very important for efficient workflow. Same as >>> well-designed language, like smalltalk is. >>> >>> They usually put out the excuse "I am no designer" yet the truth is that >>>> they dont care because they cant understand the importance of a great GUI >>>> to the user. Applications like Photoshop are rare example of good GUI >>>> design. >>>> >>> >>> you lost me on that. I never considered Photoshop as one that has good >>> GUI design.. >>> The main merit of Photoshop is that it is killed all other really good >>> graphics editors and established monopoly. It's easy to say 'we are best' >>> when there's nothing to compare with. >>> >>> >>> >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > -- > Best regards, > Igor Stasenko. >

Jan. 9, 2014

Re: [Pharo-dev] TDD in Core

by Tudor Girba

+1 So, what do we do to make it happen? Doru On Thu, Jan 9, 2014 at 12:28 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > +1 to just add things with appropriate tests. > > in the case of Spec in particular, the problem is that is really hard to > have UI testing :( > Alsoâ¦ sometimes you break backward compatibility, thatâs inevitableâ¦ and > is ok if is for the best (like in the case of Specâ¦ it was to gain ui > platform independence). > > but anyway, I do agree that we need to raise our acceptance criteria :) > > Esteban > > On 09 Jan 2014, at 12:22, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > We should have a policy on this. I've been guilty of writing new features > > without tests too. It's bad enough we have to deal with untested legacy > > code, but to replace key parts of the system with untested code doesn't > seem > > like such a good idea. In particular, the latest Spec refactoring broke a > > lot of the UI. It's a validation of how well it's been received. It has > > become a crucial part of much of the IDE. At various points in 3.0 the > > ChangeSorter, Versionner, and SliderModel have been broken, to name a > few, > > and I get mysterious and sudden, often image wrecking, DNUs that appear, > > like TextModel>>#asText. It's made it very hard to work, especially when > the > > compiler, RPackage, etc are changing (and sometimes breaking) at the same > > time. > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/TDD-in-Core-tp4735378.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 9, 2014

[pharo-project/pharo-core] 3d9404: 30681

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 3d9404019be44c2ad1f5bbf5c001c7fe3aedf279 https://github.com/pharo-project/pharo-core/commit/3d9404019be44c2ad1f5bbf5… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-01-09 (Thu, 09 Jan 2014) Changed paths: M RPackage-Core.package/RPackageOrganizer.class/instance/private/packageNamedIgnoreCase_ifAbsent_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script334.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30681.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30681 EstebanLorenzano http://files.pharo.org/image/30/30681.zip

Jan. 9, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30681 Home: https://github.com/pharo-project/pharo-core

Jan. 9, 2014

Re: [Pharo-dev] Do you want to accept???????? Discard???????

by Igor Stasenko

On 9 January 2014 12:11, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Well, truth be told, the editors are really a pain in the current form. > And in some ways are worse than in the past, especially with selection bugs > etc. Now, given that we are using principles that date back 30+ years, it > is astonishing that we went so far without massive changes. > > There are efforts ongoing and getting TextEditors "right" is really hard. > I really look forward to the new editor and dark theme. > > Now, yeah, I should move my ass and contribute more to this. Putting bread > on the table is getting in my way at the moment, but that's forseen to > change soon. > > (And Photoshop is a pain in the assets as well - GIMP isn't any better. > What matters is that one invests time in learning the quirks to get the > results. Always like that. Currently working with Varicad for some design > project and the UI isn't simple either, see for yourself: > yeah.. GUI typically falls victim of too many functionality fighting with too little screen space :) I just want that everyone understands my point: lets not surrender and keep making progress. yes, we will suffer in the process, but that should serve as a stimulus to do things right, instead of doing nothing by reverting everything back. I am fully understand and accepting that everyone has own preferences and different workflow, and i never assuming that my workflow is the only one which should prevail above everyone's else. Well except the modal things :P > [image: Inline image 1] > > > > > On Thu, Jan 9, 2014 at 11:59 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> On 9 January 2014 11:10, kilon alios <kilon.alios(a)gmail.com> wrote: >> >>> I was the one that worked on CMD+L dialog. I posted my slice here and it >>> was discussed. I tried to implement undo, but trying to understand undo was >>> a pain in the ass. >>> >>> And yes Igor I am no pro coder, I code like 30 minutes a day max. I am a >>> lawyer that tries to become a pro 2d/3d artist. >>> I enjoy coding and an IDE that punishes me for my mistakes does not >>> make coding enjoyable for me. >>> >> >> because punishment is a HUGE part of process as one of the stimulus for >> learning things you wouldn't learn the other way. Without it, i doubt you >> can learn anything at all. >> You can give a candy to baby each time it does not try touching fire, and >> the only thing which baby will learn is that to get a candy it needs to >> pretend that its about to touch fire. >> Only after baby will touch it, it can learn why touching it is bad idea.. >> no candies will help. >> >> I think maybe an easy solution is to set all modals to a preference >>> setting so they can be easily disabled, thus making everyone happy. >>> >>> Yes, that could be a way to go. >> >> >>> Igor I will be frank with you, coders have no idea how to design good >>> GUIs. They see GUIs as nothing more than an inconvenience and extra coding >>> effort from their part. >>> >> >> really? i do not belong to those who think GUI is secondary. A >> well-designed GUI is very important for efficient workflow. Same as >> well-designed language, like smalltalk is. >> >> They usually put out the excuse "I am no designer" yet the truth is that >>> they dont care because they cant understand the importance of a great GUI >>> to the user. Applications like Photoshop are rare example of good GUI >>> design. >>> >> >> you lost me on that. I never considered Photoshop as one that has good >> GUI design.. >> The main merit of Photoshop is that it is killed all other really good >> graphics editors and established monopoly. It's easy to say 'we are best' >> when there's nothing to compare with. >> >> >> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Jan. 9, 2014

Re: [Pharo-dev] TDD in Core

by Esteban Lorenzano

+1 to just add things with appropriate tests. in the case of Spec in particular, the problem is that is really hard to have UI testing :( Alsoâ¦ sometimes you break backward compatibility, thatâs inevitableâ¦ and is ok if is for the best (like in the case of Specâ¦ it was to gain ui platform independence). but anyway, I do agree that we need to raise our acceptance criteria :) Esteban On 09 Jan 2014, at 12:22, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > We should have a policy on this. I've been guilty of writing new features > without tests too. It's bad enough we have to deal with untested legacy > code, but to replace key parts of the system with untested code doesn't seem > like such a good idea. In particular, the latest Spec refactoring broke a > lot of the UI. It's a validation of how well it's been received. It has > become a crucial part of much of the IDE. At various points in 3.0 the > ChangeSorter, Versionner, and SliderModel have been broken, to name a few, > and I get mysterious and sudden, often image wrecking, DNUs that appear, > like TextModel>>#asText. It's made it very hard to work, especially when the > compiler, RPackage, etc are changing (and sometimes breaking) at the same > time. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/TDD-in-Core-tp4735378.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Jan. 9, 2014

TDD in Core

by Sean P. DeNigris

We should have a policy on this. I've been guilty of writing new features without tests too. It's bad enough we have to deal with untested legacy code, but to replace key parts of the system with untested code doesn't seem like such a good idea. In particular, the latest Spec refactoring broke a lot of the UI. It's a validation of how well it's been received. It has become a crucial part of much of the IDE. At various points in 3.0 the ChangeSorter, Versionner, and SliderModel have been broken, to name a few, and I get mysterious and sudden, often image wrecking, DNUs that appear, like TextModel>>#asText. It's made it very hard to work, especially when the compiler, RPackage, etc are changing (and sometimes breaking) at the same time. ----- Cheers, Sean -- View this message in context: http://forum.world.st/TDD-in-Core-tp4735378.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 9, 2014