- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Athens SVG Import

by J.F. Rick

Sure, but getting the glue between Athens and Morphic right is important if we want Morphic to successfully use Athens. I'll investigate it sometime and see where the problem lies. BTW, I'm starting to work on the SVG thing. There definitely are a few things missing from the specification. For instance, opacity does not work that well. I'll just see what bugs I find and try to put solutions to them together. One thing that occurred to me is that we may want to think about abstracting a bit up from the SVG format. Could we have a more universal vector format that can be read from an SVG and can be written to an SVG but could also have other applications (e.g., Postscript)? What I am thinking of is something along the lines of forms. They can be written out as JPGs or PNGs but they aren't very JPG or PNG like when you are using them. Cheers, Jeff On Thu, Jan 9, 2014 at 1:07 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 9 January 2014 12:54, J.F. Rick <self(a)je77.com> wrote: > >> '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. >> >> > Lets make things clear: Athens is responsible for drawing things on canvas. > It is not responsible for what you drawing, when and where. Such things is > beyond the scope of Athens. > So, if there's a bug it could be related to some Morphic glue code (like > in AthensWrapMorph etc). That is possible. > And so, if you suspecting there's something wrong, look in that direction, > and don't loose time trying to fix something in Athens because these things > actually belong to morphic. > > > >> 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 >> > > > > -- > Best regards, > Igor Stasenko. > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

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? Marcus

Jan. 9, 2014

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

by btc＠openinworld.com

Jan. 9, 2014

Re: [Pharo-dev] TDD in Core

by Sean P. DeNigris

EstebanLM wrote > in the case of Spec in particular, the problem is that is really hard to > have UI testing :( I don't mean to pick on Spec. I'm very grateful for all the work Ben is doing. It's just that it has become essential to getting any work done in Pharo, and is undergoing a lot of changes, and in my recent 3.0 experience is causing a lot of pain. And while some UI testing is hard: - it's much easier in Pharo than anywhere else, since widgets = Morphic = just another part of the live, turtles all the way down environment - see the UI testing stuff I did which is in core and let's you simulate clicks, menu selections, etc - some of the breakage did not even require UI interaction to test. For example, for SliderModel, this simple statement, which doesn't even open the UI, would've caught the bug: "SliderModel new buildWithSpec", but there are only 7 tests to cover all of Spec, none of which mention SliderModel. We haven't even felt the pain of hard stuff because we've all (of course myself included) created a culture where testing is secondary or non-existent. And of course I'm only speaking about testing, not backward-compatibility. Although, while we're on the subject, the changes with this last iteration were significant enough to necessitate more communication. For example, you can no longer return a Morph instead of a model from a Spec accessor, but instead have to convert to some kind of adaptor. How the heck could I know that?! I had to dig through examples of Spec tools in the image to see how it is now doneâ¦ more time lost... In working with 3.0 recently, a fair amount of my time (it feels like most, but I may be exaggerating) has been spent chasing bugs on untested, undocumented features, which is why I resisted porting (see recent list thread). Don't get me wrongâ¦ I happily pound on our new versions close to release time and fix as much as I can. And I understand that some of this is inevitable. But when these problems are caused by *new* features, what could've been caught by the code-writer via tests will take me 10x as long to: 1. file a bug 2. mail the list 3. investigate through unfamiliar code 4. make the fix 5. wait for review â¦ etcâ¦ you get the idea My goal is to discover the path toward maximum effectiveness, and IMHO we have swung a bit too far toward "throw it in the image and wait for the bug reports", especially for critical components, when a bit of testing and documentation could free us all to work on other important parts of the system. Thanks for listening... ----- Cheers, Sean -- View this message in context: http://forum.world.st/TDD-in-Core-tp4735378p4735482.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 9, 2014

Re: [Pharo-dev] [Issue tracker] 46 issues in TODO for Pharo3

by btc＠openinworld.com

Jan. 9, 2014

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

by Sebastian Sastre

the solution is to set that on settings use barriers for protection and let hackers do its risky thing Pharo will be better if Igor can use it like a ninja and the rest of us noobs not so eager to loose code changes stick to a safer workflow On Jan 9, 2014, at 1:50 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > 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_… > > > Esteban A. Maringolo > > > 2014/1/9 Igor Stasenko <siguctua(a)gmail.com>: > > > > > > > > On 9 January 2014 14:03, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> > >> > >> On 09 Jan 2014, at 13:59, kilon alios <kilon.alios(a)gmail.com> wrote: > >> > >> > yes this lead to endless debate, but I think this is good because we see > >> > diffirent ways into looking into things. I have to admit till today I never > >> > expected that someone would be against confirm dialogs to such extend of > >> > wanting them to be removed completely, but I can see now that for people > >> > that dont make mistakes or they rather live with these mistakes would prefer > >> > a non confirmation approach. Its good to discuss these things because next > >> > time I will try to "fix" something I will try to do it in a way that pleases > >> > most people and not interrupting their workflow. > >> > > >> > And its endless because people prefer diffirent things, and thats ok. > >> > Opinions should be expressed and be respected. Opinions matter to make > >> > software better . Afterall software is made to please people by doing the > >> > things they want . No software of course is perfect. :) > >> > > >> > I completely respect Igor's opinion. And Igor its great you have worked > >> > on these things and thank you :) You should promote your work I think > >> > progress should be more carefully logged so we can all appreciate the work > >> > that goes inside pharo :) > >> > > >> > >> A editor key combination that looses code because is does not support undo > >> is *wrong*. Completely and utterly *wrong*. > >> > > > > Crippling the feature is *wrong*. Completely and utterly *wrong*. > > As we all agreed , the proper fix to cmd-l problem is make it undoable. > > An *improper* fix is put warnings everywhere. Warnings do not prevent from > > mistakes, > > they just do things worse at times. > > That's all what wanted to say. > > > >> > >> > >> Marcus > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > -- > Best regards, > Igor Stasenko.

