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

Charter chapter under construction

by Alexandre Bergel

Dear All, Just to share the work on progress about a chapter on Charter. A charting library on top of Roassal. http://agilevisualization.com https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/0202-Charte… Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 15, 2014

Re: [Pharo-users] [Moose-dev] [ANN] Live Robot Programming

by Santiago Bragagnolo

Great Johan! Congrats for both of you :) 2014-08-14 22:37 GMT+02:00 Johan Fabry <jfabry(a)dcc.uchile.cl>: > > Aargh, copy-paste error. The Lego robot example is on Instagram of course > :-) > > http://instagram.com/p/pEhm0Oj837/ > > > On Aug 14, 2014, at 4:28 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > > Hi all, > > > > itâs with great joy that I can announce the project that my PhD student > Miguel and I have been working on recently: Live Robot Programming, or LRP > for short. > > > > LRP is a live programming language designed for the creation of the > behavior layer of robots. It is fundamentally a nested state machine > language built with robotics applications in mind, but it is not bound to a > specific robot middleware, API or OS. Have a look at one minute of LRP > programming to get an idea of what it is like: http://youtu.be/4Ma8ZapBUqA > > > > Live programming is fun, and live robot programming even more so, as it > brings all the advantages of live programming to programming a robot. You > get direct manipulation of a running robot, and thatâs just cool beyond > words. As an example of LRP on a robot, this guy was programmed in LRP: > http://youtu.be/4Ma8ZapBUqA Note that you can use LRP âjustâ for live > programming nested state machines as well. > > > > More information on LRP is available on its website: > http://pleiad.cl/LRP where you can also find download instructions. > > > > LRP is implemented in Pharo, and uses Roassal2 for the visualization of > its state machines. We currently can steer the Lego Mindstorms EV3 and ROS > robots, thanks to a small layer on top of the cool Pharo support that > Jannik, Luc, Santiago and Noury are implementing at Douai. I am going to > look into support for the Parrot AR.Drone 2.0esug in a few weeks. > > > > Miguel will be at ESUG next week (I cannot make it), and has a talk at > the IWST workshop about LRP, in the morning session. I am sure that he will > also be happy to give demos of LRP if you ask him to (but sadly without a > robot). > > > > All feedback is welcome, and â¦ have fun! > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > > > Johan Fabry - http://pleiad.cl/~jfabry > > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > >

Aug. 14, 2014

Re: [Pharo-users] A Slice

by Sven Van Caekenberghe

Another way, more technical way to say the same thing: a slice is an empty Monticello package which has a number of other packages as its so called requirements - loading the main slice package will then load the required packages. so it is a way to group modified packages. BTW, Monticello is a distributed version control system. On 14 Aug 2014, at 23:40, phil(a)highoctane.be wrote: > A slice is useful for packaging changes one does for fixing a bug. Slices can hold several packages at once. > > One can create a slice from monticello. > > Slices are then put into an inbox monticello repository. > > And referred to in the fogbugz issue. > > Check the issue procedure on the website. > > Now, you can do your own slices for othe reasons. > > HTH > Phil > Le 14 aoÃ»t 2014 22:53, "Ichiseki" <is076(a)outlook.com> a Ã©crit : > I've been reading some post that mention Slices. > What is a slice? and what's usefull for? > thank you > > Ichiro > > > > -- > View this message in context: http://forum.world.st/A-Slice-tp4773357.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Aug. 14, 2014

Re: [Pharo-users] A Slice

by phil＠highoctane.be

A slice is useful for packaging changes one does for fixing a bug. Slices can hold several packages at once. One can create a slice from monticello. Slices are then put into an inbox monticello repository. And referred to in the fogbugz issue. Check the issue procedure on the website. Now, you can do your own slices for othe reasons. HTH Phil Le 14 aoÃ»t 2014 22:53, "Ichiseki" <is076(a)outlook.com> a Ã©crit : > I've been reading some post that mention Slices. > What is a slice? and what's usefull for? > thank you > > Ichiro > > > > -- > View this message in context: http://forum.world.st/A-Slice-tp4773357.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > >

Aug. 14, 2014

A Slice

by Ichiseki

I've been reading some post that mention Slices. What is a slice? and what's usefull for? thank you Ichiro -- View this message in context: http://forum.world.st/A-Slice-tp4773357.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 14, 2014

