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

perspective request for those earning a living from Smalltalk

by Ben Coman

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

Re: [Pharo-users] Zinc HTTP Component HTTP/2?

by Esteban Lorenzano

Hi Holger, We talked a bit about this last ESUG. Sadly, it requires serious work to have it so we hadnât put this in any schedule yet :( Esteban > On 21 Oct 2017, at 16:26, Volkert <volkert(a)komponentenwerkstatt.de> wrote: > > Dear all, > > the world is moving to http/2. Any plans for Zinc HTTP Components to > support this standard? > > BW, Volkert > > >

Oct. 22, 2017

Zinc HTTP Component HTTP/2?

by Volkert

Dear all, the world is moving to http/2. Any plans for Zinc HTTP Components to support this standard? BW, Volkert

Oct. 21, 2017

Re: [Pharo-users] Bloc texts font size

by Steven Costiou

Thanks Alex. Not much success with this trick however, do you use scaleTo:, scaleBy:.. ? and on the BlTextElement or on the BrRopedText ? It also seems that some sizes work better, like 45, 55, and 70 are ok aswell as everything under 40. I'll try to avoid the problematic sizes for the moment. Unfortunately i am on linux and have trouble with brick and Moz2D, specifically on raspberry pi - but otherwise just bloc works fine so i'll stick with it for now :) Steven. Le 2017-10-20 19:52, Aliaksei Syrel a Ã©crit : > Hi Steven, > > It is a known Cairo + Freetype bug. If you are on OSX try to install #development version of Bloc/Brick that uses Moz2D as rendering backend. > Cairo does not support named fonts because it there is no system fonts lookup. Moz2D supports it. > > One way to fix strange font size is to apply scaling by 1.0001. Text measurement will still be broken, though... > > Other than that you code looks good! > > Cheers, > Alex > On 20 October 2017 at 15:04, Steven Costiou <steven.costiou(a)kloum.io> wrote: > >> Hi, >> >> i am trying to set the font size of a BlTextElement, and i do not have much success. I use the following code to add the text element, where 'model' is a string. >> >> First, if the string is '0.0' then the font size is correct (see screenshot). But, if for example the value is '21.0' then the font size is wrong (see the other screenshot). I don't understand, i've tried variants but it seems to me that this code was the right way to do it. Sometimes, a '9' would be displayed at the correct font size, sometimes not. Any ideas ? >> >> text := BlTextElement new >> text: >> ((BrRopedText string: model) >> attributes: >> {(BrTextForegroundAttribute paint: (Color green alpha: 0.8)). >> (BrFontSizeAttribute size: 60). >> (BrFontWeightAttribute weight: 50). >> (BrFontGenericFamilyAttribute monospace). >> "(BrFontFamilyAttribute named: 'Source Sans Pro')"}); >> yourself. >> >> text >> constraintsDo: [ :c | >> c frame horizontal alignCenter. >> c frame vertical alignCenter ]. >> >> "text is added to a parent BlElement" >> self addChild: text >> >> Second, i don't have the impression that changing the font family does have any effect (but maybe its my local setup i don't know...). >> >> Steven.

Oct. 20, 2017

Re: [Pharo-users] Bloc texts font size

by Aliaksei Syrel

Hi Steven, It is a known Cairo + Freetype bug. If you are on OSX try to install #development version of Bloc/Brick that uses Moz2D as rendering backend. Cairo does not support named fonts because it there is no system fonts lookup. Moz2D supports it. One way to fix strange font size is to apply scaling by 1.0001. Text measurement will still be broken, though... Other than that you code looks good! Cheers, Alex On 20 October 2017 at 15:04, Steven Costiou <steven.costiou(a)kloum.io> wrote: > Hi, > > i am trying to set the font size of a BlTextElement, and i do not have > much success. I use the following code to add the text element, where > 'model' is a string. > > First, if the string is '0.0' then the font size is correct (see > screenshot). But, if for example the value is '21.0' then the font size is > wrong (see the other screenshot). I don't understand, i've tried variants > but it seems to me that this code was the right way to do it. Sometimes, a > '9' would be displayed at the correct font size, sometimes not. Any ideas ? > > text := BlTextElement new > text: > ((BrRopedText string: model) > attributes: > {(BrTextForegroundAttribute paint: (Color green alpha: > 0.8)). > (BrFontSizeAttribute size: 60). > (BrFontWeightAttribute weight: 50). > (BrFontGenericFamilyAttribute monospace). > "(BrFontFamilyAttribute named: 'Source Sans Pro')"}); > yourself. > > > text > constraintsDo: [ :c | > c frame horizontal alignCenter. > c frame vertical alignCenter ]. > > > "text is added to a parent BlElement" > self addChild: text > > Second, i don't have the impression that changing the font family does > have any effect (but maybe its my local setup i don't know...). > > Steven. >

