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

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

by Thierry Goubier

Hi Ben, Interesting find. 2018-06-08 14:29 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > I bumped into a paper "Empirical Analysis of Programming Language Adoption" > that I thought might be of interest to others since we'd like to increase > Pharo's mindshare. (http://sns.cs.princeton.edu/docs/asr-oopsla13.pdf) > > TLDR; my top three take outs were... > > Figure 5 indicates that simple syntax and languages features don't attract > new users, and of the things we can control the most important are... > performance, portability and development speed. This is interesting, and they also insist in the paper that developpers do not care that much about the semantics of what they use... > Figure 12 suggests a strategy to promote useful libraries rather than > language features. I guess that might best take take the form blogs showing > the use of libraries. And have librairies that are really usefull... A possible strategy then would be a stable, clean core, and librairies that really make a difference. > Table 7 makes and interesting assertion that static types are more important > for readability than preventing bugs. This one is in line with Dan Luu meta-study that static typing catches at best a small proportion of bugs. Note that this is used in Smalltalk, when you write anInteger, aString : you're using a form of typing for documentation. By the way, I wrote for fun a small metalink-based run-time type-checker using method argument names. To be used when running unit tests :) Regards, Thierry > cheers -ben > > > P.S. Then I bumped into "Toward Semantic Foundations for Program Editors" > (https://arxiv.org/pdf/1703.08694.pdf) > which was over my head but I guess it might be interesting to people working > in UI area.

June 8, 2018

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

by Sean P. DeNigris

Ben Coman wrote > the most important are... > performance, portability and development speed. I wonder about this because Ruby and Python are no speed demons and it's hard to imagine anyone (except maybe lisp) beating Smalltalk in development speed. I didn't read the article, but it seems to me the main factor in popularity is random chance because the industry is a pop culture where trends are more about being cool (or getting a job) than any underlying principles. Coding "academies" seem to be the latest caricature of this phenomenon: "Want to code? For just $1,995 we'll will get you job ready w the sexiest languages in just 3 weeks! And that's not allâ¦ we'll even throw in this ironic hipster coding T-shirt for free!!" That said, IMHO mainstream popularity is a curse. The sweet spot is a critical mass where the core and desired libraries are available and maintained. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 8, 2018

Empirical Analysis of Programming Language Adoption

by Ben Coman

I bumped into a paper "Empirical Analysis of Programming Language Adoption" that I thought might be of interest to others since we'd like to increase Pharo's mindshare. (http://sns.cs.princeton.edu/docs/asr-oopsla13.pdf) TLDR; my top three take outs were... Figure 5 indicates that simple syntax and languages features don't attract new users, and of the things we can control the most important are... performance, portability and development speed. Figure 12 suggests a strategy to promote useful libraries rather than language features. I guess that might best take take the form blogs showing the use of libraries. Table 7 makes and interesting assertion that static types are more important for readability than preventing bugs. cheers -ben P.S. Then I bumped into "Toward Semantic Foundations for Program Editors" (https://arxiv.org/pdf/1703.08694.pdf) which was over my head but I guess it might be interesting to people working in UI area.

June 8, 2018

[Pharo 7.0-dev] Build #1025: 22087-Integrate-new-Calypso-v0114

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

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

June 8, 2018

Re: [Pharo-dev] [squeak-dev] Why do we have SmallDictionary?

by Andres Valloud

In addition, open addressing with linear probing has superior cache line read behavior (no indirection / random traversal, and if the first probe misses the second one was likely cached by the first one). On 6/8/18 1:37 , Levente Uzonyi wrote: > On Fri, 8 Jun 2018, ClÃ©ment Bera wrote: > >> Hi Max, >> Theoretically, for a small number of elements, usually somewhere >> between 3 and 30 depending on implementations, a linear search is >> faster than a hash search, especially in the Pharo dictionary hash search >> implementation. >> >> Efficient dictionary implementations are usually bucket-based. The >> dictionary holds a certain number of buckets, and based on the key >> hash, the bucket where the key value is present is determined. Small >> buckets are linear (arrays or linked list). Large buckets are >> typically balanced binary trees (red-black trees typically). Under a >> certain number of elements there is a single bucket, which means a linear >> search is performed, as for the SmallDictionary. When it grows the >> dictionary search becomes a combination between a hash search and a >> linear or tree search. > > The bucket-based list you described is called separate chaining > collision resolution, and it won't have any better performance in Squeak > than the currently used open addressing. > However, it is preferrable, when you can't trust your hash function. > When you do "crazy" things, like using a tree as a bucket, you just > exchange the possible O(n) worst case time with O(log(n)). > >> >> Pharo dictionary search is first hash-based, then all the buckets are >> represented next to each other in the same arrays and a linear search >> is performed there, leading to many collisions and slower search >> time (especially when the element is not found), sometimes the code >> searches over multiple buckets because the dictionary is too full or >> there are too many near-collisions. The memory consumption is >> competitive with the advanced implementations though (precise >> measurements would need to be made). > > This is called open addressing, and if your hash function is good > enough, the lists are short, so those "many collisions and slower search > time" just don't happen. And no, separate chaining needs a lot more > memory than open addressing, unless you manage to get rid of > Associations, but that's a lot harder than it sounds like. > >> >> Method dictionaries are represented differently to optimize the >> look-up logic. > > MethodDictionary is optimized to let the VM do lookups more easily. > Memory consumption is worse when the dictionary is sparse, but gets > better as it gets filled up compared to the current Dictionary > implementation (assuming Pharo still uses the same representation as > Squeak does). > >> >> If you want to improve things and have one dictionary implementation >> instead of two, implement or look for a bucket based dictionary and >> put it in the base image instead of Dictionary. This is quite some work >> since there are many APIs to port. You can look at the Pinnochio >> implementation, it's quite good but they've not implemented large >> buckets. > > Well, as an experiment, I'm sure it'll be fun. But don't expect better > performance nor better memory usage. > > Levente > >> >> >> >> On Fri, Jun 8, 2018 at 8:46 AM, Max Leske <maxleske(a)gmail.com> wrote: >> Hi, >> >> I was messing around with SmallDictionary when I suddenly >> realised that I can't find a single reason to use it over a normal >> Dictionary. While its name and class comment imply that it is somehow >> an optimised Dictionary, I don't see any measurement where that >> actually holds up. The following was run in a Pharo 7 image on a >> recent VM (see below): >> >> | d | >> d := SmallDictionary new. >> d sizeInMemory. "24" >> [100000 timesRepeat: [ >> 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. >> "0:00:00:05.226" >> >> [100000 timesRepeat: [ >> d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.041" >> >> >> >> | d | >> d := Dictionary new. >> d sizeInMemory. "16" >> [100000 timesRepeat: [ >> 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. >> "0:00:00:00.385" >> [100000 timesRepeat: [ >> d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.006" >> >> >> As you can see, SmallDictionary is 8 bytes larger per instance >> and significantly faster while reading and writing (I know that this >> isn't a good benchmark but it suffices to make my point). >> >> >> Is anyone aware of a reason for hanging on to SmallDictionary? >> I'm also curious to know how SmallDictionary came to be. There must >> have been some advantage over Dictionary at some point in the >> past. >> >> >> Cheers, >> Max >> >> >> >> >> >> Image version: Pharo 7.0 >> Build information: >> Pharo-7.0+alpha.build.961.sha.a69e72a97136bc3f93831584b6efa2b1703deb84 >> (32 Bit) >> >> VM version: CoInterpreter VMMaker.oscog- nice.2281 uuid: >> 4beeaee7-567e-1a4b-b0fb-bd95ce302516 Nov 27 2017 >> StackToRegisterMappingCogit VMMaker.oscog-nice.2283 uuid: >> 2d20324d-a2ab-48d6-b0f6-9fc3d66899da Nov 27 2017 >> VM: 201711262336 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Mon Nov >> 27 00:36:29 2017 +0100 $ Plugins: 201711262336 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> >> OS: macOS 10.13.5 >> Machine: MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports) >> >> >> >> >> -- >> ClÃ©ment BÃ©ra >> https://clementbera.github.io/https://clementbera.wordpress.com/ >> >> > > >

June 8, 2018

Re: [Pharo-dev] #literals and #hasLiteral: not in sync

by Marcus Denker

> On 8 Jun 2018, at 12:42, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi Marcus. > > #literals and #allLiterals are good idea but maybe we can better distinguish them using more specific names like: > - for all literals: encodedLiterals or allEncodedLiterals > - for real literals: syntaxLiterals, semanticLiterals, userLiterals, sourceCodeLiterals > I am not sure. that looks even more complex to me. > 2018-06-08 11:17 GMT+03:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > Hi, > > As you might now, we abuse the literals of compiled methods to hold on to the class and the literal. (and the place used to store the literal is used for > additional properties if there are some). > > So right now we have the problem that #literals just returns all the literals and clients do âallButLastâ to filter out the class binging, but they ignore the selector. > > #hasLiteral: doe the filtering *and* it filters the last two. All quite confusing. > > So, this is true: > > (Object >> #yourself) literals includes: #yourself. > (Object >> #yourself) hasLiteralSuchThat: [ :lit | lit = #yourself]. > > > but this is false: > > (Object >> #yourself) hasLiteral: #yourself. > (Object >> #yourself) hasLiteralThorough: #yourself. > > I suggest we make this simpler by: > > -> #allLiterals return all the literals, even the abused last two > -> #literals returns what you think it should: the true literals of the method, without the last two abused fields. > -> fix all cases of âliterals allButLastâ, there are not many. > > https://github.com/pharo-project/pharo/pull/1502/files <https://github.com/pharo-project/pharo/pull/1502/files> > > Is there any reason why this could be bad? > > Marcus >

June 8, 2018

Re: [Pharo-dev] #literals and #hasLiteral: not in sync

by Denis Kudriashov

Hi Marcus. #literals and #allLiterals are good idea but maybe we can better distinguish them using more specific names like: - for all literals: encodedLiterals or allEncodedLiterals - for real literals: syntaxLiterals, semanticLiterals, userLiterals, sourceCodeLiterals 2018-06-08 11:17 GMT+03:00 Marcus Denker <marcus.denker(a)inria.fr>: > Hi, > > As you might now, we abuse the literals of compiled methods to hold on to > the class and the literal. (and the place used to store the literal is used > for > additional properties if there are some). > > So right now we have the problem that #literals just returns all the > literals and clients do âallButLastâ to filter out the class binging, but > they ignore the selector. > > #hasLiteral: doe the filtering *and* it filters the last two. All quite > confusing. > > So, this is true: > > (Object >> #yourself) literals includes: #yourself. > (Object >> #yourself) hasLiteralSuchThat: [ :lit | lit = #yourself]. > > > but this is false: > > (Object >> #yourself) hasLiteral: #yourself. > (Object >> #yourself) hasLiteralThorough: #yourself. > > I suggest we make this simpler by: > > -> #allLiterals return all the literals, even the abused last two > -> #literals returns what you think it should: the true literals of the > method, without the last two abused fields. > -> fix all cases of âliterals allButLastâ, there are not many. > > https://github.com/pharo-project/pharo/pull/1502/files > > Is there any reason why this could be bad? > > Marcus >

June 8, 2018

[Pharo 7.0-dev] Build #1024: 22072-Begin-to-add-requirements-to-BaselineOfDisplay

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

There is a new Pharo build available! The status of the build #1024 was: SUCCESS. The Pull Request #1490 was integrated: "22072-Begin-to-add-requirements-to-BaselineOfDisplay" Pull request url: https://github.com/pharo-project/pharo/pull/1490 Issue Url: https://pharo.fogbugz.com/f/cases/22072 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 8, 2018

[Issue Tracker] Please check issue tracker

by Marcus Denker

Hi, If you -> submitted an issue in the past -> have been involved in some discussion about an issue ===> please check the issue tracker. There are many cases where e.g. - some issue has been fixed but the issue tracker entry is not closed - where a discussion came to a conclusion but no action happened. - you reported issue has been fixed in the meantime but the issue tracker entry is still open. https://pharo.fogbugz.com/f/filters/57/All-newest-first We have right now 471 open issues, I am sure we can get that number down! Marcus

June 8, 2018

#literals and #hasLiteral: not in sync

by Marcus Denker

Hi, As you might now, we abuse the literals of compiled methods to hold on to the class and the literal. (and the place used to store the literal is used for additional properties if there are some). So right now we have the problem that #literals just returns all the literals and clients do âallButLastâ to filter out the class binging, but they ignore the selector. #hasLiteral: doe the filtering *and* it filters the last two. All quite confusing. So, this is true: (Object >> #yourself) literals includes: #yourself. (Object >> #yourself) hasLiteralSuchThat: [ :lit | lit = #yourself]. but this is false: (Object >> #yourself) hasLiteral: #yourself. (Object >> #yourself) hasLiteralThorough: #yourself. I suggest we make this simpler by: -> #allLiterals return all the literals, even the abused last two -> #literals returns what you think it should: the true literals of the method, without the last two abused fields. -> fix all cases of âliterals allButLastâ, there are not many. https://github.com/pharo-project/pharo/pull/1502/files <https://github.com/pharo-project/pharo/pull/1502/files> Is there any reason why this could be bad? Marcus

June 8, 2018