July 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Deprecator

by Sean P. DeNigris

camille teruel wrote > This debugger has a little 'Rewrite' button O.M.G. That is fantastic! Let's get this into core quickly!! Thanks :) Regarding the name... while I get the value of cool, mysterious-sounding names for public-facing (or maybe at minimum cross-platform) projects, I'd rather these small tools that we often make be named as intention-revealing as possible. I've felt at times some unnecessary complication translating #(starfish shovel sandcastle) -> #(Socket Debugger Array) ;-p ----- Cheers, Sean -- View this message in context: http://forum.world.st/Deprecator-tp4769844p4769880.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 24, 2014

Re: [Pharo-users] Commandline

by Esteban Lorenzano

On 24 Jul 2014, at 16:07, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > Norbert, > > I've just recently made the decision to start using Pharo3.0 to do all of the heavy lifting for my GsDevKit project[1] shell scripts. > > I use boilerplate bash code to setup the environment[2] and then call Pharo CommandLineHandler[3] to do the real work ... > > I embed the script repository[4] in the project, so the script code matches the directory structure and I build the command line pharo image[5] as part of my installation. > > I've been pretty pleased with the results, too. It's pretty straightforward to run the scripts from within an interactive Pharo for debugging and it beats the heck out of trying to do *simple things* with bash... > > My only wish is that CommandLine had better getopts support - I have a posix getopts commandline parser implementation that iI use for tODE that I'd be willing to share ... hint hint:). and we would be glad to integrate, if is somewhere :) Esteban > > Dale > > [1] https://github.com/GsDevKit/gsDevKitHome#open-source-development-kit-for-ge… > [2] https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createStone > [3] https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createStone#L78-82 > [4] https://github.com/GsDevKit/gsDevKitHome/tree/master/repository > [5] https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createTodeImage#L6… > > > On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > What are you using to do jobs on the commandline. I'm sick of doing bash and sed,perl,jq,... stuff. What would be the quickest start when using a normal image? And what if I want to give coral a start. Does it work in 3.0? Best place to load stuff from? > > thanks, > > Norbert > > >

July 24, 2014

Re: [Pharo-users] Browse list of methods

by Mark Rizun

