- Pharo-users - lists.pharo.org

Re: [Pharo-users] About Traits

by Hilaire

Hi Julien, Le 22/04/2016 16:45, Julien Delplanque a Ã©crit : > Hello, > > I have a question about Trait. > > Is it ok, in the design point of view, to use them to force an object to > implement an interface? Why not using a parent abstract class for that, with required method answering #subclassResponsability? Then from your tests in subclasses, you check self shouldnt: [instance toto] raise: SubclassResponsabilty > Like that it would be possible to check (via an #assert: for example) if > a class provides the interface required. > > I read some things I found on the net about Traits and already used > TComparable but I never created one myself and I am not sure to > understand this concept entirely. With Trait you add behavior to a class. TComparable adds behavior to your class, your instance are then comparable. > > > Thanks in advance! > > Julien > -- Dr. Geo http://drgeo.eu

April 22, 2016

About Traits

by Julien Delplanque

Hello, I have a question about Trait. Is it ok, in the design point of view, to use them to force an object to implement an interface? Like that it would be possible to check (via an #assert: for example) if a class provides the interface required. I read some things I found on the net about Traits and already used TComparable but I never created one myself and I am not sure to understand this concept entirely. Thanks in advance! Julien

April 22, 2016

Re: [Pharo-users] ensureCreateFile

by Valentin Ryckewaert

For me ensureCreateFolder is made to be sure the folder is created, if you make '/home/a/b/c/d' with a b c d not existing it will create all of them. ensureCreateFile should do the same thing no ? 2016-04-21 13:19 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > because it's like this > > ensureCreateFolder : create the folder structure if necessary > ensureCreateFile : create the file if necessary > > I really don't see any gain from changing existing behavior and > introducing potential problems. > If I ask for file to be created, I don't expect that the system will > suddenly start creating folders, that's a unintentional side effect. > If you need it for your convenience, then it's dead-easy to implement > without breaking existing stuff. > > > On Thu, Apr 21, 2016 at 10:35 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> 2016-04-21 9:55 GMT+02:00 Valentin Ryckewaert < >> valentin.ryckewaert(a)gmail.com>: >> >>> Yes but why ensureCreateFile then ? >>> Why don't we juste create a message createFile as there is createFolder ? >>> createFolder : create the folder >>> createFile : create the file >>> >>> ensureCreateFolder : create the folder and its parents if necessary >>> ensureCreateFile : create the file and its parents if necessary >>> >> >> +1 >> > >

April 22, 2016

Re: [Pharo-users] Trapping the Pharo window close event

by Dimitris Chloupis

sorry meant to say Pharo is not lazy coder friendly by nature. On Fri, Apr 22, 2016 at 10:03 AM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Just for the record I am in agreement as I think most of us are about > this. > > But.... > > I think as a community must make one thing clear > > Pharo is environment meant to be hacked. Its not always to do so but > similarly to Squeak, the goal here is to give developers and environment > that they can design and modify themselves with ease. At least a lot more > than other languages and this is where Pharo really excels. > > In the end Pharo does not tries to be the most popular thing out there, it > tries to fill a gap that others dont or cant. Sure we want to make Pharo > popular but making something that is a ready made solution is not our top > priority. Making something modifiable and direct so much more. > > I think its our responsibility to make this clear to newcomers. > > Or else people will wonder, why not use python, ruby or whatelse which > comes with sophisticated IDEs far more lazy friendly than Pharo. > > Pharo is definetly , by nature, lazy coder friendly. Its for coders that > like to design their own workflow. > > On Sat, Apr 16, 2016 at 1:51 PM kmo <voxkmp(a)gmail.com> wrote: > >> Well, my reply was rather tongue-in-cheek. I was mocking my own laziness >> and >> the laziness of developers like me. But really I have no problem in doing >> these things for myself. And I hope that soon I will be in a position to >> contribute to pharo myself. >> >> But overriding the close event is something any application developer is >> going to want to do. And every time you make a developer work harder than >> necessary to implement a basic feature you make the pharo platform less >> attractive. If you want more developers to use pharo you have to make >> basic >> things like this easy to do and easy to find out how to do. >> >> I do think that deployment of applications gets very little attention in >> pharo - yet it's a major issue of you want to make pharo a widely-used >> application platform. >> >> I'm not the only lazy developer, you know . >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Trapping-the-Pharo-window-close-event-tp4890079p48902… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >>

April 22, 2016

Re: [Pharo-users] Trapping the Pharo window close event

by Dimitris Chloupis

Just for the record I am in agreement as I think most of us are about this. But.... I think as a community must make one thing clear Pharo is environment meant to be hacked. Its not always to do so but similarly to Squeak, the goal here is to give developers and environment that they can design and modify themselves with ease. At least a lot more than other languages and this is where Pharo really excels. In the end Pharo does not tries to be the most popular thing out there, it tries to fill a gap that others dont or cant. Sure we want to make Pharo popular but making something that is a ready made solution is not our top priority. Making something modifiable and direct so much more. I think its our responsibility to make this clear to newcomers. Or else people will wonder, why not use python, ruby or whatelse which comes with sophisticated IDEs far more lazy friendly than Pharo. Pharo is definetly , by nature, lazy coder friendly. Its for coders that like to design their own workflow. On Sat, Apr 16, 2016 at 1:51 PM kmo <voxkmp(a)gmail.com> wrote: > Well, my reply was rather tongue-in-cheek. I was mocking my own laziness > and > the laziness of developers like me. But really I have no problem in doing > these things for myself. And I hope that soon I will be in a position to > contribute to pharo myself. > > But overriding the close event is something any application developer is > going to want to do. And every time you make a developer work harder than > necessary to implement a basic feature you make the pharo platform less > attractive. If you want more developers to use pharo you have to make basic > things like this easy to do and easy to find out how to do. > > I do think that deployment of applications gets very little attention in > pharo - yet it's a major issue of you want to make pharo a widely-used > application platform. > > I'm not the only lazy developer, you know . > > > > -- > View this message in context: > http://forum.world.st/Trapping-the-Pharo-window-close-event-tp4890079p48902… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

April 22, 2016

Re: [Pharo-users] Trapping the Pharo window close event

by stepharo

Le 16/4/16 12:18, kmo a Ã©crit : > Well, my reply was rather tongue-in-cheek. I was mocking my own laziness and > the laziness of developers like me. But really I have no problem in doing > these things for myself. And I hope that soon I will be in a position to > contribute to pharo myself. But you are :) 30 min a week is enough :) > > But overriding the close event is something any application developer is > going to want to do. And every time you make a developer work harder than > necessary to implement a basic feature you make the pharo platform less > attractive. If you want more developers to use pharo you have to make basic > things like this easy to do and easy to find out how to do. We know that. Now I will not give the HUGE list of the things we are working on and that default developers are in need: - good file library - good list widget - FFI - decent texteditor - a compiler :) - ... > > I do think that deployment of applications gets very little attention in > pharo - yet it's a major issue of you want to make pharo a widely-used > application platform. Indeed. We started to push that when damien worked on the launcher and we should continue. > > I'm not the only lazy developer, you know . > > > > -- > View this message in context: http://forum.world.st/Trapping-the-Pharo-window-close-event-tp4890079p48902… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

