- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Need a decision on subString: vs substring:

by Chris Cunningham

On Fri, Sep 4, 2015 at 6:18 AM, Christophe Demarey < Christophe.Demarey(a)inria.fr> wrote: <snip> > > I agree with that. > To be compatible with these goals, I think my proposition just needs to be > updated a bit. > I'm still in favor of rules to transform ANSI code to Pharo code. The > point is that we should not force the user to update their code base. The > rule-cased approach is compatible with that if you transform ANSI code when > it gets loaded in the image. True to a point. That point being folks who want to write code that could play in other ANSI Smalltalks - with your approach, you have locked those people out, since they CAN'T write ansi code - only Pharo code. any non-Pharo ANSI'ism would be auto-changed back to Pharo - and they'd leave to write and live in a different Smalltalk. Now, if you had the ANSI compatibility layer that either allowed conversion to Pharo OR ignored conversion to Pharo, that wouldn't be a barrier. On a different topic, what would be required to amend the ANSI standard? Maybe a Smalltalk Agreement 2016 that took the standard and amended some parts (like fixing the spelling) so that going forward, all Smalltalks could be standard with good English spellings? Just curious, cbc

Sept. 4, 2015

Re: [Pharo-dev] Need a decision on subString: vs substring:

by Jan Vrany

... > > The corollary being, if you make it simple for people to continue > > maintaining the old dialect, you are more likely to get code ported > > to > > your dialect. > > I agree with that. > To be compatible with these goals, I think my proposition just needs > to be updated a bit. > I'm still in favor of rules to transform ANSI code to Pharo code. The > point is that we should not force the user to update their code base. > The rule-cased approach is compatible with that if you transform ANSI > > code when it gets loaded in the image. No, it's not! Rewriting the code in this case is actually a very bad thing. The problem is that when you port changes done in, say, Pharo back to, say, "The other cool Smalltalk" you have rewrite everything back (or things will break). This is not what you want to spend you time on. So either don't enforce code rewriting in this case or be honest and say openly "I do not care, not my problem" :-) And no, I'm not theorizing, I'm talking out of my every-two-weeks-or=-so-pain I'm suffering last year or so. Best, Jan

Sept. 4, 2015

remove MczInstaller?

by Martin Dias

Hi, Does somebody use MczInstaller to load Monticello files? The only users in the image are it's tests. The class comment states: " An installer for Monticello files with the *.mcz extension. MczInstaller installFileNamed: 'MyKillerApp-Core-Author.1.mcz' " MartÃn

Sept. 4, 2015

Re: [Pharo-dev] Need a decision on subString: vs substring:

by Christophe Demarey

Le 4 sept. 2015 Ã 12:20, Ben Coman a Ã©crit : > On Fri, Sep 4, 2015 at 3:39 PM, Christophe Demarey > <Christophe.Demarey(a)inria.fr> wrote: >> I don't like so much compatibility packages because people will not update >> their code and expect the compatibility package to always work. >> Why not just use what Marcus did for deprecations? Create a rule to >> transform ANSI Smalltalk to Pharo "magically'? > > People updating their code when porting is better than using a > compatibility package. But having code ported is better than > not-having code ported, if its perceived we are making it harder than > necessary. If someone wants to continue maintaining their software in > the original Smalltalk dialect, *forcing* their code from #subStrings > to #substrings is one more difference you've *imposed* on them to > maintain in their own compatibility layer. Its the sort of annoyance > that can taint people's emotional buy-in to a new system. This again > reminds me of a story about when Excel took over from Lotus (which > I've posted before) which I think applies to code being ported from > one system to another... > > "Excel's tipping point [...] happened around the time of Excel 4.0. > And the biggest reason was that Excel 4.0 was the first version of > Excel that could *write* Lotus spreadsheets transparently. Yep, you > heard me. *Write*. Not read. It turns out that what was stopping > people from switching to Excel was that everybody else they worked > with was still using Lotus 123. [...] To take over a market, you have > to address every barrier to entry. If you forget just one barrier > which trips up 50% of your potential customers, then by definition, > you can't have more than 50% market share, and you will never displace > the dominant player, and you'll be stuck on the sad (omelet) side of > chicken and egg problems." [1] > > [1] http://www.joelonsoftware.com/articles/fog0000000052.html > > The corollary being, if you make it simple for people to continue > maintaining the old dialect, you are more likely to get code ported to > your dialect. I agree with that. To be compatible with these goals, I think my proposition just needs to be updated a bit. I'm still in favor of rules to transform ANSI code to Pharo code. The point is that we should not force the user to update their code base. The rule-cased approach is compatible with that if you transform ANSI code when it gets loaded in the image.

