January 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Generating a binary package like PharoLauncher

by HernÃ¡n Morales Durand

Hi Serge, I wrote a code generator package with uses Mustache and generates a NSIS script. As an example: CGNSISIPharo4AppInstaller uniqueInstance product: 'MyProduct'; identity: 'MyName'; version: '1.0.0'; url: 'http://www.google.com'; launcher: 'MyLauncher.exe'; licenseEnFileName: 'LICENSE_ENGLISH'; iconFile: 'MyProduct.ico'; welcomeBmpFile: 'MyProduct.bmp'; splashBMPFileName: 'Splash.bmp'; generate. Maybe that's what you're looking for? HernÃ¡n 2016-01-18 14:23 GMT-03:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > Dear all, > > I would like to distribute Kendrick like PharoLauncher, i.e as a > binary package for mac and windows. Are the script of CI for > generating PharoLauncher available somewhere ? > > Thank you. > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

Jan. 20, 2016

Re: [Pharo-users] Use cases for methods with optional parameters

by HernÃ¡n Morales Durand

Hi Damien, As far as I know this describes the Robert Hirschfeld's Convenience Methods pattern. I wrote a code generator package which generates this pattern through an API like this: CGStConvenienceMethods uniqueInstance setCleanTarget; parameterCount: 2; targetSelector: #cgConvEx2; addReturn; targetClassCategory: 'ConvenienceMethodsEx'; targetClass: #ConvenienceMethodsEx; generateMethods. That expression generates a class named ConvenienceMethodsEx with 3 methods: #cgConvEx2 #cgConvEx2with: #cgConvEx3with:with: where each method passes nil as default parameter to it's "subsequent" version (same selector +1 parameter). Cheers, HernÃ¡n 2016-01-20 12:08 GMT-03:00 Damien Cassou <damien.cassou(a)inria.fr>: > Hi, > > I would like to study the impact of adding optional parameters to > keyword methods in Pharo. The goal of optional parameters is to > facilitate the implementation of methods where some parameters are > optional. For example, Seaside has: > > WAComponent>>request: aRequestString label: aLabelString > default: aDefaultString onAnswer: aBlock > > ... > > This method of 4 arguments has only 1 required argument (aRequestString) > and 3 optional ones. In the current implementation, this results in 7 > additional methods that only delegate directly or indirectly to the one > above: > > - request: > - request:default: > - request:default:onAnswer: > - request:label: > - request:label:default: > - request:label:onAnswer: > - request:onAnswer: > > Before starting to implement anything, I need to know if it makes sense. > If you want to help me, please send me all the use cases you have by > giving me: > > - the library name (and URL if not in Catalog), or "pharo" if it's in > Pharo > - the class where this happens > - the range of selectors that make sense > > For the example above, this would be: > > - Seaside > - WAComponent > - request:* > > > Thank you very much > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > >

Jan. 20, 2016

Re: [Pharo-users] Dynamic Typing > Static Typing? Â« games.greggman.com

by David Allouche

> On 20 Jan 2016, at 19:27, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > > I will not argue whether or not Smalltalk and Lisp were right all along. However, the fact that Smalltalk and Lisp are where they are is not simply a matter of technical merit. There were many, many, political decisions made by the owners of the technology which participated in its successes and failures. > > Proprietary, commercial, expensive, and the varying corporate entities one had to deal with in order to use this software was a huge factor. Us small guys who would want to use this fantastic enabling technology had our limitations in acquiring this technology. You had to have money and really want to spend it in this manner. > > This is not to make derogatory statements about their decisions. But they did have an impact. Had the best of Smalltalk and Lisp been open sourced 20 to 30 years ago. Would this be a very different world? I think so. However, the income and profits of those corporations would have been different also. It wasn't our decision to make and we were not living in their shoes. We would have to become knowledgeable about the economics, the state of the competition, the state of their own business, etc. to become even reasonably qualified to judge. Even then different people make different decisions because they think differently or even possibly are looking for different results. Open source was a different and very foreign world back then. It was a very foreign thought to open source your intellectual property and believe that you could earn a living from it. You do have to think different to be a creator of open source software and to be successful at making a living from it. > > What if Sun put the effort into Strongtalk that they put into Java? Where would we be? > > I personally believe Smalltalk and Lisp had it right. Own the entire environment and machine. Turtles all the way down. > > Unfortunately the world isn't so clean. However, we do have a very nice open source Smalltalk inspired tool in Pharo. While the past was not in our control. We do have a say about the future. :) > Lets make the future great! Well spoken! Free software became a business enabler thanks to the web. Back then, there was no web, no ability to build global communities pushing forward a shared artefact. I think that is no coincidence that the oldest language that is still mainstream is C, which was used to build Unix, which was used to build the web. Now, let's do something awesome :-)

