June 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Empirical Analysis of Programming Language Adoption

by Thierry Goubier

Hi Ben, Le 09/06/2018 Ã 10:21, Ben Coman a Ã©critÂ : > > > On 8 June 2018 at 23:06, Thomas Dupriez > <thomas.dupriez(a)ens-paris-saclay.fr > <mailto:thomas.dupriez@ens-paris-saclay.fr>> wrote: > > Hello, > I wanted to just write a quick comment, but it turned into an essay, > sorry. ^^ > > Le 08/06/2018 Ã 16:35, Nicolas Cellier a Ã©critÂ : >> >> >> 2018-06-08 14:50 GMT+02:00 Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>>: >> >> >> Note that this is used in Smalltalk, when you write anInteger, >> aString >> : you're using a form of typing for documentation. >> >> Exactly! >> >> And if you transpose this style to static typing you get things like >> Â Â Â Cat *theCat = new Cat; >> Being tainted, I always thought that is was noise... >> You'd better rename your variable felix;) > Naming variables/arguments according to their type is only half a > solution I think. > Because there are actually two things I would like to know about a > variable/argument when reading code: its type and its meaning. > For example, knowing that an argument named "anInt" is an integer is > nice, but I would also like to know that it's the number of dice the > method has to roll. The two information are very useful to quickly > understand the code. > > From what I've seen in Pharo, variables are usually named after > their meaning, while method argument are named after their type, but > in an ideal world I would like to know both the type and the meaning > of both the variables and the arguments. > > That's in my opinion one of the advantages of explicit types for > reading code: you write the type besides the variable/argument, so > the name of the variable/argument can describe its meaning and I > have both informations. > >> Static typing may help the IDE (refactoring and navigating). >> My POV is thus that you enter this information for the tools, not >> for the humans (compiler, navigator, refactoring engine, ...). >> >> I have differently tainted colleagues still thinking that the type >> help them reading code... >> So, IMO, this assertion reflects the dominant culture rather than >> intrinsic merits. >> IOW, if you want to create a successfull language, just clone an >> existing one :( > I would agree with your colleagues. I got stuck countless times when > reading pharo code, because there was a message send to a variable I > didn't know the type of, so I couldn't know which method was being > called (because there were multiple methods with that name in the > system). So the only solution was to place a breakpoint and get that > method to be executed. This is not so easy (at least for me) in > programs that are not really simple, because: > 1) I need to have this method executed in its "normal use > environment". I can't just execute it with dummy values as argument, > because that will affect the values the variables will take. > > > Has anyone looked at capturing all types assigned to variables while > unit tests are running? Yes. A code trace tool like mine can provides you with that. Determining which variables have to be tracked is a bit complex if the developper doesn't provides that information. > What mechanisms do we have available that might help do this? Metalinks, your usual trace tool code rewriting techniques, even RB. I have been unsuccessfull at using metalinks for heavy (many, many probes) method instrumentation. Metalinks and my trace tool more or less produces the same code, as far as the vm is concerned. > Then we might hovering over a variable to display the percentage actual > occurrence of types in that variable. If you equates type with class, that is. > (A side effect is this could be an indication of test code coverage.) Thierry > 2) I can look into tests, but since I don't know the program, I have > no idea which tests to run to execute the piece of code. > > > Makes me think a useful feature would be "what tests run that pass this > point", and run one of them breaking at "this point". > Then you'd quickly have a live stackÂ to peruse. > > > cheers -ben

June 9, 2018

[Pharo 7.0-dev] Build #1029: 22100-Add-exampleSuperReceiverexampleSelfReceiver-and-isSelfOrSuper

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1029 was: SUCCESS. The Pull Request #1510 was integrated: "22100-Add-exampleSuperReceiverexampleSelfReceiver-and-isSelfOrSuper" Pull request url: https://github.com/pharo-project/pharo/pull/1510 Issue Url: https://pharo.fogbugz.com/f/cases/22100 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 9, 2018

Re: [Pharo-dev] Empirical Analysis of Programming Language Adoption

by Ben Coman

