- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Weird Warnings at startup

by Sven Van Caekenberghe

> On 8 Jun 2018, at 16:52, Guillermo Polito <guillermopolito(a)gmail.com> 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 system-settings.ston in {preferences}/pharo/7.0 - Hurray for GT Inspectors ;-) Thank you. > On Fri, Jun 8, 2018 at 4:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > For a couple of days I am seeing a number of weird warnings at startup (via Growl/inform). Here is a screenshot: > > <Screen Shot 2018-06-08 at 16.45.23.png> > > It seems to go away once the image is in use. > > Sven > > > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13

June 8, 2018

Re: [Pharo-dev] Weird Warnings at startup

by Guillermo Polito

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. On Fri, Jun 8, 2018 at 4:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > For a couple of days I am seeing a number of weird warnings at startup > (via Growl/inform). Here is a screenshot: > > > It seems to go away once the image is in use. > > Sven > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

June 8, 2018

Weird Warnings at startup

by Sven Van Caekenberghe

Hi, For a couple of days I am seeing a number of weird warnings at startup (via Growl/inform). Here is a screenshot: It seems to go away once the image is in use. Sven

June 8, 2018

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

by Nicolas Cellier

2018-06-08 14:50 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > 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 > 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. > > > 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;) 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 :( Nicolas 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 >

June 8, 2018

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

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

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 Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 8, 2018

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

by Ben Coman

On 8 June 2018 at 20:49, Sean P. DeNigris <sean(a)clipperadams.com> 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 development > speed. > So its not all three at once, but different choices for different domains. And maybe Smalltalk is trumped by the next two most important... Personal familiarity (E) Team familiarity (E) where such "familiarity" encompasses text-based versus image-based systems. And we can't do much about these... Extending existing code (E) Already used in group (E) So we just promote what we can influene. > 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. And this reinforces "Personal familiarity" and perhaps a bit like Coca Cola adverts. Their aim is not to make you rush from the TV to go and get a Coke, but just the next time you are standing in the corner store deciding which you might choose, its Coke that comes to mind. 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. Agreed. cheers -ben

June 8, 2018

Re: [Pharo-dev] ApplicationSecurity Questions

by Sean DeNigris

> 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 the dropbox link no longer works). I was able to procure the library elsewhere - ERROR: DNU #selector from RBParser >>#externalFunctionDeclaration when trying to parse: apiDeleteDC: aHDC <apicall: bool 'DeleteDC' (Win32HDC) module:'gdi32.dll'> ^self externalCallFailed Pharo 5: - ConfigurationOfNacl - had to comment out #preload, which failed to download libsodium (apparently the dropbox link no longer works). I was able to procure the library elsewhere - BioFormatters-HernanMoralesDurand.118 complained about missing PMVector, clicked proceed and no more problems Since Iâm not familiar with Iliad, I wasnât sure how to run the app. I manually executed IGEVETApplication>>#startUp to get the server going, but wasnât sure what URL to type into the browser. I tried a few things that all returned 404 like: - http://localhost:9999/IC - http://localhost:9999/chromopainter-jobs - http://localhost:9999/IC/chromopainter-jobs Also from my previous reply (not sure if you saw it): > Out of curiosity, why Iliad instead of Seaside? Would Iliad be your default/recommendation for new web apps? > Is it well-supported/maintained? It doesnât seem to have much recent activity unless Iâm looking at the wrong repo. Thanks! - s

June 8, 2018

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

by John Brant

On 06/08/2018 02:02 AM, Marcus Denker wrote: > > >> On 8 Jun 2018, at 08:46, Max Leske <maxleske(a)gmail.com> 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 the past. >> > It came from RBâ¦ the idea was that there are (in the Refactoring engine) a lot of very small dictionaries with <10 elements. > The idea is that for such dictionaries, the overhead of hashing was higher than just linear search. I created its ancestor in VW some 20+ years ago (as RBSmallDictionary). It was used when doing pattern matching. When it performs a pattern match against an AST, it puts the potential value of the pattern variable in the dictionary. If the value is used later in the pattern, then we can get the previous value and make sure that we have an equivalent AST. This allows you to write patterns like: `@a = `@a to find where someone has the same expression on both sides of the #= message. Since most patterns have very few pattern variables, these dictionaries won't hold many entries. Furthermore, we are likely to abort the match when we have 0 entries. The original RBSmallDictionary had an #empty method that "emptied" the dictionary without actually removing any elements -- it just set the size to 0. In a general dictionary this would lead to memory leaks since the previous values are still held by the dictionary. However, these dictionaries were only used during the matching process and went away after the process completed. Anyway, at the time when we converted our pattern matching code from using the VW parser with our pattern matching extensions to use the new RB parser with pattern matching, the time to run Smalllint on the image was cut in half even though our parser was quite a bit slower than the VW parser. I don't remember everything that was done, but I think that most of the speedup came from having special pattern AST nodes and the small dictionary. John Brant

June 8, 2018

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

by Thierry Goubier

2018-06-08 14:29 GMT+02:00 Ben Coman <btc(a)openinworld.com>: ... > > > 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 you look at it in a greater scheme of things (once you get past their complexity of incomplete programs layer). However, some of the stuff seems hard to solve (all of it is about finding what could fill the holes of an incomplete program, according to your definition of what an incomplete program is... their's is not Smalltalk's) Once you have a theory about finding what could be in those holes, then some of it can be solved elegantly. And, in some theories, you have excellent results (i.e. formally sound, and fast in practice) on determining what could be in the holes. Thanks for the link, Thierry

June 8, 2018

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

by Thierry Goubier

2018-06-08 14:54 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > 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: https://github.com/ThierryGoubier/AltBrowser/tree/pharo6/Alt-TypeCheck.pack… It decodes things like anArrayOf, anIntOrString and similar names, and writes a metalink-based type check. Thierry > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

June 8, 2018