Oct. 20, 2017

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

by Herby VojÄÃk

Denis Kudriashov wrote: > So you want to stub message to *any* instance of class. Right? > > Conceptually, in Mocketry/StateSpecs way, it should looks like: > > (Instance of: Something) stub askForName willReturn: 'new'. > > or: > > (Kind of: Something) stub askForName willReturn: 'new'. > > > But it will not really works. It will work only on instances which are > already "stubbed". > Making it really transparent will require crazy magic underhood. And I > am not sure that it is really possible. > Because generally it should cover existing instances and not just newly > created during test. > And for simple case: to automatically stub new instances their classes > should be stubbed with special constructors. But system do not know what > exact class side messages are constructors. 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 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. 20, 2017

CfP <Programming> 2018: Research Papers Third Submission Deadline

by Sylvia Grewe

<Programming> 2018 : The Art, Science, and Engineering of Programming Mon 9 - Thu 12 April 2018 Nice, France http://2018.programming-conference.org/ In 2017, we started a new conference and journal focused on everything to do with programming, including the experience of programming, called <Programming> for short. The first edition of <Programming> was a great success (see http://twitter.com/programmingconf for testimonies). Paper submissions and publications are handled by the affiliated journal (http://programming-journal.org/) Accepted papers must be presented at the conference. ******************************************************** CALL FOR PAPERS ******************************************************** <Programming> 2018 accepts papers that advance knowledge of programming. Almost anything about programming is in scope, but in each case there should be a clear relevance to the act and experience of programming. UPCOMING SUBMISSION DEADLINES: December 1 2017 (Research Papers Third Submission Deadline, for journal Vol. 2, Issue 3) We accept submissions covering several areas of expertise. These areas include, but are not limited to: â¢ General-purpose programming â¢ Distributed systems programming â¢ Parallel and multi-core programming â¢ Graphics and GPU programming â¢ Security programming â¢ User interface programming â¢ Database programming â¢ Visual and live programming â¢ Data mining and machine learning programming â¢ Interpreters, virtual machines and compilers â¢ Modularity and separation of concerns â¢ Model-based development â¢ Metaprogramming and reflection â¢ Testing and debugging â¢ Program verification â¢ Programming education â¢ Programming environments â¢ Social coding ******************************************************** IMPORTANT UPCOMING DATES ******************************************************** Research paper submissions: December 1 2017 (Research Papers Third Submission Deadline, for journal Vol. 2, Issue 3) Research paper first notification (for third submission deadline): February 1 2018 Research paper revised submission (for third submission deadline): March 1 2018 Research paper final notification (for third submission deadline): March 7 2018 Camera-ready copy (for third submission deadline): March 15 2018 Student Research Competition Abstracts Submission: January 22 2018 All important dates of the journal throughout the year can also be found at http://programming-journal.org/timeline/ ******************************************************** ORGANIZATION ******************************************************** General Chair: Manuel Serrano, INRIA France Local Organizing Chair: Tamara Rezk, INRIA France Organizing Committee: Stefan Marr (workshops co-chair), University of Kent, United Kingdom Jennifer B. Sartor (workshops co-chair), Software Languages Lab, Vrije Universiteit Brussel Belgium Philipp Haller (student research competition chair), KTH Royal Institute of Technology, Sweden Tobias Pape (web technology), HPI - University of Potsdam Sylvia Grewe (publicity), Technische UniversitÃ¤t Darmstadt Germany Minh Ngo (volunteers chair), INRIA France Etienne Lozes (grants committee chair), UniversitÃ© de Nice Sophia-Antipolis, France Yves Roudier (poster chair), UniversitÃ© de Nice Sophia-Antipolis, France Program Committee: Guido Salvaneschi (program chair), Technische UniversitÃ¤t Darmstadt, Germany Davide Ancona, University of Genova, Italy Alberto Bacchelli, Delft University of Technology, Netherlands Shigeru Chiba, University of Tokyo, Japan Yvonne Coady, University of Victoria, Canada Susan Eisenbach, Imperial College London, UK Patrick Eugster, TU Darmstadt, Germany & Purdue University, United States Antonio Filieri, Imperial College London, UK Matthew Flatt, University of Utah, United States Lidia Fuentes, Universidad de MÃ¡laga, Spain Richard P. Gabriel, Dream Songs, Inc. & HPI, California Jeremy Gibbons, University of Oxford, UK Yossi Gil, Israel Institute of Technology Elisa Gonzalez Boix, Vrije Universiteit Brussel, Belgium Phlipp Haller, KTH Royal Institute of Technology, Sweden Matthew Hammer, University of Colorado, Boulder, United States Felienne Hermans, Delft University of Technology, Netherlands Robert Hirschfeld, Hasso Plattner Institute (HPI), Germany Roberto Ierusalimschy, Pontifical Catholic University of Rio de Janeiro, Brazil Jun Kato, National Institute of Advanced Industrial Science and Technology, Japan JÃ¶rg Kienzle, McGill University, Canada Neelakantan R. Krishnaswami, University of Cambridge, UK Ralf LÃ¤mmel, University of Koblenz-Landau, Germany Hidehiko Masuhara, Tokyo Institute of Technology, Japan Mira Mezini, Technische UniversitÃ¤t Darmstadt, Germany Emerson Murphy-Hill, North Carolina State University, United States Mario SÃ¼dholt, IMT Atlantique, Nantes, France Sam Tobin-Hochstadt, Indiana University, United States Eelco Visser, Delft University of Technology, Netherlands Tijs van der Storm, CWI & University of Groningen, Netherlands ******************************************************** <Programming> 2018 is kindly supported by: ACM In-Cooperation SIGPLAN (In-cooperation) SIGSOFT (In-cooperation) INRIA France AOSA ********************************************************

