June 2020 - Pharo-users - lists.pharo.org

[ANN] Launchpad v3.0.0 [v3.0.0] released!

by Buenos Aires Smalltalk

June 29, 2020

Re: [Pharo-users] [ANN] What are reasons NOT to use Smalltalk?

by gettimothy

Hi I concur on the documentation problem. I concur that there is plenty of documentation, but finding it is a chore. I have two side projects I have started. Doc atÂ http://www.squeaksource.com/@FICALqrUmxQTIHgr/ul4_-exCAnd SeasideDoc (which I started before Doc)Â Â http://www.squeaksource.com/@FICALqrUmxQTIHgr/zwF3AJHc I expect that I will develop Doc completely before refactoring SeasideDoc to sit on top of it. The core ideas are: 1. That documentation should be available in-image in familiar terms--by sending messages to "stuff" 2. The documentation should be VERY EASY to add to (unlike the HelpBrowser, which ,imho, is coding, not documenting). 3. StackExchange style commenting with upvotes, priority. 4. Doc saves to a normal repository squeaksource or however pharo does its stuff, and hence, evolves with the image. 5. ?? this one is a stickler. should documentation be tightly bound with the Objects per Class comment style? or should it exist symbiotically? I think the latter. If so, what is the best design pattern(s) to facilitate that. Regarding 1. ......by sending messages to "stuff" stuff is.. classes:Â Â Dictionary docÂ Â packages: PG3 doc frameworks: Seaside doc Â Â Â Â Â Â Â Â Â Â XTreams doc Design Patterns:Â Singleton doc Â Â Â Â Â Â Â Â Â Â Â Â Â Â Facade doc Â Â Â Â Â Â Â Â Â Â Â Â Â Â BigBallOfMud docÂ (j.k.) I think typical Gnu-Linux style "man" , "help" , "info" or "verbose" would be an incredibly useful tool in bridging the "how do I do foo" gap that Squeak certaintly has and I suspect Pharo does too. I am very busy with a PEG grammar development project, so this is back burner stuff for me. I post this in the hope that some guru will take over the project and make Pharo/Squeak/ (and other) Smalltalks the BEST documented systems on the internet. Cheers. tty ---- On Mon, 29 Jun 2020 10:08:29 -0400 TomaÅ¾ Turk <mailto:tomaz.turk@ef.uni-lj.si> wrote ---- Dear all, This thread is a bit old, but anyways: here are my two cents on the question 'What are reasons not to use Smalltalk'. Thanks, Horrido, to constantly promote these kind of discussions. I think that your polls are mixing very different reasons - for instance, we choose development tools in different settings: as a group, as a firm, as an individual -- and for different purposes - for one of the projects, for some projects, as a general orientation of a firm, a specific team, or an individual. So I don't respond to these polls since it would be hard to answer properly, and "all of the above" is probably useless to you. What struck me about Pharo is the beauty and simplicity of the language and environment - and its great community, of course! Despite the fact that I have to use other tools because of my habits, environment, colleagues, students, and customers, I keep running Pharo almost every day, testing the ideas - it became a habit. I think that the consortium is well aware of the important things to make Pharo a feasible toolset for serious development, like stability, the proper GUI support, and books.Â In my own experience, Pharo as a language is pretty mature. In every-day situation with Pharo I deal with small challenges like remembering how to change all spaces with hyphens in a String - as I do in other languages when I try to remember all the methods that are already made for me in a certain language/libraries. This is not a problem. The real challenge is somewhere else: it's the comprehension of all the packages that are needed for a full-size project, from persistence to GUI. When documentation is scarce you have to go more or less deep into the code which I often find quite challenging. Besides commentaries, it helps tremendously if developers would always use typed variables to indicate API, like properties: aDictionary or presentWith: aWAPresenter instead ofÂ properties: someProperties and presentWith: anObject It's true that Pharo is not among "strongly typed" languages, however we sometimes forget that typing is not just a technical thing to avoid run-time errors, but it also gives information to other developers what's going on in the code and who should be the receiver. In some packages I also miss the use of superclasses - you can see that a bunch of classes directly inherits from Object or some other general class, however they could be organized in a better inheritance hierarchies, thus additionaly explaining their common and individual behaviour.Â Both and many other concepts are nicely described in books Learning OOP and Pharo with Style. I know that we are always eager to develop the package and satisfied when it works - and then it's hard to find the time to tie up these little pieces. I hope I don't sound too patronizing - I'm the same myself. Years ago Borland made a breakthrough with Turbo Pascal and Turbo C. For both tools they prepared two sets of books: user manual and reference manual. Books about Pharo are very nice and helpful, they are user manuals. If all the crucial packages would respect typed variables and class hierarchies, we won't need reference manuals at all :-) So, yeah, I think that the tipping point for Pharo is the question of how much time a developer should use to rediscover the behaviour which is already there.Â Best wishes Tomaz

