- Pharo-dev - lists.pharo.org

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

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

by stepharo

Reading the code once again. I do not think that we need a state pattern. What is needed is just a list of (form time) and iterate over them. May be I'm wrong but it looks like we do not need three classes for that. Le 24/11/15 19:51, stepharo a Ã©crit : > I was looking at the LoadingMorph > 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! > > And it uses a state pattern, which is ok but there is not needed to > create a new state all time. > > SmallCogInitialState >> nextState > > ^ SmallCogState2 new > > nextState > > ^ SmallCogState3 new > > We can have a state pattern without creating garbage all the time. > > Now I wonder who is using this LoadingMorph? > Stef > >

Nov. 24, 2015

Re: [Pharo-dev] what is exactly flushCache?

by stepharo

Le 24/11/15 21:14, Marcus Denker a Ã©crit : >> On 24 Nov 2015, at 17:00, stepharo <stepharo(a)free.fr> wrote: >> >> Thanks for this great explanation and yes I know about this cache but I do not why >> I was wondering that we did not need to update it from the image. >> Now I would like to add such comment inside the system because I like self explanation. >> >> "See Object documentation whatIsAPrimitive." gets frustrates me. >> > This sentence used to be just in all primitives. it points to a long explanation to what is a primitive (in general) > in method #whatIsAPrimitive. > > It does not want to explain this one primitive. There should be a sentence in addition. Ok but this See Object documentation whatIsAPrimitive sucks too. It should say Browse implementors of whatIsAPrimitive Why the reader should always guess. We are not superhero and I think that Pharo and Pharoers should try to remember when they discovered the system. Then I would add these two poor methods into the class comment because I do not see why on Object we get only these two methods. It looks aged to me. Stef > > Marcus > > >

Nov. 24, 2015

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

by stepharo

I saw when browsing Morph :) Stef Le 24/11/15 19:58, Yuriy Tymchuk a Ã©crit : > 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