Oct. 20, 2017

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

by Jimmie Houchin

Thanks for the reply and for your explanation and Pharo's position on this idea and on the subject of namespaces and modules. I was simply offering a solution that was presented at Smalltalks conference. My use of Pharo is in the small. I do not in general see or know the problems associated with namespaces. I may see consequences in other people's software I use in Pharo because of the naming of classes. But it is them that dealt with the problem. I am very unqualified to comment or address either of these issues. I just didn't know who had seen the video and if it offered a solution or not. Thank you for engaging the conversation so that we have a position on record regarding a publicly available video which offers their view on a solution. You addressed one of the things I do love about Pharo and its expressed goals is that it seeks to offer real working solutions. I am okay that the hard things take time, and am happy that they are being addressed even if it takes some time. Pharo is shaping up very nicely. Thanks. Jimmie On 10/20/2017 04:07 AM, Stephane Ducasse wrote: > For the record at ESUG at Prague there was a really interesting > discussion about namespace and some people working with newspeak > mentioned that the namesapce there was a hell. And I trust these > people. So good luck. > > For the record we are working and we are making progress on module > system for Pharo but as I explained at ESUG this year. We do not want > just to have a namespace. We want a system that does not kill the live > programming experience. > Imagine you have two browsers opened: > > - in N3 one one you inherit from a class A import from N1 > - then in N1 you decide to move that class A to N2 > > Should the system discard all the subclasses from A n N3 because it > cannot find anymore the class A? > > This is why we are working on > - during year we remove harcoded reference to Smalltalk > - Undefined classes (read the IWST 2017 paper) > - new class definition > - model for class definition > - real life programming supporting module system. > > So each time I hear about namespace, I think that the best way to get > a namespace system for Pharo is to help doing something else. > This way we can concentrate on building a real working solution for > Pharo. But since we have many other things to do then it takes time. > > Stef > > > > > > On Fri, Oct 20, 2017 at 2:30 AM, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >> Absolutely. I have contemplated giving it a try. But when I go look at the >> mailing list, it looks like such a lonely place. I still might give it a go. >> It looks interesting. >> >> Jimmie >> >> >> On 10/19/2017 05:20 PM, Ben Coman wrote: >> >> btw, are you aware that Newspeak is developed on top of the CogVM that >> Pharo, Squeak, Cuis all share? >> cheers -ben >> >> On Fri, Oct 20, 2017 at 12:27 AM, Jimmie Houchin <jlhouchin(a)gmail.com> >> wrote: >>> I watched this video a year ago and was intrigued. I have not thought >>> about it deeply and do not know consequences of this model. However, Gilad >>> is a smart man who has thought deeply about these things and has experienced >>> consequences as a language designer. But it does sound interesting and I >>> wonder if it would potentially be a solution to the namespace or modularity >>> problems. >>> >>> https://youtu.be/pM0Hz4pFDZM >>> >>> He is talking about Newspeak in 2016 and what I refer to is its use of >>> Nested Classes. >>> >>> No Global Namespace >>> No Global Variables >>> No Pool Variables >>> No Class Variables >>> No Class Instance Variables >>> >>> I have no idea if it would work for Pharo or what would be involved in >>> implementing such. Or even if the community or leaders would even care to >>> explore that direction. I have not seen it discussed here. >>> >>> Just wanted to toss his discussion of these ideas into the arena of ideas >>> for Pharo. >>> >>> Jimmie >>> >>> >>> >>> On 10/13/2017 07:53 AM, Esteban A. Maringolo wrote: >>>> 2017-10-13 5:55 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: >>>>>> Am 13.10.2017 um 10:24 schrieb stephan <stephan(a)stack.nl>: >>>>>> >>>>>> On 13-10-17 09:55, Thierry Goubier wrote: >>>>>>> Because namespaces, by essence, come with serious issues. I won't take >>>>>>> someone seriously on namespaces until he can cite those faithfully. >>>>>> Let's start with the misconception that namespaces are about >>>>>> modularisation >>>>>> >>>>> +1 >>>> +1 to this as well. >>>> >>>> Having modularization is like having security, very hard to add them >>>> later if you didn't include it in the original design. >>>> >>>> I'm using VisualWorks these days, and I find its namespaces something >>>> more of a hassle than a real use. >>>> >>>> If we could name Classes with a dot, that could solve most of what >>>> namespaces are used for in practice: avoiding name colissions. >>>> That's why most of the popular frameworks have prefixes like Zn, WA, >>>> RB, and so on and so forth. But now I'm used to prefixes, I don't need >>>> them. :) >>>> >>>> Modularity is a different beast, if you look at how some modules work >>>> in JS, like AMD, you see that in practice they avoid collisions by >>>> importin what they need from a module, and assign it to a "namespace" >>>> (it is not, but works as such), so they get modules first, and >>>> namespacing later. >>>> >>>> Regards, >>>> >>>> Esteban. >>>> >>> >>