Sept. 4, 2015

Image and bootstrap dependencies

by Christophe Demarey

Hi, I created a job to automatically generate a report of the Pharo image dependencies as well as current bootstrap dependencies. You can find them here: https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM… https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM… There are a lot (too many) dependencies but you can focus on some of them with the search field. Dependencies inside orange boxes are dependencies that are there but that we ignore (for example, an example method adds an extra-dependency). It should be fixed later but is not a problem for now. Ignored dependencies are declared in the package manifest in #ignoredDependencies. Dependencies inside red boxes are dependencies we want to remove for the bootstrap. For now, they are listed in the bootstrap dependency report. People that are willing to help to have a more modular Pharo could first take a look at the bootstrap dependency report and check dependencies that we should cut. Once we know, we can open issues on fogbugz in the 'bootstrap category' and update manifests accordingly. To investigate more deeply dependencies, you can use the DependencyAnalyzer (in the Pharo Catalog) to actually check dependencies (inheritance, reference, extension, traits, message send). Regards, Christophe.

Sept. 4, 2015

Re: [Pharo-dev] Announcements in Nautilus

by Yuriy Tymchuk

Iâve seen that there is a method #package:class:category:method: which is called sometimes with nil values and the method sends 4 messages, and in each message if the arg is not nil it announces the selection. What Iâve done was to break in into 4 methods: #package:, #package:class: and so on. Then Iâve changes all the messages that contained hardcoded nil, to use only the method they need. And each method fires only one announcement. This is not perfect, but at least we donât have to send model package: aPackage class: aClass category: nil method: nil if we only want to select a class. Maybe in the future this can be reduced to a simple "class: aClassâ, because Iâve seen that many of parameters some from âself selectedPackageâ, âself selectedClassâ and so on. Uko > On 04 Sep 2015, at 14:02, Franck Warlouzet <franck.warlouzet(a)hotmail.fr> wrote: > > I will take a look at it, thanks to continue this effort. > I agree with Nicolai, there is too many announcements raised but the way to manage selection complicates a deep change. But I trust us, step by step we can simplify all of this. > > Franck > > From: yuriy.tymchuk(a)me.com > Date: Fri, 4 Sep 2015 12:08:55 +0200 > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] Announcements in Nautilus > > Iâve made a prototype, and it seems to work well, though Iâd really like if Franck or Esteban can take a look. https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen… <https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen…> > > Cheers. > Uko > > > On 04 Sep 2015, at 10:25, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > > I will not reply publicly on the true reason of that situation :) > Now what we should do is to continue to simplify the code of Nautilus (we made great steps with Franck). > And yuriy if you have some fixes please let us know. > > Stef > > Le 4/9/15 09:22, Yuriy Tymchuk a Ã©crit : > Hi, > > I find announcements in Nautilus a bit strange. I guess you are familiar with QualityAssistant. To display the critics about the currently selected entity I need to know which one is selected. There is NautilusMethodSelected and NautilusClassSelected announcements. But here is a small detail, if you select a method, both of them are fired i.e. for the methodâs class and the method itself. For me it does not make any sense because I need to show critics only for currently selected source code. > > Moreover if I need to show something about the class while a method is selected, I can just ask the method for its class, right? > > Does anybody need this double announcing? (Maybe it is quadruple, I havenât checked for a package and protocol) > > Cheers! > Uko

Sept. 4, 2015

Re: [Pharo-dev] [Reflectivity] Slides ESUG talk

by Marcus Denker