Jan. 20, 2016

Re: [Pharo-users] Updating a project and NIL class variables

by Sven Van Caekenberghe

> On 20 Jan 2016, at 18:06, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > > âThe warning is: this only happens when the *source* code of the #initialize methods changes. So sometimes, you will have to touch that method to force it.â > Perhaps there should be an overload able method that decides whether or not to initialize the class, such that classes relying on reinitializing every time a change is merged, can do this by simply answering true? Seems like a good idea, to modify the logic in MCMethodDefinition>>#postloadOver: However, I have a feeling that maybe people already have thought/discussed about this in the past, maybe we should find out why it was decided to do it like this. A question is also: will the test method only run in the existing image, and/or does the incoming code have an influence, because that could require two version before an initialiser runs in the worst case (previous version says no, incoming says yes). Just thinking out loud. > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Dimitris Chloupis > Sent: Wednesday, January 20, 2016 3:47 PM > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] Updating a project and NIL class variables > > no apologies owed, I just asked because I want to make sure Pharo wont do anything weird behind my back :) > > On Wed, Jan 20, 2016 at 4:39 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 20 Jan 2016, at 15:34, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > > > Thank you for the info but I think I did not make myself clear because you say "remain nil" > > > > Ok Imagine a class SomeClass and that class has a variable we will call SomeVariable, class variable that is > > , there is no class initialize method, now that class has a method that is eventually called , > > someMethod > > > > SomeVariable ifNil: [ SomeVariable := 'hello world'] > > > > so when I decide to update this class via metacello loading the latest version from github , SomeVariable will have the value 'hello world' > > > > My question is , will SomeVariable after I do the update revert back to nil or stay 'hello world' ? > > > > If your answer is no, and it stays 'hello world' then yes i need an initialize method and call it at update time. > > Argh, I should have said: keeps it value, will not revert to nil. > > Sorry for the confusion ! > > > On Wed, Jan 20, 2016 at 2:54 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > They remain nil. > > > > That is why #initialize on the class side is needed. > > > > You can call that explicitly in a post load script, or rely on the class loading mechanism that normally calls #initialize automatically when loading a class. The warning is: this only happens when the *source* code of the #initialize methods changes. So sometimes, you will have to touch that method to force it. > > > > I hope that makes sense. > > > > See MCMethodDefinition>>#postloadOver: > > > > > On 20 Jan 2016, at 13:41, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > > > > > So my question is this , I have a class with nil variables that are lazy initialised only when needed the first time and of course they keep their values from there on. > > > > > > Lets say I get the latest update from github via metacello over an older update that I already have inside the image , do those variables revert back to nil values ? or do they keep their values as they are ? > > > > >

Jan. 20, 2016

Re: [Pharo-users] Dynamic Typing > Static Typing? Â« games.greggman.com

by Jimmie Houchin

