October 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] using mocketry to mock subcall

by Denis Kudriashov

Hi Herby. 2017-10-20 18:49 GMT+02:00 Herby VojÄÃk <herby(a)mailbox.sk>: > > > I had this problem. I tried something like (though not exactly w/ this > code): > > Foo stub new will: [ :aMessage | > | original | > original := MockExpectedOriginalCall new executeFor: aMessage. > original stub. > ^ original ] > > but IIRC it failed on doing #stub inside will: block. > So the arguments of block in message #will: are expected to be arguments of stubbing message (not a full message instance). We can introduce new kind of expected action to automatically stub any result of message send: Foo stub new willStubRealResult. With help of new subclass of MockExpectedOriginalMethodCall: MockExpectedMethodResultStub>>executeFor: anOccurredMessage realMethodResult := super executeFor: anOccurredMessage. realMethodResult stub. ^realMethodResult. MockExpectedMessage>>willStubRealResult self will: MockExpectedMethodResultStub new And then you will be able specify expectations for all Foo instances: (Instance of: Foo) stub someMessage willReturn: #const And you will be able assert any message which was sent to Foo instances: (Instance of: Foo) should receive someRequiredMessage which should equal: #expectedValue I committed this code to the dev branch. But I am wondering that such kind of behaviour is really needed. Probably it is useful as you ask about it. > >> So now you can just use simple mock which will be returned as simple >> stub from concrete constructor of your class: >> >> some := Mock new. >> >> some stub askForName: 'new'. >> >> Something stub new willReturn: some. >> >> >> I think it looks not not bad and no crazy magic is evolved. And of >> course you can replace mock with real instance if you want: >> >> some := Something new. >> >> some stub askForName: 'new'. >> >> Something stub new willReturn: some. >> >> >> >> 2017-10-20 14:21 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com >> <mailto:dionisiydk@gmail.com>>: >> >> Yes, but in that case you stub messages to the class itself. For >> your example it means: >> >> Something stub askForName willReturn: 'new'. >> >> Something askForName should be: 'new' >> >> >> >> 2017-10-20 13:58 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com >> <mailto:i.uhnak@gmail.com>>: >> >> Thanks Denis, that did the trick. >> >> But I thought that I can also mock at the class level (at least >> it was shown in the docs). >> >> Peter >> >> On Sat, Oct 7, 2017 at 11:24 AM, Denis Kudriashov >> <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> Hi Peter. >> >> You should stub instance instead of class: >> s := Something new. >> s stub askFor... >> >> 7 Ð¾ÐºÑ. 2017 Ð³. 9:18 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Peter UhnÃ¡k" >> <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: >> >> >> Hi, >> >> maybe I am missing something fundamental, because this >> seems like an obvious scenario >> >> I have a class Something with two methods >> >> Something>>askForName >> ^ UIManager default request: 'Name' >> >> Something>>name >> ^ self askForName , ' suffix' >> >> Now I want to mock out askForName, so I can run it >> automatically in tests... >> >> I've tried just stubbing it... >> >> SomethingTest>>testRenameStub >> Something stub askForName willReturn: 'new'. >> Something new name should be: 'new suffix' >> >> however it still opens the window to ask for the name, >> so the original method is being called. >> >> Right now I have to stub it with metalinks, which >> doesn't play well with some tools (hapao) >> >> SomethingTest>>testRenameMeta >> | link newName | >> link := MetaLink new >> metaObject: [ 'new' ]; >> control: #instead. >> (Something >> #askForName) ast link: link. >> [ newName := Something new name ] >> ensure: [ link uninstall ]. >> self assert: newName equals: 'new suffix' >> >> Thanks, >> Peter >> >> >> >> >> > >

Oct. 23, 2017

[ANN] SeasideTesting recovered from oblivion

by Esteban Lorenzano

