- Pharo-users - lists.pharo.org

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

Deprecator

by Camille Teruel

Hello Pharo users, I'm pleased to announce the release of Deprecator. It's a prototype of a small tool that permits you to deprecate method by annotating them with a <deprecated: ...> pragma. This pragma takes a rewrite expression as argument that specifies how to rewrite the message send to the deprecated method. If such a deprecated method is executed, a warning is thrown and a debugger opens. This debugger has a little 'Rewrite' button that permits to rewrite the sending method according to the rewrite expression and then resume the execution with the new rewritten sending method :) The implementation is a proof-of-concept and is a bit hacky here and there, but it works. Example: You have a class C with a method that you deprecate. Its rewrite expression tells that if it's executed as the result of a message send of the form: <receiver> deprecatedMethodArg1: <arg1> arg2: <arg2>, this message send should be rewritten to: <receiver> replacementMethodArg1: <arg2> arg2: <arg1>. Note you can change the order of arguments or even the receiver. C>>deprecatedMethodArg1: o1 arg2: o2 <deprecated: '`@receiver replacementMethodArg1: `@arg2 arg2: `@arg1'> ^ #deprecated C>>replacementMethodArg1: o1 arg2: o2 ^ #replacement C>>senderMethod ^ self deprecatedMethodArg1: 1 + 1 arg2: 2 + 2. Then if you execute C new senderMethod, and then click on the "Rewrite" button of the debugger, then sending method is rewritten to: C>>senderMethod ^ self replacementMethodArg1: 2 + 2 arg2: 1 + 1. and the result is #replacement. The repo is on sSmalltalkHub: MCHttpRepository location: 'http://smalltalkhub.com/mc/CamilleTeruel/Deprecator/main' user: '' password: '' I hope for comments, feature suggestions, code reviews, contributors, etc :) BTW, if you have a better name for this project let me know! For example, I thought about Ammonite because it's an extinct animal (analogy with deprecated) and it fits the sea naming theme. Cheers, Camille

July 24, 2014

Re: [Pharo-users] Commandline

by stepharo

> 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

Re: [Pharo-users] Commandline

by Bernat Romagosa

I've used GST in the past for simple scripting too. Worth a try! 2014-07-24 13:24 GMT+02:00 Robert Shiplett <grshiplett(a)gmail.com>: > I run server-side JavaScript but would not dream of using JS to do jobs ! > > Humour : for years the command-line params for VW Smalltalk were some kind > of unpublished hush-hush secret for build mavens and image-stripping gurus > on hp/ux servers. Not so for Gnu Smalltalk ;-) > > There is always APL ;-) > > > On 24 July 2014 07:37, 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 >> >> >> > -- Bernat Romagosa.

July 24, 2014

Re: [Pharo-users] Commandline

by Robert Shiplett

I run server-side JavaScript but would not dream of using JS to do jobs ! Humour : for years the command-line params for VW Smalltalk were some kind of unpublished hush-hush secret for build mavens and image-stripping gurus on hp/ux servers. Not so for Gnu Smalltalk ;-) There is always APL ;-) On 24 July 2014 07:37, 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] Commandline

by Robert Shiplett

Sick of sed and Perl ? There is fun in Object Icon and Rebol ( r3 or Red ) ( Icon, UNICON or pythonic Converge PL.) And I even use xcurl scripts for MIT Curl ( www.curl.com ) (now SCSK Curl at www.curlap.com ) But Object Icon has to be built at the command line ;-) I gave up on Io and have been neglecting Falcon PL The downside to Curl is that it used Regexp ; rebol Parse is such a treat ! ( PEG packrat equiv.) On 24 July 2014 07:37, 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

Commandline

by Norbert Hartl

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