I will not argue whether or not Smalltalk and Lisp were right all along. However, the fact that Smalltalk and Lisp are where they are is not simply a matter of technical merit. There were many, many, political decisions made by the owners of the technology which participated in its successes and failures. Proprietary, commercial, expensive, and the varying corporate entities one had to deal with in order to use this software was a huge factor. Us small guys who would want to use this fantastic enabling technology had our limitations in acquiring this technology. You had to have money and really want to spend it in this manner. This is not to make derogatory statements about their decisions. But they did have an impact. Had the best of Smalltalk and Lisp been open sourced 20 to 30 years ago. Would this be a very different world? I think so. However, the income and profits of those corporations would have been different also. It wasn't our decision to make and we were not living in their shoes. We would have to become knowledgeable about the economics, the state of the competition, the state of their own business, etc. to become even reasonably qualified to judge. Even then different people make different decisions because they think differently or even possibly are looking for different results. Open source was a different and very foreign world back then. It was a very foreign thought to open source your intellectual property and believe that you could earn a living from it. You do have to think different to be a creator of open source software and to be successful at making a living from it. What if Sun put the effort into Strongtalk that they put into Java? Where would we be? I personally believe Smalltalk and Lisp had it right. Own the entire environment and machine. Turtles all the way down. Unfortunately the world isn't so clean. However, we do have a very nice open source Smalltalk inspired tool in Pharo. While the past was not in our control. We do have a say about the future. :) Lets make the future great! Shalom Aleichem Jimmie On 01/20/2016 10:13 AM, Dimitris Chloupis wrote: > indeed python and C++ are not just diffirent but two languages going > the exact opposite directions, Python emphasizing speed of development > , C++ emphasizing speed of execution. > > In C/C++ every decision must be based upon performance, this not how > any other language works , even Java is not that worried about > performance, sure its important but it is not the main goal. > > Hence its not surprising that C++ is the undisputed choice for very > performance orientated fields, like Gaming, audio , science that > involves heavy calculation. Look at python how popular it has become > for scientists but AFTER the fact that so many C++ libraries have been > made for python like numpy/scipy and Blaze. > > So you are absolute to say that some people migrate to dynamic > languages not just for dynamic types and is also to say that people > stick with C++ and C not because of static types. If that was the case > python would not implement optional static types and C++ would not > implement generics. > > The important thing to note here is that we no longer at 80 and 90s , > nowdays you can combine any language with anything else and the vast > majority of projects are written in multiple languages. > > I dont agree with the remark "Smalltalk and Lisp were right all along" > , obviously they were not because the entire world would have been > using smalltalk and lisp which we dont. To claim so is to try to > simplify coding and with every simplification it loses a part of the > truth. > > On Wed, Jan 20, 2016 at 5:57 PM Martin BÃ¤hr > <mbaehr(a)email.archlab.tuwien.ac.at > <mailto:mbaehr@email.archlab.tuwien.ac.at>> wrote: > > Excerpts from Dimitris Chloupis's message of 2016-01-20 12:36:37 > +0100: > > we have witnessed 3 great migrations of coders > > 1) The migration from Assembly to C/C++ and other high level > languages > > 2) The migration from C++ as the dominant force of coding to Java > > 3) The migration from static types languages to dynamic typed > languages > > that's a great observation! and you are right, dynamic typed > languages have won > and smalltalk and lisp had it right all along. > > > On the matter of python getting optional static typing I can say > this and > > predict this, static type will never become anywhere as big for > python as > > generic types are in static type languages and I say that > because I have a > > good understanding of the python culture. > > that's a good point too. what i am interested in is the fact that > having types > available in these languages, research can finally look for > conclusive evidence > of how much advantage types really give, because all other > differences between > eg python and c++ are eliminated. > > i simply do not believe that any findings about types, by > comparing python with > c++ is valid because they are such different beasts of languages. > > greetings, martin. > > -- > eKita - the online platform for your entire > academic life > -- > chief engineer eKita.co > pike programmer pike.lysator.liu.se <http://pike.lysator.liu.se> > caudium.net <http://caudium.net> societyserver.org > <http://societyserver.org> > secretary beijinglug.org <http://beijinglug.org> > mentor fossasia.org <http://fossasia.org> > foresight developer foresightlinux.org <http://foresightlinux.org> > realss.com <http://realss.com> > unix sysadmin > Martin BÃ¤hr working in china http://societyserver.org/mbaehr/ >

Jan. 20, 2016

