- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] logCr in SpecDebugger

by Andrei Chis

No there isn't :) (must have forgot it there) On Thu, Jan 9, 2014 at 7:06 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > Hi, > > I found this in SpecDebugger>>#updateCodeFromContext: > > ... > self logCr: aContext receiver class. > ... > > is there any any reason? > > Esteban > >

Jan. 9, 2014

logCr in SpecDebugger

by Esteban Lorenzano

Hi, I found this in SpecDebugger>>#updateCodeFromContext: ... self logCr: aContext receiver class. ... is there any any reason? Esteban

Jan. 9, 2014

Re: [Pharo-dev] TDD in Core

by Sven Van Caekenberghe

One thing I have learned (about myself) is this: first you write a cool piece of library/framework/tool/... and you make it as good and as clean as possible (first iteration). When you write unit tests (which you should do during development, let's leave in the middle whether that should be before or after ;-), your code will improve (a lot) because you have to make things cleanly testable (which can be hard). Quality improves. Then you write methods and class comments (again, before or after) and you realise that thing are hard to explain which will lead you to refactoring, renaming, cleaning and adding missing pieces. Quality improves. Finally, you (try) to write the high level overview document. You want to prove how good your stuff is, you want to have nice, clean examples. Again you will change stuff because of what you learn trying to explain yourself. Quality improves. After to you publish, feedback and contributions come in. Quality improves. Do a couple of these cycles. Quality goes through the roof ;-) It sounds harder than it is, but it is worth it. And Spec already has lots of the required pieces, I think it just needs some polishing. On 09 Jan 2014, at 18:28, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > As usual the problem is that it takes time :) > (and also that I am a newbie when it comes to write :P) > > Ben > > On 09 Jan 2014, at 14:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 09 Jan 2014, at 18:14, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> >>> For Spec, I actually sent a mail in the mailing list when integrated explaining how to move to the new version :) >>> But indeed, not enough documentation about it is present, this is why I am currently spending time writing some :P >>> (but you already know that :P) >>> >>> I think the overall remark is good :) >>> We should not integrate things in Pharo if they are under tested (Spec included). >>> >>> I think that the next month will be spent on writing more tests or Spec >>> >>> Ben >> >> Yes, some good, high-level, independent docs (like a book chapter) combined with unit tests will improve things a lot. And there are already existing examples. >> >> We'll get there, I am sure. >> >> Thanks for all the efforts. >> >> Sven >

Jan. 9, 2014

Re: [Pharo-dev] TDD in Core

by Benjamin

As usual the problem is that it takes time :) (and also that I am a newbie when it comes to write :P) Ben On 09 Jan 2014, at 14:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 09 Jan 2014, at 18:14, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> For Spec, I actually sent a mail in the mailing list when integrated explaining how to move to the new version :) >> But indeed, not enough documentation about it is present, this is why I am currently spending time writing some :P >> (but you already know that :P) >> >> I think the overall remark is good :) >> We should not integrate things in Pharo if they are under tested (Spec included). >> >> I think that the next month will be spent on writing more tests or Spec >> >> Ben > > Yes, some good, high-level, independent docs (like a book chapter) combined with unit tests will improve things a lot. And there are already existing examples. > > We'll get there, I am sure. > > Thanks for all the efforts. > > Sven

Jan. 9, 2014

Re: [Pharo-dev] TDD in Core

by Sven Van Caekenberghe

On 09 Jan 2014, at 18:14, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > For Spec, I actually sent a mail in the mailing list when integrated explaining how to move to the new version :) > But indeed, not enough documentation about it is present, this is why I am currently spending time writing some :P > (but you already know that :P) > > I think the overall remark is good :) > We should not integrate things in Pharo if they are under tested (Spec included). > > I think that the next month will be spent on writing more tests or Spec > > Ben Yes, some good, high-level, independent docs (like a book chapter) combined with unit tests will improve things a lot. And there are already existing examples. We'll get there, I am sure. Thanks for all the efforts. Sven

Jan. 9, 2014

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

by phil＠highoctane.be

