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

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