Re: [Pharo-users] Use cases for methods with optional parameters

by Dimitris Chloupis

it would certainly save time from navigating through methods that more or less do the same thing. And of course dummy methods that they are there just to facilitate for less arguments. On Wed, Jan 20, 2016 at 7:42 PM Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > Le 20/01/2016 16:08, Damien Cassou a Ã©crit : > > Hi, > > > > I would like to study the impact of adding optional parameters to > > keyword methods in Pharo. The goal of optional parameters is to > > facilitate the implementation of methods where some parameters are > > optional. For example, Seaside has: > > > > WAComponent>>request: aRequestString label: aLabelString > > default: aDefaultString onAnswer: aBlock > > > > ... > > > > This method of 4 arguments has only 1 required argument (aRequestString) > > and 3 optional ones. In the current implementation, this results in 7 > > additional methods that only delegate directly or indirectly to the one > > above: > > > > - request: > > - request:default: > > - request:default:onAnswer: > > - request:label: > > - request:label:default: > > - request:label:onAnswer: > > - request:onAnswer: > > > > Before starting to implement anything, I need to know if it makes sense. > > If you want to help me, please send me all the use cases you have by > > giving me: > > > > - the library name (and URL if not in Catalog), or "pharo" if it's in > > Pharo > > - the class where this happens > > - the range of selectors that make sense > > > > For the example above, this would be: > > > > - Seaside > > - WAComponent > > - request:* > > > > > > Thank you very much > > > > Hi Damien, > > There is a lot of optional parameters in the UIManager. > > Package: UIManager (pharo) > > Classes: UIManager and subclasses > > Selectors: > > - chooseFrom:* > - reguest:* > - â¦ > > Almost all the methods have optional parameters. > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France > >

Jan. 20, 2016

Re: [Pharo-users] Use cases for methods with optional parameters

by Cyril Ferlicot D.

Le 20/01/2016 16:08, Damien Cassou a Ã©crit : > Hi, > > I would like to study the impact of adding optional parameters to > keyword methods in Pharo. The goal of optional parameters is to > facilitate the implementation of methods where some parameters are > optional. For example, Seaside has: > > WAComponent>>request: aRequestString label: aLabelString > default: aDefaultString onAnswer: aBlock > > ... > > This method of 4 arguments has only 1 required argument (aRequestString) > and 3 optional ones. In the current implementation, this results in 7 > additional methods that only delegate directly or indirectly to the one > above: > > - request: > - request:default: > - request:default:onAnswer: > - request:label: > - request:label:default: > - request:label:onAnswer: > - request:onAnswer: > > Before starting to implement anything, I need to know if it makes sense. > If you want to help me, please send me all the use cases you have by > giving me: > > - the library name (and URL if not in Catalog), or "pharo" if it's in > Pharo > - the class where this happens > - the range of selectors that make sense > > For the example above, this would be: > > - Seaside > - WAComponent > - request:* > > > Thank you very much > Hi Damien, There is a lot of optional parameters in the UIManager. Package: UIManager (pharo) Classes: UIManager and subclasses Selectors: - chooseFrom:* - reguest:* - â¦ Almost all the methods have optional parameters. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Jan. 20, 2016

Re: [Pharo-users] Use cases for methods with optional parameters

by Esteban A. Maringolo

2016-01-20 14:01 GMT-03:00 Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net>: > Hi, > > As a newbie, without a clear idea of where to apply this specifically I can > say that seems pretty interesting. I have methods with several parameters > (may be product of my newbie code), but making them optional seems an idea > worthy to explore. > > Cheers, > In a pure object oriented approach, if you have a lot of varying parameters is a sign that you might need to reify the parameters as a first class object, i.e. "SomethingParameters" class or similar, then instead of passing 1...n objects that will work as parameters you only pass one object, aSomethingParameters. Of course it adds more friction to something that maybe the language could provide, but in Smalltalk everything is explicit. I would be interested in the use cases and how to deal with "undefined" arguments, will they be nil or other kind of undefined object? Regards! Esteban A. Maringolo