Hi Roberto, Very good! I am now working on #after for methods+sequence. *And* primitives... this should all be committed early next week. After that, I need to actually use it to find remaining problems, so this is very good that you will start now. Marcus On Thu, Sep 3, 2015 at 2:50 PM, roberto.minelli(a)usi.ch < roberto.minelli(a)usi.ch> wrote: > Very good talk Marcus. > > In the next weeks I will finally have some time to try Reflectivity out! > > Thanks a lot for all your effort! > > Cheers, > Roberto > > > On 31 Jul 2015, at 13:23, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > > >> On 15 Jul 2015, at 10:15, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> > >> Hi, > >> > >> the slides for my ESUG talk are online: > >> > >> http://www.slideshare.net/MarcusDenker/reflection-in-pharo5 > >> > >> > > > > Video is online, too: > > > > https://www.youtube.com/watch?v=Ik539CtjtTI > > > > > > > > Marcus > > > > -- -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Sept. 4, 2015

Re: [Pharo-dev] Announcements in Nautilus

by Franck Warlouzet

I will take a look at it, thanks to continue this effort. I agree with Nicolai, there is too many announcements raised but the way to manage selection complicates a deep change. But I trust us, step by step we can simplify all of this. Franck From: yuriy.tymchuk(a)me.com Date: Fri, 4 Sep 2015 12:08:55 +0200 To: pharo-dev(a)lists.pharo.org Subject: Re: [Pharo-dev] Announcements in Nautilus Iâve made a prototype, and it seems to work well, though Iâd really like if Franck or Esteban can take a look. https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen… Cheers.Uko On 04 Sep 2015, at 10:25, stepharo <stepharo(a)free.fr> wrote:I will not reply publicly on the true reason of that situation :) Now what we should do is to continue to simplify the code of Nautilus (we made great steps with Franck). And yuriy if you have some fixes please let us know. Stef Le 4/9/15 09:22, Yuriy Tymchuk a Ã©crit : Hi, I find announcements in Nautilus a bit strange. I guess you are familiar with QualityAssistant. To display the critics about the currently selected entity I need to know which one is selected. There is NautilusMethodSelected and NautilusClassSelected announcements. But here is a small detail, if you select a method, both of them are fired i.e. for the methodâs class and the method itself. For me it does not make any sense because I need to show critics only for currently selected source code. Moreover if I need to show something about the class while a method is selected, I can just ask the method for its class, right? Does anybody need this double announcing? (Maybe it is quadruple, I havenât checked for a package and protocol) Cheers! Uko

Sept. 4, 2015

Re: [Pharo-dev] Compiling a method with a new iv raises DNU

by Marcus Denker

I checked with stef a bit what it could beâ¦ - first theory: copy-paste of some strange character leads to error in the scanner. But we could not reproduce it, so that was not it - second: with quality check running we stress far more the reading of code right after accepting a method. So it could uncover strange bugs in the .changes mechanism (which is very convoluted and old code). I guess it is the second and we should monitor if this happens more often to find way to reproduce it. Marcus > On 04 Sep 2015, at 11:00, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi Stef. > > Can you tell me in which class do you add this? Because it does not happen for every class. There was an issue that one on the rules destroying ASTs, but we solved it about a month ago. > > Uko > >> On 04 Sep 2015, at 10:45, stepharo <stepharo(a)free.fr> wrote: >> >> Apparently there is something wrong in the ASTCache. >> The only solution I found to continue to work was to remove the QAPlugin. >> >> >> Le 4/9/15 10:21, stepharo a Ã©crit : >>> Here is the scenario >>> >>> I added the method >>> >>> comment >>> >>> ^ comment >>> >>> and I get now a DNU >>> >>> doSemanticAnalysisIn: >>> >>> >>> at: aCompiledMethod >>> ^ self >>> at: aCompiledMethod >>> ifAbsentPut: [ >>> aCompiledMethod parseTree doSemanticAnalysisIn: aCompiledMethod methodClass ] >>> >>> >>> where aCompiledMethod is StoreBlessing>>#comment >>> >>> but the parseTree is nil :( >>> >>> How this behavior can happen? >>> >>> Stef >>> >>> >> >> > >

Sept. 4, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50303 Home: https://github.com/pharo-project/pharo-core

Sept. 4, 2015