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

Characterizing Pharo Code: A Technical Report

by Oleksandr Zaytsev

Hello, We have analyzed the source code of the 50 projects selected from the Pharo ecosystem and reported our findings in this document: https://hal.inria.fr/hal-02440055v1 Perhaps, you will find it interesting. Here are some fun facts that we have discovered: - 25% of classes have no more than 3 methods in them, and 50% of classes have no more than 6 methods - The average number of lines of code in Pharo methods is 5.8, the median of this number is 3, meaning that 50% of methods have no more than 3 lines. - About a quarter of source code are message sends (method names) - they take 27.3% of source code tokens and 26.3% of characters. - On a character level, 22.5% of source code are string literals, and 19.4% are literal arrays. Together literals take 44% of characters in source code, but only 7.1% of tokens. - Positive statements are much more common than negative ones. ifTrue: is used 3 times more often than ifFalse:. Similarly, ifTrue:ifFalse: is 26 times more common than ifFalse:ifTrue:. - After tokenizing the code of 151,717 methods, splitting identifier names by camel case, and removing non-alphabetic characters, we received a sequence of almost 3 million words (e.g. ... ordered collection with all command line arguments...). This sequence contains only 8,211 unique words (including all misspellings such as arrray, clipped words such as arr, and nonsense words such as ddd or xdkh). Compare this to over 40,000 unique words used in roughly the same amount of printed English prose. - At least 5,480 of those 8,211 unique alphabetic sequences are valid English words. Have a nice day, and let us know what you think. We would be happy to receive your feedback. Oleks

Jan. 15, 2020

Pharo Quality Rules for Beginners

by ESTEBAN VILLALOBOS DIAZ

Hello everyone! My name is Esteban and I will be working on the Pharo Quality Rules for the next few months. The goal is to create different profiles for the rules according to the programming experience of the user. For example, for the beginner profile we would like to check for common mistakes made by people who are just starting with Pharo like: - Sending self as a message (probably because they forgot a . ) - Using False instead of false - etc.. I would appreciate it if you could share with me other common mistakes that you have seen beginners do, or maybe tell me a bit of your own experience when you started using Pharo :) Best, Esteban Villalobos

Jan. 15, 2020

Re: [Pharo-dev] Iceberg Bug? Branches with $/

by Ben Coman

On Tue, 14 Jan 2020 at 21:26, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Ben Coman wrote > > I find slashes in branch names problematic > > Okay, you've convinced me. How do we guide people toward that policy? > A warning when creating such branches? That sounds reasonable. Perhaps a discrete warning icon/button appears that opens a Help Subject that describes that slashes are supported, but warns of a few potential pitfalls. cheers -ben

Jan. 14, 2020

[Pharo 8.0] Build #1106: 5481-Metacello-logs-now-prints-lots-of-new-lines

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

There is a new Pharo build available! The status of the build #1106 was: FAILURE. The Pull Request #5484 was integrated: "5481-Metacello-logs-now-prints-lots-of-new-lines" Pull request url: https://github.com/pharo-project/pharo/pull/5484 Issue Url: https://github.com/pharo-project/pharo/issues/5481 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 14, 2020

[Pharo 9.0] Build #6: Made metalinks installable on ast nodes by selecting code when browsing methods in Calypso

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

There is a new Pharo build available! The status of the build #6 was: SUCCESS. The Pull Request #5455 was integrated: "Made metalinks installable on ast nodes by selecting code when browsing methods in Calypso" Pull request url: https://github.com/pharo-project/pharo/pull/5455 Issue Url: https://github.com/pharo-project/pharo/issues/Enhancing Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 14, 2020

Re: [Pharo-dev] Iceberg Bug? Branches with $/

by Sean P. DeNigris

Ben Coman wrote > I find slashes in branch names problematic Okay, you've convinced me. How do we guide people toward that policy? A warning when creating such branches? At minimum we should change the ghost text from Iceberg's branch creation dialog, which suggests "feature/what" as a branch template! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 14, 2020

Re: [Pharo-dev] Iceberg Bug? Branches with $/

by Pierce Ng

On Tue, Jan 14, 2020 at 12:35:27PM +0800, Ben Coman wrote: > Even from the command line I find slashes in branch names problematic, > because slashes are as a "remote/branch" separator incites confusion about > what is being referenced. > > Other have different problems... The VM's shell scripts have problem with slashes in branch names too. I use underscore in place of slash. Pierce

Jan. 14, 2020

Re: [Pharo-dev] Iceberg Bug? Branches with $/

by Ben Coman