Hi, I spend some days last week woking with the guys of AFI (http://afi-sa.fr <http://afi-sa.fr/>, yes they also use Pharo in some of their projects) and together we recovered SeasideTesting from Davis Shaffer to be used for their TDD experience. you can check it out here: https://github.com/Afibre/SeasideTesting <https://github.com/Afibre/SeasideTesting> Whatâs SeasideTesting? A package to test Seaside components. Why we do not use Parasol? Because it is based on selenium and that makes the process slow. Where can I know more? - there is some documentation here (for VW, I think): http://www.shaffer-consulting.com/david/Seaside/TestingComponents/TestingCo… <http://www.shaffer-consulting.com/david/Seaside/TestingComponents/TestingCo…> - some slides here (on squeak): http://esug.org/data/ESUG2005/Wednesday/2005-ESUG-Shaffer.pdf <http://esug.org/data/ESUG2005/Wednesday/2005-ESUG-Shaffer.pdf> but all that is old. Best way is to just install and see the tests, as always, cheers! Esteban

Oct. 23, 2017

Re: [Pharo-users] perspective request for those earning a living from Smalltalk

by jtuchel＠objektfabrik.de

Petr, I've been working as a Consultant for many big corporations (mainly in VA Smalltalk) since 1996. The situation you describe is very well known to me. But in my opinion there is no technical reason for this. It's a managerial problem. Ever since IBM went out to their customers and told them to move to Java for the better ini the mid-90ies, managers wanted the Smalltalk projects to go away as fast as possible. Nobody asked why IBM was still happily using VisualAge Smalltalk internally at that time frame.... So the Smalltalk projects were declared legacy by Management. Replacement projects were started with big efforts and optimism. Some went well, some somewhat came to fly in a bit more than double the time and much more times the costthan planned, some failed miserably. One thing was in common to the replacement projects all over the place: they took much longer, turned out to be much mor complicated and took a lot more manpower than anybody had ever imagined. So two important things happened: 1) People were told the old Smalltalk stuff would be gone soon, so if you wanted to be a valued and appreciated staff member, you better stay away from these projects 2) The people who knew the business and technical side of the existing projects were moved to the new projects. Some liked it (because of 1) some were frustrated (because they knew / feared the new project was going to be a death march) Over the first 2 years or so, nobody realized how bad the situation really was. It was easy to postpone user requirements to the new project, accumulate more and more manpower in the new project and still keep up green flags everywhere. ...until yellow was the new green and users/stakeholders wanted the new features NOW - and not one day when the replacement project would become real. So the remaining manpower in the old project (not the ones with lots of experience and knowledge) had to extend the old system, integrate it with the new system (thereby implementing all the stuff that IBM once told their management would never be possible in Smalltalk) and keep it up and ranning year after year. Nobody ever said Thank You or would appreciate the work they did. Because that was old stuff anyways and was already irrelevant. Some of these old systems still exist today, serving users every single day, while some of the new systems never appeared. No manpower was ever added to these projects, and never would anybody ever say: okay, guys, you won. They still work on legacy code and try to do their best to fulfill user requirements. While on other projects that never see the light of day, people get appreciation, are allowed to work with new technologies and do cool stuff. Nobody ever asked the Smalltalkers whether they could do that as well, because "if you want to do web, you need to do Java". IBM said so, you know (and many other consultants as well). So this is why new people try to stay away from these old projects. This is why the remaining staff is frustrated and this is why nobody allows them to do the cool things that Smalltalk can do as well as the others. They are just required to fix bugs, add new features in the old GUIs and else keep silent. Some of them were trying to fight this and tried to prove Smalltalk's strengths, but back then nobody would listen. One day they gave up. Management still frustrates people every. single. day. Just my opinion Joachim Am 22.10.17 um 18:56 schrieb Petr Fischer: > Here. (But from one point of view, it's a litte misery, 10-20 year old code sometimes, a mess, old VAST, absolutely no interest from young colleagues with no experience to willingly learn something about Smalltalk etc etc.). > > If I bring up enough arguments, we will use Gemstone+Pharo tools in the future, which is a dream for me... but, we will see... > > pf > >> At https://news.ycombinator.com/item?id=15523807 >> the question is asked... "Does anyone on here program in Smalltalk >> professionally? Not to get off topic, but I'm curious and would like to >> know how it stacks up compared to what they did previously? " >> >> If you've earning a living from programming Smalltalk, please drop a >> comment there. >> >> cheers -ben > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1Â Â Â Â Â Â Â Â Â Â Â Â Â http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0Â Â Â Â Â Fax: +49 7141 56 10 86 1