Oct. 20, 2017

ANN: Smalltalk Express Blog

by Peter Fisk

Hi everyone, I have started a new blog to discuss the "Smalltalk Express" framework. https://smalltalkexpress.quora.com/ Smalltalk Express is web development framework using a Smalltalk interpreter written in the "Go" language. The first blog post provides some details and a video. A few months ago, I built an experimental framework called "Rails Express" which had an interactive interpreter based on Ruby. The feedback that I have received has been fantastic. "Smalltalk Express" uses all the same UI techniques and is designed to be capable of production deployment. I am intending to offer "Smalltalk Express" initially as a service based on Google's App Engine, but I would be happy to hear any ideas of how to market the product. The product website will be "smalltalk.express" (smalltalk - dot - express). Thoughts and feedback are welcome. Cheers, -- Peter -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by Peter Fisk

Thank you Joachim! That is the most honest assessment of the situation of Smalltalk in 2017 that I have ever seen. And I agree with you 100%. We need a new Smalltalk which is both "cool" and can seamlessly integrate with all of the latest web technologies. I will be releasing a new Smalltalk framework very shortly called "Smalltalk Express". The interpreter is written in the "Go" language and can run on all of the major web platforms such as Google, Heroku, etc. I use Pharo to manage the Smalltalk code. Here is a new blog that I have started to discuss the project. https://smalltalkexpress.quora.com/ Also, I have reserved the web address "smalltalk.express" for use once the code goes live. There is a video in the blog post so you can get an idea of where things stand right now. -- Peter On Fri, Oct 20, 2017 at 3:23 AM, jtuchel(a)objektfabrik.de < jtuchel(a)objektfabrik.de> wrote: > First of all: I'd say the question itself is not a question but an excuse. > I am not arguing there are enough Smalltalkers or cheap ones. But I think > the question is just a way of saying "we don't want to do it for reasons > that we ourselves cannot really express". If you are a good developer, > learning Smalltalk is easy. If you are a good developer you've heard the > sentence "we've taken the goos parts from x,y,z and Smalltalk" at least > twice a year. So you most likely would like to learn it anyways. > > A shortage of developers doesn't exist. What exists is an unwillingness of > companies to get people trained in a technology. If Smalltalk was cool and > great in their opinion, they wouldn't care. It's that simple. As a > consultant, I've heard that argument so often. Not ferom Startups, but from > insurance companies, Banks or Car manufacturers who spend millions on > useless, endless meetings and stuff instead of just hiring somebody to > teach a couple of developers Smalltalk. It's just a lie: the shortage of > Smalltalk developers is not a problem. > > And, to be honest: what is it we actually are better in by using Smalltalk? > Can we build cool looking web apps in extremely short time? No. > Can we build mobile Apps with little effort? No. > Does our Smalltalk ship lots of great libraries for all kinds of things > that are not availabel in similar quality in any other language? > Are we lying when we say we are so extremely over-productive as compared > to other languages? > > I know, all that live debugging stuff and such is great and it is much > faster to find & fix a bug in Smalltalk than in any other environment I've > used so far. But that is really only true for business code. When I need to > connect to things or want to build a modern GUI or a web application with a > great look&feel, I am nowhere near productive, because I simply have to > build my own stuff or learn how to use other external resources. If I want > to build something for a mobile device, I will only hear that somebody > somewhere has done it before. No docs, no proof, no ready-made tool for me. > > > Shortage of developers is not really the problem. If Smalltalk was as cool > as we like to make ourselves believe, this problem would be non-existent. > If somebody took out their iPad and told an audience: "We did this in > Smalltalk in 40% of the time it would have taken in Swift", and if that > something was a must-have for people, things would be much easier. But > nobody has. > > > I am absolutely over-exaggerating, because I make my living with an SaaS > product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk > and - as you - am convince that many parts of what we've done so far > would've taken much longer or even be impossible in other languages. But > the advantage was eaten by our extremely steep learning curve for web > technologies and for building something that works almost as well as tools > like Angular or jQuery Mobile. > > Smalltalk is cool, and the day somebody shows me something like Google's > flutter in Smalltalk, I am ready to bet a lot on a bright future for > Smalltalk. But until then, I'd say these arguments about productivity are > just us trying to make ourselves believe we're still the top of the food > chain. We've done that for almost thirty years now and still aren't ready > to stop it. But we've been lying to ourselves and still do so. > > I don't think there is a point in discussing about the usefulness of a > language using an argument like the number or ready-made developers. That > is just an argument they know you can't win. The real question is and > should be: what is the benefit of using Smalltalk. Our productivity > argument is a lie as soon as we have to build something that uses or runs > on technology that has been invented after 1990. > > > Okay, shoot ;-) > > Joachim > > > -- > ----------------------------------------------------------------------- > 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. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by Dimitris Chloupis