On 8 June 2018 at 23:06, Thomas Dupriez <thomas.dupriez(a)ens-paris-saclay.fr> wrote: > Hello, > I wanted to just write a quick comment, but it turned into an essay, > sorry. ^^ > > Le 08/06/2018 Ã 16:35, Nicolas Cellier a Ã©crit : > > > > 2018-06-08 14:50 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> >> Note that this is used in Smalltalk, when you write anInteger, aString >> : you're using a form of typing for documentation. >> >> Exactly! > > And if you transpose this style to static typing you get things like > Cat *theCat = new Cat; > Being tainted, I always thought that is was noise... > You'd better rename your variable felix;) > > Naming variables/arguments according to their type is only half a solution > I think. > Because there are actually two things I would like to know about a > variable/argument when reading code: its type and its meaning. > For example, knowing that an argument named "anInt" is an integer is nice, > but I would also like to know that it's the number of dice the method has > to roll. The two information are very useful to quickly understand the code. > > From what I've seen in Pharo, variables are usually named after their > meaning, while method argument are named after their type, but in an ideal > world I would like to know both the type and the meaning of both the > variables and the arguments. > > That's in my opinion one of the advantages of explicit types for reading > code: you write the type besides the variable/argument, so the name of the > variable/argument can describe its meaning and I have both informations. > > Static typing may help the IDE (refactoring and navigating). > My POV is thus that you enter this information for the tools, not for the > humans (compiler, navigator, refactoring engine, ...). > > I have differently tainted colleagues still thinking that the type help > them reading code... > So, IMO, this assertion reflects the dominant culture rather than > intrinsic merits. > IOW, if you want to create a successfull language, just clone an existing > one :( > > I would agree with your colleagues. I got stuck countless times when > reading pharo code, because there was a message send to a variable I didn't > know the type of, so I couldn't know which method was being called (because > there were multiple methods with that name in the system). So the only > solution was to place a breakpoint and get that method to be executed. This > is not so easy (at least for me) in programs that are not really simple, > because: > 1) I need to have this method executed in its "normal use environment". I > can't just execute it with dummy values as argument, because that will > affect the values the variables will take. > Has anyone looked at capturing all types assigned to variables while unit tests are running? What mechanisms do we have available that might help do this? Then we might hovering over a variable to display the percentage actual occurrence of types in that variable. (A side effect is this could be an indication of test code coverage.) > 2) I can look into tests, but since I don't know the program, I have no > idea which tests to run to execute the piece of code. > Makes me think a useful feature would be "what tests run that pass this point", and run one of them breaking at "this point". Then you'd quickly have a live stack to peruse. cheers -ben

June 9, 2018

Re: [Pharo-dev] ApplicationSecurity Questions

by HernÃ¡n Morales Durand

Hi Sean, El 6 jun. 2018, a las 22:37, Sean P. DeNigris <sean(a)clipperadams.com> escribiÃ³: hernanmd wrote You can check a project making use of ApplicationSecurity here: http://www.smalltalkhub.com/#!/~hernan/IGEVET â¦it uses Iliadâ¦ I'll check it out. Thanks. Out of curiosity, why Iliad instead of Seaside? Is Iliad well-supported/maintained? Of course not :) We are like 10? in the mailing list, you could say it seems like a dead project, but it performed really well for me (some reasons below). For people who like to feel always safe, Seaside is the best choice. However at some point after some years I felt Seaside uncomfortable, I read that Iliad picked some of the best features of Seaside and Aida, then wanted to gave a try. Would that be your default/recommendation for new web apps? First of all, I should say I'm not super experienced in web apps. Although I appreciate the big efforts behind Smalltalk web frameworks, I didnât really like any of them, neither page-centric or programmatic. None of them was easily adapted to the emerging web trends for the last years like the appearance of static site generators, adaptive/responsive design, multiple competing JS libraries, semantic web, mobility, etc. not to mention they lack "standard" built-in features such as caching, template, security frameworks. However I cannot complain, we are a small community doing the best we can, and the alternative of coding in a popular PHP framework would be like going to hell... think about matching "objects" to relational table schemas here (single table inheritance). I really love the Iliad form validation through Formula (easier than Magritte for me), the free Ajax, the simple routing, and it feels lightweight. However there a lot of things missing in Iliad by now: a Zinc adaptor is missing, better CSS integration, more documentation, examples, updated jQuery, etc. For other classic features, there was an old comparison table for Smalltalk web frameworks, a bit outdated but you could check it: https://docs.google.com/spreadsheets/d/1eiiY-ooLNN0aLhQfe0kTDnpgB2hjFrxJoka… Cheers, HernÃ¡n ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 9, 2018

