November 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Merge tests and mocks of Monticello

by Guillermo Polito

I remember that Monticello tests make dirty and load/unload the mocks package. Thatâs why itâs separated. > On 24 nov 2015, at 11:11 p.m., Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com> wrote: > > see that a Test need a method in an extension, that must be for > that reason that there is two packages.

Nov. 25, 2015

Redraw Ghosts/Artifacts

by Sven Van Caekenberghe

I get lots of redraw ghosts/artifacts in the latest 5.0 (retina macbook pro), does anyone else see this too ? And something is wrong with the task bar preview too, that cannot be fixed by redrawing the world.

Nov. 25, 2015

Re: [Pharo-dev] Seaside REST on Pharo 50

by Johan Brichau

Hi, Seaside-REST is included in Seaside since version 3.1 ConfigurationOfSeasideREST is outdated; it works with version 3.0 Therefore, load the âRESTâ group from ConfigurationOfSeaside3: Metacello new configuration: 'Seaside3'; version: #stable; load: âREST' If you want to experiment with all of Seaside, load everything: Metacello new configuration: 'Seaside3'; version: #stable; load: âOneClick' Seaside is also not tested on Pharo5 as itâs still a moving target. Use Pharo4 if you want to make sure it works. regards Johan > On 25 Nov 2015, at 01:07, Franck Warlouzet <franck.warlouzet(a)hotmail.fr> wrote: > > I was using both ConfigurationOfSeaside3 and ConfigurationOfSeasideRest. Is it the wrong way ? > > Franck > > > To: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > > From: stephan(a)stack.nl <mailto:stephan@stack.nl> > > Date: Wed, 25 Nov 2015 00:26:05 +0100 > > Subject: Re: [Pharo-dev] Seaside REST on Pharo 50 > > > > On 24/11/15 16:43, Franck Warlouzet wrote: > > > We are working on Pharo 50, and we noticed that Seaside-REST is not > > > working anymore. > > > > How are you loading it? > > > > (ConfigurationOfSeaside3 project version: #'release3.2') load: > > #('OneClick' 'REST') > > > > There could be a configuration problem, or not the right combination of > > groups. > > > > To resolve it, compare the package cache from Pharo4 vs Pharo5 after > > loading. > > > > Stephan > > > >

Nov. 25, 2015

Re: [Pharo-dev] Install Pharo launcher on MAC

by Damien Cassou

Trussardi Dario Romano <dario.trussardi(a)tiscali.it> writes: > i have a macbook with Mac OS X 10.7.5 and some Pharo x.y applications. > > Now i begin a new development work and i think to started with the Pharo launcher to manage the last and the future pharo image. > Into https://ci.inria.fr/pharo/view/Launcher/job/Launcher-Mac/ i found this link: latest.dmg > It's the right dmg image to install ? yes > I need to do something for the old pharo applications? I don't think so > After installed the new pharo launcher, the old Pharo application is > load and works without problem? ( how they work now: open with > specific VM ) I don't understand the question. After you install the pharo launcher, you should be able to launch Pharo from the Applications menu. This will open the launcher. > In the Mac App Store i found this : > > https://itunes.apple.com/it/app/pharo-launcher/id503025789?mt=12 > It has the same name: 'pharo-launcher' but it's > another think or i wrong? this is completely different stuff > It can interact with the above? no idea -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Nov. 25, 2015

Re: [Pharo-dev] problem using curl and wget in zero-conf

by Ben Coman