Re: [Pharo-users] [Pharo-business] [Pharo-dev] [ANN] HelloPharo - webapp deployment tool

by Sven Van Caekenberghe

On 14 Aug 2014, at 22:40, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> wrote: > Ah ! I was also thinking about a cookie to keep user identity, I hate to re-login because of an expired session. I was looking for a good name, "login-token" sounds good :) It works pretty well in practice (this is a mobile app mostly), even if the Seaside session expires, your login survives and you are moved to some sensible state (but that has to be programmed explicitly). > Why do you keep it 14 days only ? Is there a reason ? I planned to make it valid much longer than that... Allowing a login to remain valid forever feels like a bad idea, but I guess the number is not necessarily fixed and should not be the same for everyone. Now, after 14 days not touching the web app from an open browser/tab you will have to do a new login, that is not that bad IMO. I would even say the UX says (implicitly) 'we closed your session for security reasons'. > On Thu, Aug 14, 2014 at 10:27 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 14 Aug 2014, at 15:21, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> wrote: > > > Good idea, I add monit as one of the next step. > > > > Load balancing is not supported at all. But we could change the nginx config file to load balance between two images. And maybe make something for Seaside and its state (sticky sessions?). I haven't done enough of this to actually take an informed decision. > > Here is some information on how I did it recently using nginx and Seaside: > > http://forum.world.st/Nginx-Load-Balancing-Experiences-td4750823.html > > The stickiness is by client IP. > > It is also possible to do route based stickiness in Seaside and using Zinc (see ZnServer>>#route:), but I know only how to do that with Apache 2 (it is a paying option for nginx sadly). > > Of course, in most cases you will have to do some session state sharing between instances. I used memcached for that. > > > I'll update the README to be more clear about what is done behind the scene. Showing the tree of directories created by HelloPharo will be worth a thousand words (especially if you've used capistrano before). > > > > > > On Thu, Aug 14, 2014 at 3:13 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 14 Aug 2014, at 13:08, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> wrote: > > > > > Oh, I forgot to mention Sven. He wrote the original http://stfx.eu/pharo-server/ > > > We basically stole all his Bash-fu to build the main script: > > > > > > https://github.com/fstephany/hello-pharo/blob/master/app > > > > > > Thanks a lot Sven! > > > > You're welcome, FranÃ§ois. BTW, I am still using that script for all my deploys. > > > > I didn't immediately see it, but does your solution include something for process monitoring and automatic restarts (like monit) and/or some basic load balancing ? In my experience the combination of these two makes for a more robust solution. Maybe that is the next step ;-) > > > > Sven > > > > > On Thu, Aug 14, 2014 at 1:02 PM, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> wrote: > > > Hello, > > > > > > At Ta MÃ¨re, we are used to deploy Ruby/Rails application with Heroku or on VPS with Capistrano. Almost everybody uses the same tools and techniques in the Rails community so deployment is quite easy once you grasp the process. > > > > > > The same process was quite frustrating with Pharo. To solve that, we've built HelloPharo. It is a tool to deploy small apps to a Linux VPS/VM. > > > > > > It is heavily inspired by Capistrano, it prones convention over configuration and it wants to be full stack (e.g., serve the assets, restart the processes). It is built with Ansible. > > > > > > We haven't released a fixed version yet but the tool starts to be in a good-enough shape to be shown. We want to grab some feedback and fix the most obvious limitations (see the README for more) before releasing version 0.1.0. > > > > > > If you or your company uses a well defined process to deploy pharo webapps, we are all ears. We think that having a canonical way to deploy simple apps is a must if we want to see wider Pharo adoption for small web companies. This process *must* be Unix friendly if we want to attract Python or Ruby people. Most of them are Devops anyway, the command line is their friend, NOT something they want to avoid. > > > > > > Pull requests (for code or instructions in the README) are more than welcome. The code and the documentation are MIT licensed. > > > > > > https://github.com/fstephany/hello-pharo/ > > > > > > Cheers, > > > Francois > > > > > > > > > > > _______________________________________________ > > Pharo-business mailing list > > Pharo-business(a)lists.pharo.org > > http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org > >

Aug. 14, 2014

Re: [Pharo-users] [ANN] HelloPharo - webapp deployment tool

by FranÃ§ois Stephany

Just sent it to the Seaside ML, thanks for mentioning it ;) On Thu, Aug 14, 2014 at 5:13 PM, stepharo <stepharo(a)free.fr> wrote: > > On 14/8/14 13:02, FranÃ§ois Stephany wrote: > >> Hello, >> >> At Ta MÃ¨re, we are used to deploy Ruby/Rails application with Heroku or >> on VPS with Capistrano. Almost everybody uses the same tools and techniques >> in the Rails community so deployment is quite easy once you grasp the >> process. >> >> The same process was quite frustrating with Pharo. To solve that, we've >> built HelloPharo. It is a tool to deploy small apps to a Linux VPS/VM. >> > > Excellent! > I love infrastructure. > Keep pushing that. > Did you announce it on the seaside mailing-list > > >> It is heavily inspired by Capistrano, it prones convention over >> configuration and it wants to be full stack (e.g., serve the assets, >> restart the processes). It is built with Ansible. >> >> We haven't released a fixed version yet but the tool starts to be in a >> good-enough shape to be shown. We want to grab some feedback and fix the >> most obvious limitations (see the README for more) before releasing version >> 0.1.0. >> >> If you or your company uses a well defined process to deploy pharo >> webapps, we are all ears. We think that having a canonical way to deploy >> simple apps is a must if we want to see wider Pharo adoption for small web >> companies. This process *must* be Unix friendly if we want to attract >> Python or Ruby people. Most of them are Devops anyway, the command line is >> their friend, NOT something they want to avoid. >> >> Pull requests (for code or instructions in the README) are more than >> welcome. The code and the documentation are MIT licensed. >> >> https://github.com/fstephany/hello-pharo/ >> >> Cheers, >> Francois >> > > >