June 29, 2020

Re: [Pharo-users] [ANN] What are reasons NOT to use Smalltalk?

by TomaÅ¾ Turk

Dear all, This thread is a bit old, but anyways: here are my two cents on the question 'What are reasons not to use Smalltalk'. Thanks, Horrido, to constantly promote these kind of discussions. I think that your polls are mixing very different reasons - for instance, we choose development tools in different settings: as a group, as a firm, as an individual -- and for different purposes - for one of the projects, for some projects, as a general orientation of a firm, a specific team, or an individual. So I don't respond to these polls since it would be hard to answer properly, and "all of the above" is probably useless to you. What struck me about Pharo is the beauty and simplicity of the language and environment - and its great community, of course! Despite the fact that I have to use other tools because of my habits, environment, colleagues, students, and customers, I keep running Pharo almost every day, testing the ideas - it became a habit. I think that the consortium is well aware of the important things to make Pharo a feasible toolset for serious development, like stability, the proper GUI support, and books. In my own experience, Pharo as a language is pretty mature. In every-day situation with Pharo I deal with small challenges like remembering how to change all spaces with hyphens in a String - as I do in other languages when I try to remember all the methods that are already made for me in a certain language/libraries. This is not a problem. The real challenge is somewhere else: it's the comprehension of all the packages that are needed for a full-size project, from persistence to GUI. When documentation is scarce you have to go more or less deep into the code which I often find quite challenging. Besides commentaries, it helps tremendously if developers would always use typed variables to indicate API, like properties: aDictionary or presentWith: aWAPresenter instead of properties: someProperties and presentWith: anObject It's true that Pharo is not among "strongly typed" languages, however we sometimes forget that typing is not just a technical thing to avoid run-time errors, but it also gives information to other developers what's going on in the code and who should be the receiver. In some packages I also miss the use of superclasses - you can see that a bunch of classes directly inherits from Object or some other general class, however they could be organized in a better inheritance hierarchies, thus additionaly explaining their common and individual behaviour. Both and many other concepts are nicely described in books Learning OOP and Pharo with Style. I know that we are always eager to develop the package and satisfied when it works - and then it's hard to find the time to tie up these little pieces. I hope I don't sound too patronizing - I'm the same myself. Years ago Borland made a breakthrough with Turbo Pascal and Turbo C. For both tools they prepared two sets of books: user manual and reference manual. Books about Pharo are very nice and helpful, they are user manuals. If all the crucial packages would respect typed variables and class hierarchies, we won't need reference manuals at all :-) So, yeah, I think that the tipping point for Pharo is the question of how much time a developer should use to rediscover the behaviour which is already there. Best wishes Tomaz

June 29, 2020

How to Create a Form with button

by shawon58

Hello I am new for Gui so i don't have idea how to create a form and place a button. If i press than button than it will run(like i press do it for execute) a method what i have created. Thanks -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 29, 2020

Re: [Pharo-users] STON question

by StÃ©phane Ducasse