On Wed, Nov 25, 2015 at 1:56 AM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > Actually, I think that you should add the --show-error (with --silent) for > curl and --no-verbose for wget, so that you get a more useful error message > than "BOOM" ... you also should get a script exit from the curl/wget command > as well which is exactly what _should_ happen... "BOOM" was just indicative. I should have said "$BOOM" ? ;) cheers -ben > On 11/24/2015 02:39 AM, Ben Coman wrote: >> >> On Tue, Nov 24, 2015 at 7:25 AM, Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com> wrote: >>> >>> I've been using zero-conf scripts to download the pharo vm for a while >>> and >>> occasionally the download fails to install the vm in the pharo-vm >>> directory >>> .... silently ..... with no clue as to what happened. even worse the exit >>> status is zero so the failure isn't noticed until much later on in my >>> install when an attempt is made to actually use the vm >> >> So to fail early after the download we should... >> if [ ! -f "$VM_DIR/vm.zip" ] ; then >> echo "BOOM!" >> exit 1; >> fi >> >> (?) cheers -ben >> >> >>> .... I do know that when I see these failures the pharo-vm [directory] >>> does get created but is empty ... >>> >>> I got another failure today and figured that I would dig into this on my >>> end >>> to see if I could understand what might be going on .... >>> >>> The section of the zero-conf script that is suspect is the following: >>> >>> mkdir $VM_DIR >>> $DOWNLOAD_TO$VM_DIR/vm.zip $VM_URL >>> >>> >>> After the $VM_DIR is created (which I know happens), the $DOWNLOAD_TO >>> script >>> is run. Recently, I learned that a side effect of using the --silent >>> option >>> for curl is that error messages are also suppressed and I see that for >>> curl, >>> the `--silent` option is being used: >>> >>> if [[ `which curl 2> /dev/null` ]]; then >>> DOWNLOAD="curl --silent --location --compressed "; >>> DOWNLOAD_TO="$DOWNLOAD --output "; >>> elif [[ `which wget 2> /dev/null` ]]; then >>> DOWNLOAD_TO="wget --quiet --output-document="; >>> DOWNLOAD="$DOWNLOAD_TO-"; >>> else >>> echo "Please install curl or wget on your machine"; >>> exit 1 >>> fi >>> >>> >>> For curl if you want to turn off the progress meter (a good thing) and >>> continue to report errors, you need to use --show-error in conjunction >>> with >>> --silent (as described in the man page) >>> >>> I think the same thing applies to wget, --quiet turns off error messages >>> and >>> progress .... you probably should be using --no-verbose to continue to >>> get >>> error messages ... >>> >>> Dale >>> >>> > >

Nov. 25, 2015

Re: [Pharo-dev] Rules

by Ben Coman