[Pharo 7.0-dev] Build #1028: 16303-Unload-Old-Compiler

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1028 was: SUCCESS. The Pull Request #1508 was integrated: "16303-Unload-Old-Compiler" Pull request url: https://github.com/pharo-project/pharo/pull/1508 Issue Url: https://pharo.fogbugz.com/f/cases/16303 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 9, 2018

Re: [Pharo-dev] Annoying frame around ToolDockingBarMorph

by Hilaire

Why ? DockingBarMorph>>defaultBorderWidth Â Â Â ^ self theme menuBorderWidth Le 09/06/2018 Ã 09:27, Hilaire a Ã©critÂ : > I am not there yet, hope to have time. Now I just browse changes from > github, can see several changed related to use of theme borderwidth -- Dr. Geo http://drgeo.eu

June 9, 2018

Re: [Pharo-dev] Annoying frame around ToolDockingBarMorph

by Hilaire

Le 09/06/2018 Ã 09:14, Esteban Lorenzano a Ã©critÂ : > Cyril has been working on the docking bar. So what next? Could this change be revereted? >> As I don't know how to track the changes occurring in P7, any one has an idea about what happen? (we do not have anymore timestamp on method, or do I miss something? > If you connect your image with a pharo repository, you will have the history. > (in iceberg, you will see âpharoâ and it will have a âlocal directory missingâ messageâ¦ and a repair option that will allow you to clone or locate it) I am not there yet, hope to have time. Now I just browse changes from github, can see several changed related to use of theme borderwidth -- Dr. Geo http://drgeo.eu

June 9, 2018

Re: [Pharo-dev] Annoying frame around ToolDockingBarMorph

by Esteban Lorenzano

> On 9 Jun 2018, at 09:01, Hilaire <hilaire(a)drgeo.eu> wrote: > > Hi, > > Something changed recently in P7 in the theme or so, there is now a frame around the ToolDockingBarMorph. Cyril has been working on the docking bar. > > As I don't know how to track the changes occurring in P7, any one has an idea about what happen? (we do not have anymore timestamp on method, or do I miss something? If you connect your image with a pharo repository, you will have the history. (in iceberg, you will see âpharoâ and it will have a âlocal directory missingâ messageâ¦ and a repair option that will allow you to clone or locate it) cheers, Esteban > > DrGeo GUI is odd, see screenshot? > > Hilaire > > > -- > Dr. Geo > http://drgeo.eu > > <AnnoyingFrame.png>

June 9, 2018

Annoying frame around ToolDockingBarMorph

by Hilaire

Hi, Something changed recently in P7 in the theme or so, there is now a frame around the ToolDockingBarMorph. As I don't know how to track the changes occurring in P7, any one has an idea about what happen? (we do not have anymore timestamp on method, or do I miss something? DrGeo GUI is odd, see screenshot? Hilaire -- Dr. Geo http://drgeo.eu

June 9, 2018

Re: [Pharo-dev] Empirical Analysis of Programming Language Adoption

by Esteban Lorenzano

> On 9 Jun 2018, at 08:45, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Esteban, > > Le 09/06/2018 Ã 08:37, Esteban Lorenzano a Ã©crit : >>> On 9 Jun 2018, at 00:58, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> >>> Thomas Dupriez wrote >>>> I got stuck countless times when >>>> reading pharo code, because there was a message send to a variable I >>>> didn't know the type of, so I couldn't know which method was being >>>> called (because there were multiple methods with that name in the >>>> system). So the only solution was to place a breakpoint and get that >>>> method to be executed. >>> >>> That is an interesting perspective. I usually browse senders. This almost* >>> always seems to work, except when the message selector is very generic and >>> reused in different contexts (e.g. #next) >> then you can scope your senders. There are 99% of possibilities your message is sent within the context of the class or package you are looking for. > > Then a simple question is: > > - how do you scope your senders of command? > > A typical discovery / new user will do "senders of" first, and then discover the result is far too large. calypso has the possibility of scoping after look for senders. there is a drop box there (but it can be enhanced, often I want to scope several packages, not just one) > > Now, does he has to backtrack on its exploration, choose a scope and call 'senders of' again? nope. Esteban > > Thierry > >> Esteban >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>> > >

June 9, 2018