Jan. 20, 2016

Re: [Pharo-users] Updating a project and NIL class variables

by Henrik Nergaard

âThe warning is: this only happens when the *source* code of the #initialize methods changes. So sometimes, you will have to touch that method to force it.â Perhaps there should be an overload able method that decides whether or not to initialize the class, such that classes relying on reinitializing every time a change is merged, can do this by simply answering true? From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Dimitris Chloupis Sent: Wednesday, January 20, 2016 3:47 PM To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] Updating a project and NIL class variables no apologies owed, I just asked because I want to make sure Pharo wont do anything weird behind my back :) On Wed, Jan 20, 2016 at 4:39 PM Sven Van Caekenberghe <sven(a)stfx.eu<mailto:sven@stfx.eu>> wrote: > On 20 Jan 2016, at 15:34, Dimitris Chloupis <kilon.alios(a)gmail.com<mailto:kilon.alios@gmail.com>> wrote: > > Thank you for the info but I think I did not make myself clear because you say "remain nil" > > Ok Imagine a class SomeClass and that class has a variable we will call SomeVariable, class variable that is > , there is no class initialize method, now that class has a method that is eventually called , > someMethod > > SomeVariable ifNil: [ SomeVariable := 'hello world'] > > so when I decide to update this class via metacello loading the latest version from github , SomeVariable will have the value 'hello world' > > My question is , will SomeVariable after I do the update revert back to nil or stay 'hello world' ? > > If your answer is no, and it stays 'hello world' then yes i need an initialize method and call it at update time. Argh, I should have said: keeps it value, will not revert to nil. Sorry for the confusion ! > On Wed, Jan 20, 2016 at 2:54 PM Sven Van Caekenberghe <sven(a)stfx.eu<mailto:sven@stfx.eu>> wrote: > They remain nil. > > That is why #initialize on the class side is needed. > > You can call that explicitly in a post load script, or rely on the class loading mechanism that normally calls #initialize automatically when loading a class. The warning is: this only happens when the *source* code of the #initialize methods changes. So sometimes, you will have to touch that method to force it. > > I hope that makes sense. > > See MCMethodDefinition>>#postloadOver: > > > On 20 Jan 2016, at 13:41, Dimitris Chloupis <kilon.alios(a)gmail.com<mailto:kilon.alios@gmail.com>> wrote: > > > > So my question is this , I have a class with nil variables that are lazy initialised only when needed the first time and of course they keep their values from there on. > > > > Lets say I get the latest update from github via metacello over an older update that I already have inside the image , do those variables revert back to nil values ? or do they keep their values as they are ? > >

Jan. 20, 2016

Re: [Pharo-users] Use cases for methods with optional parameters

by Offray Vladimir Luna CÃ¡rdenas

Hi, As a newbie, without a clear idea of where to apply this specifically I can say that seems pretty interesting. I have methods with several parameters (may be product of my newbie code), but making them optional seems an idea worthy to explore. Cheers, Offray On 20/01/16 10:08, Damien Cassou wrote: > Hi, > > I would like to study the impact of adding optional parameters to > keyword methods in Pharo. The goal of optional parameters is to > facilitate the implementation of methods where some parameters are > optional. For example, Seaside has: > > WAComponent>>request: aRequestString label: aLabelString > default: aDefaultString onAnswer: aBlock > > ... > > This method of 4 arguments has only 1 required argument (aRequestString) > and 3 optional ones. In the current implementation, this results in 7 > additional methods that only delegate directly or indirectly to the one > above: > > - request: > - request:default: > - request:default:onAnswer: > - request:label: > - request:label:default: > - request:label:onAnswer: > - request:onAnswer: > > Before starting to implement anything, I need to know if it makes sense. > If you want to help me, please send me all the use cases you have by > giving me: > > - the library name (and URL if not in Catalog), or "pharo" if it's in > Pharo > - the class where this happens > - the range of selectors that make sense > > For the example above, this would be: > > - Seaside > - WAComponent > - request:* > > > Thank you very much >

Jan. 20, 2016