About Varicad: Check the bottom left area saying "command". Any icon is doing some command thing. So, once you know them, you type them in the box. Kind of DSL thing. For $650, there is a lot in the package. Competition are in the thousands. Google Sketchup is not up to anything, nor is open source in that area. Phil On Thu, Jan 9, 2014 at 6:05 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > Hi all -- I didn't read this discussion closely, I just saw this > screenshot and had to say something. I do not wish to criticize Varicad > since it's evident the developers put a lot of work into the domain > functionality.. > > .. But this UI design provides way too-low "functional-density". They're > letting "commands" drive the UI-design rather than domain objects. Those > icon images are probably burning into their monitor screens and eating up > valuable screen space that could otherwise be used to present the domain in > a less distracting fashion (i.e., with contextually available commands > appearing on-demand). > > I'm glad to see Pharo regarding this as an example of what _not_ to do. :) > > > On Thu, Jan 9, 2014 at 5:11 AM, 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: >> [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. >>> >> >> >

Jan. 9, 2014

Re: [Pharo-dev] TDD in Core

by Benjamin

For Spec, I actually sent a mail in the mailing list when integrated explaining how to move to the new version :) But indeed, not enough documentation about it is present, this is why I am currently spending time writing some :P (but you already know that :P) I think the overall remark is good :) We should not integrate things in Pharo if they are under tested (Spec included). I think that the next month will be spent on writing more tests or Spec Ben

Jan. 9, 2014

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

by Chris Muller

Hi all -- I didn't read this discussion closely, I just saw this screenshot and had to say something. I do not wish to criticize Varicad since it's evident the developers put a lot of work into the domain functionality.. .. But this UI design provides way too-low "functional-density". They're letting "commands" drive the UI-design rather than domain objects. Those icon images are probably burning into their monitor screens and eating up valuable screen space that could otherwise be used to present the domain in a less distracting fashion (i.e., with contextually available commands appearing on-demand). I'm glad to see Pharo regarding this as an example of what _not_ to do. :) On Thu, Jan 9, 2014 at 5:11 AM, 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: > [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. >> > >

Jan. 9, 2014

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

by Esteban A. Maringolo

2014/1/9 Igor Stasenko <siguctua(a)gmail.com>: > On 9 January 2014 14:29, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >> From time to time, a slippery road warning sign is good even for the >> best driver. >> > I like your analogy with roads and driver. Let me put mine, which i think > fits better for modal dialogs: > https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcR1S9qdN4wl00uaCdNa70_… :) In a normal world road signs are placed beside or above the road. Never in the middle, unless there is something exceptional ahead, like an accident that can cause you to lose your live, or your code (which sometimes feels alike :P) Esteban A. Maringolo

Jan. 9, 2014

Re: [Pharo-dev] [Pharo3] The last test failing...

by Marcus Denker

> > On 09 Jan 2014, at 17:29, btc(a)openinworld.com wrote: > >> Marcus Denker wrote: >>> >>> 12377 ZnHTTPSTests.>>testGetPharoVersion fails on Windows slave >>> https://pharo.fogbugz.com/f/cases/12377 >>> >>> And this is just a build server artefactâ¦ (windows slave firewall problem). >>> >>> I wonder what to doâ¦ maybe we could just skip it on windows when running on the build slave ;-) >>> >>> Marcus >>> >>> >> Was the DNS lookup error cannot resolve âci.inria.fr' the only problem? or would access to the server also be blocked? >> If only the former, did you consider preloading the DNS resolver cache from hosts file per [1], which provides a number of options: >> * refer to ci.inria.fr server via its a private subnet IP address, rather than the public facing IP address >> * fake up ci.inria.fr as a second IP address on the slave to which web server can be bound and configured to deliver the require file >> Of course the additional effort for these versus the gain needs to be balanced. >> >> btw, useful commands for testing these are [2]: >> * ipconfig /displaydns >> * ipconfig /flushdns >> >> [1] http://technet.microsoft.com/en-us/library/cc780585(v=ws.10).aspx >> [2] http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en… >> > > No, the thing is: Does it make sense to invest a lot of time into this or are there not more important things? > > There is a point where I get endlessly tiredâ¦ so many many many things, sometimes a simple workaround is just the easiest. Marcus

Jan. 9, 2014