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

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

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

Le 08/06/2018 à 19:43, Nicolas Cellier a écrit : ... Yes, I don't know these languages enough, but it's indeed an extensible specification of types (as expectations). And this have values both for tools (compiling/browsing/static checks) and humans. Oh, and if it helps browser, then it

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

2018-06-08 17:05 GMT+02:00 Thierry Goubier : > 2018-06-08 16:35 GMT+02:00 Nicolas Cellier gmail.com>: > > > > > > 2018-06-08 14:50 GMT+02:00 Thierry Goubier : > >> > >> Hi Ben, > >> > >> Interesting find. > >> > >> ... snip ... > >> > >> > Table 7 makes and interesting assertion that static

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

2018-06-08 17:06 GMT+02:00 Thomas Dupriez < thomas.dupr...@ens-paris-saclay.fr>: > 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 : > >> >> Note that

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

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 >: Note that this is used in Smalltalk, when you write anInteger,

[Pharo-dev] [Pharo 7.0-dev] Build #1027: 21225-Unknown-message-nonBlockTempsIn-sent-in-RBBasicLintRuleTestclasstempsReadBeforeWritten

There is a new Pharo build available! The status of the build #1027 was: SUCCESS. The Pull Request #1506 was integrated: "21225-Unknown-message-nonBlockTempsIn-sent-in-RBBasicLintRuleTestclasstempsReadBeforeWritten" Pull request url: https://github.com/pharo-project/pharo/pull/1506

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

2018-06-08 16:35 GMT+02:00 Nicolas Cellier : > > > 2018-06-08 14:50 GMT+02:00 Thierry Goubier : >> >> Hi Ben, >> >> Interesting find. >> >> ... snip ... >> >> > Table 7 makes and interesting assertion that static types are more >> > important >> > for readability than preventing bugs. >> >> This

Re: [Pharo-dev] Weird Warnings at startup

> On 8 Jun 2018, at 16:52, Guillermo Polito wrote: > > I think you have stored some settings that are not valid anymore for the new > version. And it looks related to Compiler and Quality Assistant options. Ha, I never consciously put them there, I never save preferences. I deleted

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

2018-06-08 14:50 GMT+02:00 Thierry Goubier : > Hi Ben, > > Interesting find. > > ... snip ... > > > 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 >

[Pharo-dev] [Pharo 7.0-dev] Build #1026: 22039-Introduce-displayScaleFactor

There is a new Pharo build available! The status of the build #1026 was: SUCCESS. The Pull Request #1461 was integrated: "22039-Introduce-displayScaleFactor" Pull request url: https://github.com/pharo-project/pharo/pull/1461 Issue Url: https://pharo.fogbugz.com/f/cases/scaleFactor Build

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

On 8 June 2018 at 20:49, Sean P. DeNigris wrote: > 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

Re: [Pharo-dev] ApplicationSecurity Questions

> You can check a project making use of ApplicationSecurity here: > http://www.smalltalkhub.com/#!/~hernan/IGEVET Pharo 6.1: - No #development version for Iliad, had to add to ConfigurationOfIliad - ConfigurationOfNacl - had to comment out #preload, which failed to download libsodium (apparently

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

On 06/08/2018 02:02 AM, Marcus Denker wrote: > > >> On 8 Jun 2018, at 08:46, Max Leske wrote: >> 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

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

2018-06-08 14:29 GMT+02:00 Ben Coman : ... > > > 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. Interesting, and not that complex when

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

2018-06-08 14:54 GMT+02:00 Sean P. DeNigris : > Thierry Goubier wrote >> 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 :) > > Cool! Is that public? Yes. It's at:

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

Thierry Goubier wrote > 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 :) Cool! Is that public? - Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

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

Hi Ben, Interesting find. 2018-06-08 14:29 GMT+02:00 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) > >

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

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

[Pharo-dev] Empirical Analysis of Programming Language Adoption

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

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

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:

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

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,

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

> On 8 Jun 2018, at 12:42, Denis Kudriashov 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,

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

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

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

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:

[Pharo-dev] [Issue Tracker] Please check issue tracker

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

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

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

Re: [Pharo-dev] [ANN] Epicea, Ombu and Hiedra packages have new "official" repository

Hi, Can we define what we mean by "Light"? Are we talking about - memory consumption? - Dependencies? - Amount of code? - Complexity? - Size of API? Guille On Fri, Jun 8, 2018 at 2:31 AM, Hernán Morales wrote: > Hi Norbert, > > El 7 jun. 2018, a las 03:23, Norbert Hartl escribió: > > > > Am

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

Well, I can answer my own question: SmallDictionary is a lot more space efficient. I think the class comment should clarify the use case for SmallDictionary and mention the performance trade off. Max On 8 Jun 2018, at 8:46, Max Leske wrote: Hi, I was messing around with SmallDictionary