Thanks Uko. I'll keep that in mind. cheers On Wed, Nov 25, 2015 at 1:37 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > On 24 Nov 2015, at 17:29, Ben Coman <btc(a)openinworld.com> wrote: > > On Tue, Nov 24, 2015 at 11:45 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > wrote: > > > On 24 Nov 2015, at 14:10, Ben Coman <btc(a)openinworld.com> wrote: > > On Tue, Nov 24, 2015 at 4:32 PM, Nicolas Anquetil > <nicolas.anquetil(a)inria.fr> wrote: > On 23/11/2015 22:14, stepharo wrote: > Le 22/11/15 22:11, Yuriy Tymchuk a Ã©crit : > > > Hi. > > The rule is correct. Sending a different message to super may be > confusing. In this case you are in âprintOn:â method and you are sending > âprintOn:nextPutAll:â to super. The idea is that you have to send > âprintOn:nextPutAll:â to self and then either it will invoke the super one, > you there will be an overridden method in your current class. > > exactly but do you expect a newbie to understand anything with the current > explanation? > I do not. > > Rewrite super messages to self messages when both refer to same method" > > > What about : > > > Sorry :) both of these make my head hurt. I think Stef's was clearer. > The useful part there is that it reports the actual identifier causing > the problem, which makes it more obvious this is not what was meant, > from which even a newbie may infer the missing period. > > "'super' should call the same selector. Send different selector to 'self' > then use 'super' in this one." > ? > > > btw, is this just commonly how super is used, or is it really bad to > call a different super method? > I'm sure I've done that on occasion. > > > It makes harder to extend your code. Because if method `a` calls method `b`, > then even if method `b` is not defined in your class, I can subclass and > redefine method b. Otherwise I have to subclass and redefine `a` although > `a` is fine, but I want to run my `b` and not the one of superclass. > > > Uko > > > > Thanks Uko. I was considering a case where my new subclass has > redefined 'b', but I want my 'a' to avoid my 'b' and use the > superclass one. > > (Sorry I can't remember the use case) > cheers -ben > > > Hi, > > no rule is perfect, and there are definitely cases that work the other way > around. But we try to focus on the best practices. > > Also I think this influences the maintainability of code. Because in the > suggested by the rule, you have method `a` with one responsibility and it > uses method `b` with another responsibility. Now when you call method `b` > from the super class, all logic becomes more complicated. > > Uko > > > > cheers -ben > > > or: > > "should not send a different message to super (send different message to > self and then call super from it)" > ? > > > > nicolas > > > Sucks > > > Secondly, there is an issue with âsends unkown selectorâ. Iâve also > noticed it recently. I think that it happens because the rule has a special > cace, and I messed up something with refresh. This is the next thing on my > TODO list. > > Cheers. > Uko > > > On 22 Nov 2015, at 16:33, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 22 Nov 2015, at 12:20, stepharo <stepharo(a)free.fr> wrote: > > With the following (broken) definition > > > : aStream > super printOn: aStream > aStream nextPutAll: '(', faces printString , ')' > > I got this strange rule: > > Rewrite super messages to self messages when both refer to same > method > > I do not get it and it looks really suspicious to me. > Any suggestions? > > > The rule is meant to catch the case when when âsuperâ can be âselfâ as > there is no #printOn: > defined in the class. > > But here it looks like it is wrong: it would be an infinite loop. > > I think it could be related to this other bug: I have seen that the > rules are not correctly updated > when you add methods. (I wanted to add an issue for that but did not > yet). E.g. I often get > a âsends unkown selectorâ for self sends and then I check â> method is > there, I just added it! > > So here this means that you added a new printOn:, the rules do not > update, and it thinks > that there is no printOn:. > > So the real bug is that added methods need to be taken into account by > QA. > > Marcus > > > > > > > > -- > Nicolas Anquetil > RMod team -- Inria Lille > >

Nov. 25, 2015

Re: [Pharo-dev] Seaside REST on Pharo 50

by Franck Warlouzet

I was using both ConfigurationOfSeaside3 and ConfigurationOfSeasideRest. Is it the wrong way ? Franck > To: pharo-dev(a)lists.pharo.org > From: stephan(a)stack.nl > Date: Wed, 25 Nov 2015 00:26:05 +0100 > Subject: Re: [Pharo-dev] Seaside REST on Pharo 50 > > On 24/11/15 16:43, Franck Warlouzet wrote: > > We are working on Pharo 50, and we noticed that Seaside-REST is not > > working anymore. > > How are you loading it? > > (ConfigurationOfSeaside3 project version: #'release3.2') load: > #('OneClick' 'REST') > > There could be a configuration problem, or not the right combination of > groups. > > To resolve it, compare the package cache from Pharo4 vs Pharo5 after > loading. > > Stephan > >

Nov. 25, 2015

Re: [Pharo-dev] learning from errors....

by Henrik Nergaard

You could use one of those images and rotate it when drawing, changing the angle by #step. I attached an example. Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Yuriy Tymchuk Sent: Tuesday, November 24, 2015 7:58 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] learning from errors.... Good catch. At the time when I was developing it, the loading morph implementation was such a magic for me, that I was super happy after finishing it and forgot that I depend on Komitter. Is there any alternative for that? Otherwise I will simply remove the spinning cog, I donât feel that this is super important. Uko On 24 Nov 2015, at 19:51, stepharo <stepharo(a)free.fr<mailto:stepharo@free.fr>> wrote: BTW: it would be good that QA does not refer to Komitter. And package it as a separate project. QA should not dependent on Komitter because we can remove Komitter. And it makes no sense!

Nov. 24, 2015

Re: [Pharo-dev] Seaside REST on Pharo 50

by Stephan Eggermont

On 24/11/15 16:43, Franck Warlouzet wrote: > We are working on Pharo 50, and we noticed that Seaside-REST is not > working anymore. How are you loading it? (ConfigurationOfSeaside3 project version: #'release3.2') load: #('OneClick' 'REST') There could be a configuration problem, or not the right combination of groups. To resolve it, compare the package cache from Pharo4 vs Pharo5 after loading. Stephan

Nov. 24, 2015

Re: [Pharo-dev] Merge tests and mocks of Monticello

by Ferlicot D. Cyril

Le 23/11/2015 21:58, stepharo a Ã©crit : > I do not know if the logic was not done exactly to separate them but we > can try to merge them. > > Oh, I see that a Test need a method in an extension, that must be for that reason that there is two packages. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Nov. 24, 2015