Actually you need to read the small letters bellow the graph "% of developers who are developing with the language or technology and have expressed interest in continuing to develop with it" which means basically "Smalltalkers love Smalltalk !!!|" . Actually I am surpised its only 67% of Smalltalkers that actually love Smalltalk and that Rust comes first. I was expecting a 90%. But then Rust has been the most hyped language these past few years. But does not change the fact that maybe 99% of the coders have not even heard of Smalltalk and a 60% of Rust. The bottom line is that the excuses for not using a language can no longer stand in 2017 (1) But I wont find coders for it (2) But I wont find libraries for it (3) But I wont find documentation for it Let's take (1) , why you even need to find someone that already knows the language? Do we realise there are people with zero coding experience that have made built milti million dollar empires . Almost 2 decades ago I remember reading about q surfer that loved to surf but also made surf boards. So inside his naiveness said "well let's make an e-shop" and he made alone one of the first e-shops selling surf boards and he made millions. So we have this guy that knows nothing about coding, I think I remember him saying that he did not even know how to use a computer before, on one side that in a period of few years has made a multi million dollars software. On the other side we have experienced coders, that most likely have battled with code bases of millions of lines of code , university degree, masters and doctorate and they cannot do what a surfer did ? Seriously.... (2) That's my favourite , libraries. We live in 2017 when even my grandmother's language run on JVM and has JS compiler and we still debate libraries availability ? Seriously. You can use ANY library from ANY language and is not even hard. I made Pharo use Python libraries and it took me a few hundreds lines of code just to make a simple socket bridge. (3) This one is the most logical, even when I i started coding in Pharo and to be fair Pharo was still on very early releases there was minimal documentation and the one I found was outdated. Still no problemo, I am a coder, I can read code. You will be reading tons and tons of code anyway, documentation in any language will never take you far. Why ? Because the vast majority of users prefer the easy and generic features. A minority of people dive deep into a library and the ones they do rare document it. You are more likely to find specialised information in mailing and forums than in documentation documents. Of course even there you may get no answer so you end up testing and learning yourself. Wont mattter even if it is Java. Plus there are tons and ton of project made in languages very unpopular that did great, Ruby On Rails is an example. One library it was all it took to put Ruby on map. Even C was introduce through the Unix operating system. New language, out of nowhere and wait those people using an unknown language wanted to make one of the best OSes of all time. So no, even though I rarely get into a language debate because of how religious people , there is no for not using Pharo but any unpopular language out there. Because in the end what it will matter the most is the determination of the coder to output efficient code. If you are passionate about something nothing can stop you and especially these bad excuses. Pretty much the most important ingredient for any very successful software product. On Fri, Oct 20, 2017 at 11:37 AM Paulo R. Dellani <dellani(a)pobox.com> wrote: > I also do not believe my eyes: > > > https://insights.stackoverflow.com/survey/2017#most-loved-dreaded-and-wanted > > > On 10/20/2017 10:20 AM, Marten Feldtmann wrote: > > I do not want to spoil the party (perhaps I've done this already) - but > > has anyone done a serious inspection of this number: 67%. > > > > They have interviewed 64000 persons and 67% of the people should "love" > > Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the > > user already using Smalltalk "love" that. > > > > By the way - the most loved platform is Linux (69%) ... > > > > > > Marten > > > > Am 20.10.2017 um 09:19 schrieb Paulo R. Dellani: > > > >> The second most loved language by 67% of developers surveyed cannot > simply > >> be ruled out because of unfounded concerns. (Thanks again for the > > > > >