Jan. 9, 2014

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

by Igor Stasenko

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_… Esteban A. Maringolo 2014/1/9 Igor Stasenko <siguctua(a)gmail.com>: > > > > On 9 January 2014 14:03, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> On 09 Jan 2014, at 13:59, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> > yes this lead to endless debate, but I think this is good because we see >> > diffirent ways into looking into things. I have to admit till today I never >> > expected that someone would be against confirm dialogs to such extend of >> > wanting them to be removed completely, but I can see now that for people >> > that dont make mistakes or they rather live with these mistakes would prefer >> > a non confirmation approach. Its good to discuss these things because next >> > time I will try to "fix" something I will try to do it in a way that pleases >> > most people and not interrupting their workflow. >> > >> > And its endless because people prefer diffirent things, and thats ok. >> > Opinions should be expressed and be respected. Opinions matter to make >> > software better . Afterall software is made to please people by doing the >> > things they want . No software of course is perfect. :) >> > >> > I completely respect Igor's opinion. And Igor its great you have worked >> > on these things and thank you :) You should promote your work I think >> > progress should be more carefully logged so we can all appreciate the work >> > that goes inside pharo :) >> > >> >> A editor key combination that looses code because is does not support undo >> is *wrong*. Completely and utterly *wrong*. >> > > Crippling the feature is *wrong*. Completely and utterly *wrong*. > As we all agreed , the proper fix to cmd-l problem is make it undoable. > An *improper* fix is put warnings everywhere. Warnings do not prevent from > mistakes, > they just do things worse at times. > That's all what wanted to say. > >> >> >> Marcus > > > > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

Jan. 9, 2014

Re: [Pharo-dev] Advanced Reflection in Pharo

by Torsten Bergmann

Marcus Denker >I would like to, but then of course it would be difficultâ¦ client code would need to be changed, without name >spaces there might even be clashes with client class namesâ¦ >Â >So for now, I think we need to ignore the ugly names a bit and focus on making the model very nice else (and use itâ¦). Damn, already january. Santa is just gone and I forgot to ask him about "Namespaces for Pharo" which is also very high on my personal wishlist. Looks like Squeak got a similar present with "environments" already... Next winter and christmas will for sure come and we may be able to write/distinguish "Twitter::Bootstrap" and "Pharo::Bootstrap" in a workspace then!? So either santa will magically be able to transform the wishlist into a todolist or completed-list. Maybe we should help him ;) Bye T.

Jan. 9, 2014

Re: [Pharo-dev] CI server account creation

by Alfredo Sanzo

Te zarpÃ¡s. (Which, in *very informal* Argentinian Spanish slang means "You are a genious"). Thanks :D It was in spam. 2014/1/9 Christophe Demarey <Christophe.Demarey(a)inria.fr> > Hello Alfredo, > > Le 8 janv. 2014 Ã 23:58, Alfredo Sanzo a Ã©crit : > > Hello! > > I am trying to create an account for the CI server and I have bumped into > several links and posts to this list and now that I've asked for help I've > finally understood the process (I think). > My question is... Can we have this written somewhere? (and corrected, if > I'm wrong :) ) > > "Steps to create a new user: > a) Sign up for a user here: https://ci.inria.fr/users/new > It gets processed manually, so you have to wait until your account is > activated for you. > > > => not true. There is no manual validation. > Once you get registered, ci.inria.fr send you an email to validate your > account. > You need to click on the provided link. > > b) Go to: https://ci.inria.fr/project and look for pharo-contribution. > Request to join it. (it also gets processed manually) > > > Yes, an admin of this project has to accept the join request. > > c) Ask in pharo-dev(a)lists.pharo.org to be made an Admin, because if not > you won't be able to create a Job. > > > Also true. > I updated Jenkins to add more permissions to members. > All pharo-contibution members are now allowed to manage jobs. > > " > > I see that Pharo-Contribution page redirects here: > https://ci.inria.fr/pharo-contribution/job/JobTemplate/ > Can we have that step 1 updated with what I wrote here? > > > > Good idea. Done! > > --------------------- > Oh, and I can't get through part a) yet.... Apparently no one is accepting > my user... Can somebody help? > > > > Maybe you should check your spams. > If you cannot find the account activation email, tell me. I can force the > account activation. > > Regards, > Christophe. >

Jan. 9, 2014

Re: [Pharo-dev] Advanced Reflection in Pharo

by Marcus Denker

On 09 Jan 2014, at 16:10, btc(a)openinworld.com wrote: > As I was looking at Marcus' [1] "Advanced Relection in Pharo" slide 34 I wondered if at some point the RB will be stripped from the front of those class names, since it seems the use is now intended to be wider than just the Refactoring Browser. > I would like to, but then of course it would be difficultâ¦ client code would need to be changed, without name spaces there might even be clashes with client class namesâ¦ So for now, I think we need to ignore the ugly names a bit and focus on making the model very nice else (and use itâ¦). Marcus

Jan. 9, 2014