April 22, 2016

Re: [Pharo-users] Trapping the Pharo window close event

by stepharo

Le 16/4/16 11:33, kmo a Ã©crit : > /Pharo is yours, so you can add it. :)/ > > Yes, but I don't want to add it. I expect it to be there out of the box. So you believe either is modern slavery or magic auto generation :D Seriously if you that need it are not ready to invest 30 min why me that does not need it should do it? Do you know what is free open-source software? > I think it's quite enough work for me to add my own code on window close. I > don't want to have to write the framework for doing it as well. > > > > -- > View this message in context: http://forum.world.st/Trapping-the-Pharo-window-close-event-tp4890079p48902… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

April 22, 2016

Re: [Pharo-users] Trapping the Pharo window close event

by stepharo

My point is that it is a proof that a library is not good when it forces users to redefined core code. Stef Le 15/4/16 23:06, Peter UhnÃ¡k a Ã©crit : > > I did not really get it. Now I have the impression that changing > the method definition shows that Pharo does not > offer the correct possibility. > Am I correct? > > > I disagree. Closing the window should not decide on it's own whether > the session should be saved. Asking the user is the right thing. > > The ideal thing would be to not ask if nothing has happened... but > that's impossible, this is a live system, not a text editor. > > Peter

April 22, 2016