> On 28 Jun 2020, at 18:22, Russ Whaley <whaley.russ(a)gmail.com> wrote: > > Stephane, > Thanks for the info on chrysal. I'm going to like going through the code to see how you solved some things. I created my own Configuration class that operates with a dictionary of keys the applications expect to use, and configuration values (paths, numerics, dates, strings...) but not blocks!... and save to and read from a STON file when a 'configs' instvar is referenced in the application. So far the only limitation I've come into is saving blocks, but admittedly I'm building it out as I need it. > > Looking forward to reviewing chrysal! Chrysal is used to simplify the hell of pillar configuration. Now I just used it in this context. I thought about it from a point of view of a non pharoer. So I have basic types (boolean, string, numbers) + files and sequence and composite. > > Thanks, > Russ > > On Sun, Jun 28, 2020 at 6:25 AM StÃ©phane Ducasse <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: > Hi russ, > > I do not if you know but based on Ston I built chrysal > to manage applications configuration: > > https://github.com/ducasse/chrysal <https://github.com/ducasse/chrysal> > > The basic idea is that you describe the possible fields of your configuration (i.e. how user can edit JSON files) and > it generates a converter from STON to your pharo objects. > You ship just the converter and its textual description so that you understand what you did. > > But this is probably not what you need but more a textual serializer. > > S. > > >> On 27 Jun 2020, at 16:07, Russ Whaley <whaley.russ(a)gmail.com <mailto:whaley.russ@gmail.com>> wrote: >> >> Good morning all from stormy Ohio/USA. Hope everyone is well and sheltering effectively from COVID, etc. >> >> I have a STON question. FIrst off, I LOVE STON. It has been the answer to my (minimal) persistence needs. I'm writing two different applications, both of which I hope to distribute someday, and I struggled with what would work to save configurations, templates, status, etc. STON was the answer for me - it's very easy to install and simple to use. >> >> But as I add the next feature/function in my code - sort blocks - as soon as I tried to save them (a collection of them in an instvar)... I get an error on the writeToSTON, and the target file is now corrupt - at the point where it tried to write the blocks. I have looked in the documentation and it plainly states the version I'm using does not yet address blocks - but I was hoping someone out there has developed a workaround, or perhaps has STON been updated to handle blocks? >> >> I could make the jump to a more sophisticated storage mechanism (i.e. Fuel?), but I'd rather spend my time working on features and figuring out the Spec2 GUI. :) >> >> Any advice is welcome and appreciated. >> >> Thanks! >> Russ >> >> -- >> Russ Whaley >> whaley.russ(a)gmail.com <mailto:whaley.russ@gmail.com> > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> / http://www.pharo.org <http://www.pharo.org/> > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > > > -- > Russ Whaley > whaley.russ(a)gmail.com <mailto:whaley.russ@gmail.com> -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

June 28, 2020

Re: [Pharo-users] STON question

by Russ Whaley

Stephane, Thanks for the info on chrysal. I'm going to like going through the code to see how you solved some things. I created my own Configuration class that operates with a dictionary of keys the applications expect to use, and configuration values (paths, numerics, dates, strings...) but not blocks!... and save to and read from a STON file when a 'configs' instvar is referenced in the application. So far the only limitation I've come into is saving blocks, but admittedly I'm building it out as I need it. Looking forward to reviewing chrysal! Thanks, Russ On Sun, Jun 28, 2020 at 6:25 AM StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi russ, > > I do not if you know but based on Ston I built chrysal > to manage applications configuration: > > https://github.com/ducasse/chrysal > > The basic idea is that you describe the possible fields of your > configuration (i.e. how user can edit JSON files) and > it generates a converter from STON to your pharo objects. > You ship just the converter and its textual description so that you > understand what you did. > > But this is probably not what you need but more a textual serializer. > > S. > > > On 27 Jun 2020, at 16:07, Russ Whaley <whaley.russ(a)gmail.com> wrote: > > Good morning all from stormy Ohio/USA. Hope everyone is well and > sheltering effectively from COVID, etc. > > I have a STON question. FIrst off, I LOVE STON. It has been the answer > to my (minimal) persistence needs. I'm writing two different applications, > both of which I hope to distribute someday, and I struggled with what would > work to save configurations, templates, status, etc. STON was the answer > for me - it's very easy to install and simple to use. > > But as I add the next feature/function in my code - sort blocks - as soon > as I tried to save them (a collection of them in an instvar)... I get an > error on the writeToSTON, and the target file is now corrupt - at the point > where it tried to write the blocks. I have looked in the documentation and > it plainly states the version I'm using does not yet address blocks - but I > was hoping someone out there has developed a workaround, or perhaps has > STON been updated to handle blocks? > > I could make the jump to a more sophisticated storage mechanism (i.e. > Fuel?), but I'd rather spend my time working on features and figuring out > the Spec2 GUI. :) > > Any advice is welcome and appreciated. > > Thanks! > Russ > > -- > Russ Whaley > whaley.russ(a)gmail.com > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > -- Russ Whaley whaley.russ(a)gmail.com

June 28, 2020

Re: [Pharo-users] How to set path as a variable

by Christopher Fuhrman