Oct. 23, 2017

Re: [Pharo-users] About Ztimestamp

by Sven Van Caekenberghe

Hi Stef, > On 22 Oct 2017, at 17:45, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi sven > > I'm confused > > ft := ZTimestampFormat fromString: '02/11/2017'. > ft format: DateAndTime now > > produces 10/11/1017060986 > > While I do not want time but just the date. > and the date is wrong. > > So I will do it manually but I found sad that ZTimestampFormat cannot > handle just handling days. > I could then pass also a date and it would not ask for nanoseconds. > > Stef ZTimestampFormat works with example based format specifications. This works by making each component unique, using a sequential number. Consult the class comment for a full explanation. The class side's #formatSpecifications lists the tokens that are understood and their meaning. To go back to your issue, The year is the first component, written as 2001, the month the third and the day the second. So you probably want to do: (ZTimestampFormat fromString: '03/02/2001') format: DateAndTime now. => '22/10/2017' HTH, Sven

Oct. 22, 2017

Re: [Pharo-users] perspective request for those earning a living from Smalltalk

by Stephane Ducasse

Push petr! We are trying hard to make Pharo really a different programming experience and slowly we are getting there. Stef On Sun, Oct 22, 2017 at 6:56 PM, Petr Fischer <petr.fischer(a)me.com> wrote: > Here. (But from one point of view, it's a litte misery, 10-20 year old code sometimes, a mess, old VAST, absolutely no interest from young colleagues with no experience to willingly learn something about Smalltalk etc etc.). > > If I bring up enough arguments, we will use Gemstone+Pharo tools in the future, which is a dream for me... but, we will see... > > pf > >> At https://news.ycombinator.com/item?id=15523807 >> the question is asked... "Does anyone on here program in Smalltalk >> professionally? Not to get off topic, but I'm curious and would like to >> know how it stacks up compared to what they did previously? " >> >> If you've earning a living from programming Smalltalk, please drop a >> comment there. >> >> cheers -ben >

Oct. 22, 2017

[Pharo 70] Integration log

by Stephane Ducasse

Oct. 22, 2017

[Pharo 70] Integration log

by Stephane Ducasse

Oct. 22, 2017

Re: [Pharo-users] perspective request for those earning a living from Smalltalk

by Petr Fischer

Here. (But from one point of view, it's a litte misery, 10-20 year old code sometimes, a mess, old VAST, absolutely no interest from young colleagues with no experience to willingly learn something about Smalltalk etc etc.). If I bring up enough arguments, we will use Gemstone+Pharo tools in the future, which is a dream for me... but, we will see... pf > At https://news.ycombinator.com/item?id=15523807 > the question is asked... "Does anyone on here program in Smalltalk > professionally? Not to get off topic, but I'm curious and would like to > know how it stacks up compared to what they did previously? " > > If you've earning a living from programming Smalltalk, please drop a > comment there. > > cheers -ben

Oct. 22, 2017

About Ztimestamp

by Stephane Ducasse

Hi sven I'm confused ft := ZTimestampFormat fromString: '02/11/2017'. ft format: DateAndTime now produces 10/11/1017060986 While I do not want time but just the date. and the date is wrong. So I will do it manually but I found sad that ZTimestampFormat cannot handle just handling days. I could then pass also a date and it would not ask for nanoseconds. Stef

Oct. 22, 2017

Re: [Pharo-users] perspective request for those earning a living from Smalltalk

by Mariano Martinez Peck

Done :) On Sun, Oct 22, 2017 at 10:33 AM, Ben Coman <btc(a)openinworld.com> wrote: > At https://news.ycombinator.com/item?id=15523807 > the question is asked... "Does anyone on here program in Smalltalk > professionally? Not to get off topic, but I'm curious and would like to > know how it stacks up compared to what they did previously? " > > If you've earning a living from programming Smalltalk, please drop a > comment there. > > cheers -ben > -- Mariano http://marianopeck.wordpress.com

Oct. 22, 2017