Aug. 14, 2014

Re: [Pharo-users] [Pharo-business] [Pharo-dev] [ANN] HelloPharo - webapp deployment tool

by FranÃ§ois Stephany

Ah ! I was also thinking about a cookie to keep user identity, I hate to re-login because of an expired session. I was looking for a good name, "login-token" sounds good :) Why do you keep it 14 days only ? Is there a reason ? I planned to make it valid much longer than that... On Thu, Aug 14, 2014 at 10:27 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 14 Aug 2014, at 15:21, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> > wrote: > > > Good idea, I add monit as one of the next step. > > > > Load balancing is not supported at all. But we could change the nginx > config file to load balance between two images. And maybe make something > for Seaside and its state (sticky sessions?). I haven't done enough of this > to actually take an informed decision. > > Here is some information on how I did it recently using nginx and Seaside: > > http://forum.world.st/Nginx-Load-Balancing-Experiences-td4750823.html > > The stickiness is by client IP. > > It is also possible to do route based stickiness in Seaside and using Zinc > (see ZnServer>>#route:), but I know only how to do that with Apache 2 (it > is a paying option for nginx sadly). > > Of course, in most cases you will have to do some session state sharing > between instances. I used memcached for that. > > > I'll update the README to be more clear about what is done behind the > scene. Showing the tree of directories created by HelloPharo will be worth > a thousand words (especially if you've used capistrano before). > > > > > > On Thu, Aug 14, 2014 at 3:13 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > On 14 Aug 2014, at 13:08, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> > wrote: > > > > > Oh, I forgot to mention Sven. He wrote the original > http://stfx.eu/pharo-server/ > > > We basically stole all his Bash-fu to build the main script: > > > > > > https://github.com/fstephany/hello-pharo/blob/master/app > > > > > > Thanks a lot Sven! > > > > You're welcome, FranÃ§ois. BTW, I am still using that script for all my > deploys. > > > > I didn't immediately see it, but does your solution include something > for process monitoring and automatic restarts (like monit) and/or some > basic load balancing ? In my experience the combination of these two makes > for a more robust solution. Maybe that is the next step ;-) > > > > Sven > > > > > On Thu, Aug 14, 2014 at 1:02 PM, FranÃ§ois Stephany < > tulipe.moutarde(a)gmail.com> wrote: > > > Hello, > > > > > > At Ta MÃ¨re, we are used to deploy Ruby/Rails application with Heroku > or on VPS with Capistrano. Almost everybody uses the same tools and > techniques in the Rails community so deployment is quite easy once you > grasp the process. > > > > > > The same process was quite frustrating with Pharo. To solve that, > we've built HelloPharo. It is a tool to deploy small apps to a Linux VPS/VM. > > > > > > It is heavily inspired by Capistrano, it prones convention over > configuration and it wants to be full stack (e.g., serve the assets, > restart the processes). It is built with Ansible. > > > > > > We haven't released a fixed version yet but the tool starts to be in a > good-enough shape to be shown. We want to grab some feedback and fix the > most obvious limitations (see the README for more) before releasing version > 0.1.0. > > > > > > If you or your company uses a well defined process to deploy pharo > webapps, we are all ears. We think that having a canonical way to deploy > simple apps is a must if we want to see wider Pharo adoption for small web > companies. This process *must* be Unix friendly if we want to attract > Python or Ruby people. Most of them are Devops anyway, the command line is > their friend, NOT something they want to avoid. > > > > > > Pull requests (for code or instructions in the README) are more than > welcome. The code and the documentation are MIT licensed. > > > > > > https://github.com/fstephany/hello-pharo/ > > > > > > Cheers, > > > Francois > > > > > > > > > > > _______________________________________________ > > Pharo-business mailing list > > Pharo-business(a)lists.pharo.org > > http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org > >

Aug. 14, 2014

Re: [Pharo-users] [Moose-dev] [ANN] Live Robot Programming

by Johan Fabry

Aargh, copy-paste error. The Lego robot example is on Instagram of course :-) http://instagram.com/p/pEhm0Oj837/ On Aug 14, 2014, at 4:28 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > Hi all, > > itâs with great joy that I can announce the project that my PhD student Miguel and I have been working on recently: Live Robot Programming, or LRP for short. > > LRP is a live programming language designed for the creation of the behavior layer of robots. It is fundamentally a nested state machine language built with robotics applications in mind, but it is not bound to a specific robot middleware, API or OS. Have a look at one minute of LRP programming to get an idea of what it is like: http://youtu.be/4Ma8ZapBUqA > > Live programming is fun, and live robot programming even more so, as it brings all the advantages of live programming to programming a robot. You get direct manipulation of a running robot, and thatâs just cool beyond words. As an example of LRP on a robot, this guy was programmed in LRP: http://youtu.be/4Ma8ZapBUqA Note that you can use LRP âjustâ for live programming nested state machines as well. > > More information on LRP is available on its website: http://pleiad.cl/LRP where you can also find download instructions. > > LRP is implemented in Pharo, and uses Roassal2 for the visualization of its state machines. We currently can steer the Lego Mindstorms EV3 and ROS robots, thanks to a small layer on top of the cool Pharo support that Jannik, Luc, Santiago and Noury are implementing at Douai. I am going to look into support for the Parrot AR.Drone 2.0esug in a few weeks. > > Miguel will be at ESUG next week (I cannot make it), and has a talk at the IWST workshop about LRP, in the morning session. I am sure that he will also be happy to give demos of LRP if you ask him to (but sadly without a robot). > > All feedback is welcome, and â¦ have fun! > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Aug. 14, 2014