> > Then you can add your directory to it (note that I put a semicolon for > path separator in Windows): > > modifiedPath := 'D:\DEV_FreeCAD\build\bin\;' + path. My apologies (I have been coding too much JavaScript lately) - this should have been: modifiedPath := 'D:\DEV_FreeCAD\build\bin\;' , path. Cheers, On Sun, 28 Jun 2020 at 11:16, Christopher Fuhrman < christopher.fuhrman(a)etsmtl.ca> wrote: > Hello, > > Why not use the PATH environment variable in Windows to do what you want? > I deal with setting variables used with LibC in my blog entry at > https://fuhrmanator.github.io/2019/03/16/LibC-Pharo-experiments.html > > You can get PATH by using: > > path := OSEnvironment current getEnv: 'PATH'. > > Then you can add your directory to it (note that I put a semicolon for > path separator in Windows): > > modifiedPath := 'D:\DEV_FreeCAD\build\bin\;' + path. > > Then you have to set the variable in the system: > > result := OSEnvironment current setEnv: 'PATH' value: modifiedPath. > > You should probably get (again) the variable PATH (as above) to make sure > the path was set correctly. > > Then just do: > > result := LibC runCommand: 'makebox.step'. > > Let us know if it works for you. > > Cheers! > > On Sun, 28 Jun 2020 at 09:03, shawon58 <shawonhoque58(a)gmail.com> wrote: > >> In pharo class side , i am creating class side method like as >> /*makebox >> LibC system: 'D:\DEV_FreeCAD\build\bin\makebox.step'*/ >> SO i want to set /D:\DEV_FreeCAD\build\bin\ / as a variable like path >> than i >> can write like as >> *LibC system: 'path\makebox.step'* >> >> how to do that, if anyone have idea please share the idea with me. >> >> Thanks for your help >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> > > -- > Christopher Fuhrman, P.Eng., PhD > > *Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de > l'informationÃTS (Ãcole de technologie supÃ©rieure)* > > http://profs.etsmtl.ca/cfuhrman > +1 514 396 8638 > *L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec* > -- Christopher Fuhrman, P.Eng., PhD *Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de l'informationÃTS (Ãcole de technologie supÃ©rieure)* http://profs.etsmtl.ca/cfuhrman +1 514 396 8638 *L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec*

June 28, 2020

Re: [Pharo-users] How to set path as a variable

by Christopher Fuhrman

Hello, Why not use the PATH environment variable in Windows to do what you want? I deal with setting variables used with LibC in my blog entry at https://fuhrmanator.github.io/2019/03/16/LibC-Pharo-experiments.html You can get PATH by using: path := OSEnvironment current getEnv: 'PATH'. Then you can add your directory to it (note that I put a semicolon for path separator in Windows): modifiedPath := 'D:\DEV_FreeCAD\build\bin\;' + path. Then you have to set the variable in the system: result := OSEnvironment current setEnv: 'PATH' value: modifiedPath. You should probably get (again) the variable PATH (as above) to make sure the path was set correctly. Then just do: result := LibC runCommand: 'makebox.step'. Let us know if it works for you. Cheers! On Sun, 28 Jun 2020 at 09:03, shawon58 <shawonhoque58(a)gmail.com> wrote: > In pharo class side , i am creating class side method like as > /*makebox > LibC system: 'D:\DEV_FreeCAD\build\bin\makebox.step'*/ > SO i want to set /D:\DEV_FreeCAD\build\bin\ / as a variable like path than > i > can write like as > *LibC system: 'path\makebox.step'* > > how to do that, if anyone have idea please share the idea with me. > > Thanks for your help > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > -- Christopher Fuhrman, P.Eng., PhD *Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de l'informationÃTS (Ãcole de technologie supÃ©rieure)* http://profs.etsmtl.ca/cfuhrman +1 514 396 8638 *L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec*

June 28, 2020

How to set path as a variable

by shawon58

In pharo class side , i am creating class side method like as /*makebox LibC system: 'D:\DEV_FreeCAD\build\bin\makebox.step'*/ SO i want to set /D:\DEV_FreeCAD\build\bin\ / as a variable like path than i can write like as *LibC system: 'path\makebox.step'* how to do that, if anyone have idea please share the idea with me. Thanks for your help -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 28, 2020

Re: [Pharo-users] STON question

by StÃ©phane Ducasse

> On 27 Jun 2020, at 16:58, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Russ, > > The limitation of STON not being capable of serialising a block closure still stands and will probably not change very soon (it open up the whole language to be written out). > > You can work around this though, with sort functions for example. > > Here is an example: > > { 1->#one. 3->#three. 2->#two } sorted: (STON fromString: (STON toStringPretty: #key ascending)). > > SortFunctions are really cool BTW (they can handles nil values elegantly). > > Sven Sven do you think that we should have a little section on this question in STON chapter. S

June 28, 2020