Thanks. That will do:) 2014-07-24 16:07 GMT+02:00 Camille Teruel <camille.teruel(a)gmail.com>: > > On 24 juil. 2014, at 16:02, Mark Rizun <mrizun(a)gmail.com> wrote: > > > Hi guys, > > > > If I have list of methods, how can I open a browser containing only this > > methods? > > There is MessageBrowser. > Look at the class side for the creating instances > For example you can do: > > (MessageBrowser on: { Object>>#copy } named: 'My Methods' autoSelect: > #copy) open > > Camille > > > Best, > > Mark > > > > > > > > -- > > View this message in context: > http://forum.world.st/Browse-list-of-methods-tp4769871.html > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > >

July 24, 2014

Re: [Pharo-users] Commandline

by Dale Henrichs

Norbert, I've just recently made the decision to start using Pharo3.0 to do all of the heavy lifting for my GsDevKit project[1] shell scripts. I use boilerplate bash code to setup the environment[2] and then call Pharo CommandLineHandler[3] to do the real work ... I embed the script repository[4] in the project, so the script code matches the directory structure and I build the command line pharo image[5] as part of my installation. I've been pretty pleased with the results, too. It's pretty straightforward to run the scripts from within an interactive Pharo for debugging and it beats the heck out of trying to do *simple things* with bash... My only wish is that CommandLine had better getopts support - I have a posix getopts commandline parser implementation that iI use for tODE that I'd be willing to share ... hint hint:). Dale [1] https://github.com/GsDevKit/gsDevKitHome#open-source-development-kit-for-ge… [2] https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createStone [3] https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createStone#L78-82 [4] https://github.com/GsDevKit/gsDevKitHome/tree/master/repository [5] https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createTodeImage#L6… On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > What are you using to do jobs on the commandline. I'm sick of doing bash > and sed,perl,jq,... stuff. What would be the quickest start when using a > normal image? And what if I want to give coral a start. Does it work in > 3.0? Best place to load stuff from? > > thanks, > > Norbert > > >

July 24, 2014

Re: [Pharo-users] Browse list of methods

by Camille Teruel

On 24 juil. 2014, at 16:02, Mark Rizun <mrizun(a)gmail.com> wrote: > Hi guys, > > If I have list of methods, how can I open a browser containing only this > methods? There is MessageBrowser. Look at the class side for the creating instances For example you can do: (MessageBrowser on: { Object>>#copy } named: 'My Methods' autoSelect: #copy) open Camille > Best, > Mark > > > > -- > View this message in context: http://forum.world.st/Browse-list-of-methods-tp4769871.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

July 24, 2014

Browse list of methods

by Mark Rizun

Hi guys, If I have list of methods, how can I open a browser containing only this methods? Best, Mark -- View this message in context: http://forum.world.st/Browse-list-of-methods-tp4769871.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 24, 2014

Re: [Pharo-users] Recommended Pharo image updating and Metacello commit policy

by Tudor Girba

Hi, I change my image at least once per day. Every single day. I have automatic jobs that create an up to date images the way I want them, and I simply take that one whenever I feel like it. This helps me push my code to a repository, and have any setup easily reconstruct-able. If a piece of code does not make it in even a playground repository, it is probably not worth having it around anyway. For me, it is a matter of principle. Cheers, Doru On Thu, Jul 24, 2014 at 3:17 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Peter, > > I and I guess most people, keep their working image for days to weeks. > After all, it is one of the main strengths to have a persistent environment > containing all you customisations, all code you loaded, your workspaces, in > essence, your world. > > That being said, you should keep all your important code in an MC > repository (at least in the package-cache, but better in a real repository, > maybe a private one). That way you know your code will survive an image > crash. > > When and if you want to upgrade, you can now do so. You have to decide if > the trouble is worth it. I always keep the old images, just in case. > > HTH, > > Sven > > PS: You can save workspaces to files, or use ScriptManager for multiple > ones. There also exists various solutions to move preferences and/or > settings around, YMMV. > > On 24 Jul 2014, at 14:58, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > Having ~month old pharo image I was wondering what is the recommended > way of updating it. Do I just delete everything and download a fresh one > every so often (daily?), do I load new changes through Monticello? Does > that upgrade the VM though? > > If the former what about local code I wrote but I don't want to loose or > haven't completely finished? Is it possible to export workspace content and > load it into fresh image? > > Do I just create local repository and commit there and once I am > satisfied with the results I push them up (to STHub/wherever)? Or should I > always push to remote repo even if the commits break the package (I would > assume that should be semi-guarded by creating ConfigurationOfMyProject)? I > am used to Git and I still can't wrap my head around this Monticello thing. > :( > > > > Thanks, > > Peter > > > -- www.tudorgirba.com "Every thing has its own flow"

July 24, 2014

Re: [Pharo-users] Recommended Pharo image updating and Metacello commit policy

by Sven Van Caekenberghe

Hi Peter, I and I guess most people, keep their working image for days to weeks. After all, it is one of the main strengths to have a persistent environment containing all you customisations, all code you loaded, your workspaces, in essence, your world. That being said, you should keep all your important code in an MC repository (at least in the package-cache, but better in a real repository, maybe a private one). That way you know your code will survive an image crash. When and if you want to upgrade, you can now do so. You have to decide if the trouble is worth it. I always keep the old images, just in case. HTH, Sven PS: You can save workspaces to files, or use ScriptManager for multiple ones. There also exists various solutions to move preferences and/or settings around, YMMV. On 24 Jul 2014, at 14:58, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Having ~month old pharo image I was wondering what is the recommended way of updating it. Do I just delete everything and download a fresh one every so often (daily?), do I load new changes through Monticello? Does that upgrade the VM though? > If the former what about local code I wrote but I don't want to loose or haven't completely finished? Is it possible to export workspace content and load it into fresh image? > Do I just create local repository and commit there and once I am satisfied with the results I push them up (to STHub/wherever)? Or should I always push to remote repo even if the commits break the package (I would assume that should be semi-guarded by creating ConfigurationOfMyProject)? I am used to Git and I still can't wrap my head around this Monticello thing. :( > > Thanks, > Peter

July 24, 2014

Recommended Pharo image updating and Metacello commit policy

by Peter UhnÃ¡k

Having ~month old pharo image I was wondering what is the recommended way of updating it. Do I just delete everything and download a fresh one every so often (daily?), do I load new changes through Monticello? Does that upgrade the VM though? If the former what about local code I wrote but I don't want to loose or haven't completely finished? Is it possible to export workspace content and load it into fresh image? Do I just create local repository and commit there and once I am satisfied with the results I push them up (to STHub/wherever)? Or should I always push to remote repo even if the commits break the package (I would assume that should be semi-guarded by creating ConfigurationOfMyProject)? I am used to Git and I still can't wrap my head around this Monticello thing. :( Thanks, Peter

July 24, 2014

Re: [Pharo-users] Commandline

by kilon alios

I don't know if my "Atlas" library could be of assistance here. Atlas will allow you to use python and python libraries from inside pharo via a socket bridge. I am very noob when it comes to terminal but I hear that python is very popular for command line stuff especially on linux and macos where it comes included. So if you run Atlas from headless pharo it should work and give you access to full power of python, but there are a few stuff I need to add to it. Of course the disadvantage here is that you still need to know python and its libraries. On Thu, Jul 24, 2014 at 2:52 PM, stepharo <stepharo(a)free.fr> wrote: > > What are you using to do jobs on the commandline. I'm sick of doing bash >> and sed,perl,jq,... stuff. >> > Me too. I dream about editing my pharo script in Pharo, deploying them > from pharo and debugging > them if necessary. > > What would be the quickest start when using a normal image? >> > passing a code snippet via the command line as described in the zeroconf > chapter. > > And what if I want to give coral a start. Does it work in 3.0? Best >> place to load stuff from? >> > > I agree with you. > Damien C made a lot of changes to make sure that we can run the image on > readonly folder. Because you want to > have a image in /usr/bin/ whatever and load your scripts. > > About coral I think that starting to use it is worth. Right you can launch > scripts and even define > classes. To me coral is orthogonal to the scripts. > > I was thinking that we would have a much better support for OSProcess (via > NB). > To me this is the most important point. Better OS integration. Having an > alternate syntax for methods is secondary or less priority. > > Stef > >

July 24, 2014