Oct. 20, 2017

Bloc texts font size

by Steven Costiou

Hi, i am trying to set the font size of a BlTextElement, and i do not have much success. I use the following code to add the text element, where 'model' is a string. First, if the string is '0.0' then the font size is correct (see screenshot). But, if for example the value is '21.0' then the font size is wrong (see the other screenshot). I don't understand, i've tried variants but it seems to me that this code was the right way to do it. Sometimes, a '9' would be displayed at the correct font size, sometimes not. Any ideas ? text := BlTextElement new text: ((BrRopedText string: model) attributes: {(BrTextForegroundAttribute paint: (Color green alpha: 0.8)). (BrFontSizeAttribute size: 60). (BrFontWeightAttribute weight: 50). (BrFontGenericFamilyAttribute monospace). "(BrFontFamilyAttribute named: 'Source Sans Pro')"}); yourself. text constraintsDo: [ :c | c frame horizontal alignCenter. c frame vertical alignCenter ]. "text is added to a parent BlElement" self addChild: text Second, i don't have the impression that changing the font family does have any effect (but maybe its my local setup i don't know...). Steven.

Oct. 20, 2017

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

by Denis Kudriashov

So you want to stub message to *any* instance of class. Right? Conceptually, in Mocketry/StateSpecs way, it should looks like: (Instance of: Something) stub askForName willReturn: 'new'. or: (Kind of: Something) stub askForName willReturn: 'new'. But it will not really works. It will work only on instances which are already "stubbed". Making it really transparent will require crazy magic underhood. And I am not sure that it is really possible. Because generally it should cover existing instances and not just newly created during test. And for simple case: to automatically stub new instances their classes should be stubbed with special constructors. But system do not know what exact class side messages are constructors. 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>: > 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>: > >> 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> >> 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> >>> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: >>> >>> 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. 20, 2017

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

by Peter UhnÃ¡k

Ah, right. I was expecting that other objects sending the message will receive the mocked result. Thanks, Peter On Fri, Oct 20, 2017 at 2:21 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 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>: > >> 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> >> 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> >>> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: >>> >>> 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. 20, 2017

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

by Denis Kudriashov

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>: > 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> > 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> >> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: >> >> 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. 20, 2017