[ANN] Live Robot Programming

by Johan Fabry

Hi all, itâs with great joy that I can announce the project that my PhD student Miguel and I have been working on recently: Live Robot Programming, or LRP for short. LRP is a live programming language designed for the creation of the behavior layer of robots. It is fundamentally a nested state machine language built with robotics applications in mind, but it is not bound to a specific robot middleware, API or OS. Have a look at one minute of LRP programming to get an idea of what it is like: http://youtu.be/4Ma8ZapBUqA Live programming is fun, and live robot programming even more so, as it brings all the advantages of live programming to programming a robot. You get direct manipulation of a running robot, and thatâs just cool beyond words. As an example of LRP on a robot, this guy was programmed in LRP: http://youtu.be/4Ma8ZapBUqA Note that you can use LRP âjustâ for live programming nested state machines as well. More information on LRP is available on its website: http://pleiad.cl/LRP where you can also find download instructions. LRP is implemented in Pharo, and uses Roassal2 for the visualization of its state machines. We currently can steer the Lego Mindstorms EV3 and ROS robots, thanks to a small layer on top of the cool Pharo support that Jannik, Luc, Santiago and Noury are implementing at Douai. I am going to look into support for the Parrot AR.Drone 2.0esug in a few weeks. Miguel will be at ESUG next week (I cannot make it), and has a talk at the IWST workshop about LRP, in the morning session. I am sure that he will also be happy to give demos of LRP if you ask him to (but sadly without a robot). All feedback is welcome, and â¦ have fun! ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Aug. 14, 2014