Even from the command line I find slashes in branch names problematic, because slashes are as a "remote/branch" separator incites confusion about what is being referenced. Other have different problems... https://stackoverflow.com/questions/273695/what-are-some-examples-of-common… "slashes can cause problems. Because branches are implemented as paths, you cannot have a branch named "foo" and another branch named "foo/bar". This can be confusing for new users." "I'm going to start a campaign to never use slashes in git branch naming. The reason for this is that if on a CI for example, you want to refer to the branch name when packaging code for example, you want to refer to the name of the branch when building a URI or PATH (for example), perhaps building a URI in a bash script; you will have trouble building the URI due to the slash adding a URL part. Yes its possible to replace the slash but it is going to take me to much time to sort out." https://news.ycombinator.com/item?id=8872683 "If you use '/' is branch names you can create path conflicts. I've seen it happen and it took me a day to debug and figure out. There is some code checking for path conflicts in the git source but it's not invoked via all code paths that create branches. I recommend against using slashes in branch names unless you know what you are doing. For example: $ git branch fireos $ git branch fireos/feature-branch error: unable to create directory for .git/refs/heads/fireos/feature-branch fatal: Failed to lock ref for update: No such file or directory This happens because creating 'fireos' branch stores the sha1 in file .git/refs/heads/fireos. But if you later want to create branch 'fireos/feature-branch', git needs to store the sha1 in .git/refs/heads/fireos/feature-branch. This is impossible because 'fireos' is a file and cannot be a directory. Path conflict. It gets even uglier when you don't discover those conflicts until a pull or push. cheers -ben On Tue, 14 Jan 2020 at 07:45, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > As per common Git workflow, I named an issue branch "port/mac-pharo-7". > When > trying to load via: > Metacello new > baseline: 'VLC'; > repository: 'github://seandenigris/Pharo-LibVLC:port/mac-pharo-7'; > onConflict: [ :ex | ex allow ]; > load. > > I got: NotFound: Revspec 'port' not found.. > > Bug? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Jan. 14, 2020

GitHub Organizations 1...*Infinity

by Sean P. DeNigris

It seems we have a new Pharo GH organization every day! There is for example (pharo-project, pharo-vcs, pharo-rdbms...). The problem is that each of these creates another entry point that must be known to users, and therefore another list for us to manually maintain, and we know the struggle of keeping docs in sync quite well. My question is: why can't we consolidate into a few general buckets (like one for official and one for community) and manage the categorization with GH topics (a.k.a. tags) and teams? Here's a discussion of this idea: https://github.community/t5/How-to-use-Git-and-GitHub/Structuring-repositor… IIUC you can use teams to scope the access for each repo. With topics/tags, someone could just go to the one organization and search for vcs or rdbms to see a list of just those repos. Here's an example of a saved search like that: https://github.com/atom/?utf8=â&q=topic%3Apackage&type=&language= ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 14, 2020

Re: [Pharo-dev] [squeak-dev] Reserving/allocating some slots in the specialObjectsArray for DoubleByteArray, WordArray and DoubleWordArray

by David T. Lewis

Slots 32, 33, and 34 in the special objects array were in use as recently as Squeak 4.1, and were set to nil by the time of Squeak 4.4. I'm not sure exactly when those usages were deprecated, but given that some VM implementations are supporting images of much earlier vintage, would it be better to assign DoubleByteArray, WordArray, and DoubleWordArray to new slots appended to the end of the special objects array? I'm not sure if this has any practical impact, just asking to be safe. Dave On Mon, Jan 13, 2020 at 09:47:27AM -0800, Eliot Miranda wrote: > Hi All, > > currently the following slots in the specialObjectsArray are unused in > both Squeak and Pharo (& I suspect Cuis). > > newArray at: 32 put: nil. "was the prototype Float" > newArray at: 33 put: nil. "was the prototype 4-byte LargePositiveInteger" > newArray at: 34 put: nil. "was the prototype Point" > > The specialObjectsArray already contains ByteArray > newArray at: 27 put: ByteArray. > > I would like to have a full set of little-endian unsigned integer arrays. > In Spur Squeak these are ByteArray, DoubleByteArray, WordArray (Bitmap is > big endian), and DoubleWordArray. The VM's at:[put:] directly supports > these four at the JIT level giving us efficient unsigned access. There is > also efficient signed access for some signed arrays but these are less > useful (at least in theVM simulator). > > I want to make all four unsigned integer array classs available to plugins > etc via the interpreterProxy. So here's a formal request to reserve these > values for use as follows: > newArray at: 27 put: ByteArray. > ... > newArray at: 32 put: DoubleByteArray. > newArray at: 33 put: WordArray. > newArray at: 34 put: DoubleWordArray. > > _,,,^..^,,,_ > best, Eliot

Jan. 14, 2020