Re: [Pharo-users] Tabular ODS import

by John Pfersich

> On Apr 20, 2016, at 23:55, Alistair Grant <akgrant0710(a)gmail.com> wrote: > >> On Wed, Apr 20, 2016 at 11:43:19PM +0200, Cyril Ferlicot D. wrote: >> Le 20/04/2016 22:47, Alistair Grant a Ã©crit : >>> So, time to learn more about Monticello... Reading the Updated PbE is >>> helpful, however I did notice one thing which doesn't match my >>> experience. On page 150 it is discussing how you can't lose code... >>> >>> "This is because all of the code that you executed is saved in the >>> .changes file. All of it! This includes one liners that you evaluate in >>> a workspace, as well as code that you add to a class while programming." >>> >>> Should "workspace" be changed to "playground"? >> >> Yes, can you open an issue please? :) >> >> https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues > > Issue 164: > https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues/164 > > > >>> My experience has been that code evaluated in the playground is *not* >>> saved to the changes file (Pharo 4.0 and 5.0). Is there a way to tell >>> Pharo to save evaluated code to the changes file? (I admit to being >>> lazy and not trying to figure this one out myself yet). >> >> All the *compiled* code is save. The playgroud is for playing, so it is >> not save in the change file. But the playground should save the code >> and you have a little menu to select your last scripts. >> >> http://puu.sh/opMd9/a823c07bf9.png >> >> If you use several times the same code you can also give a name to the >> tab (2 click on "Page") and after you can save the playground code. Via >> the spotter you can use the name of the tab to get a playground with the >> code. > > This sounds great, but I can't reproduce it. Would you mind clarifying > what you mean by "2 click on Page"? I tried clicking on the various > buttons, and clicking action-clicking, and middle buttong click on the > tab name ("Page"), without success (Pharo 5.0 50702). I think you want to double click on "Page". At least it works on Mac OSX and Pharo 5. > > >>> Finally, in Section 8.2 on versions of a method, my impression from >>> reading the section was that it would always display all versions of a >>> method, i.e. I have 24 versions of a package in my package cache, so >>> expected to see each modification to each method in the package. >>> However because I had switched to a new image and loaded the newest >>> package, only the latest version was shown. >> >> In the setting you can change the package-cache location to use always >> the same location even when you change of image. If the book is not >> clear can you copy/paste your mail into a github issue please? To not >> lose this feedback :) > > Issue 165: > https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues/165 > > > If I get time I'll also make the suggested changes and issue a pull > request. > > Thanks! > Alistair > >

April 22, 2016

Re: [Pharo-users] remove unused variables

by Johan Fabry

This was changed somewhere in November by Marcus and Miguel, and it was intentional, as part of the work on annotations on the AST that enabled breakpoints. (Breakpoints use the same highlighting mechanism). > On Apr 21, 2016, at 18:52, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > The editor used to inform when there was an unused local variable and offered to remove it. > > Is it possible to get this behavior back, or is it a feature regression with the "new" (this changed some time ago) editor? > > Thanks, > Peter ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

April 22, 2016