- Pharo-dev - lists.pharo.org

[ANN] New Woden Video

by Ronie Salgado

Hello, In a previous email I presented an early video of Woden, my new graphics engine written in Pharo. Here I have a new video in which I show some of the features of Woden: https://www.youtube.com/watch?v=1Nze9tnwYxY&feature=youtu.be With Alex, we started rewriting Roassal 3D using Woden, which can be seen in the second half of the video. I will try to show many more demos in ESUG. It also should be possible now to load Woden using the following script: Gofer new smalltalkhubUser: 'ronsaldo' project: 'Woden'; package: 'ConfigurationOfWoden'; load. (Smalltalk at: #ConfigurationOfWoden) loadBleedingEdge Later I will make a stable configuration version. Greetings, Ronie

Aug. 15, 2014

Re: [Pharo-dev] [Pharo-business] [Pharo-users] [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-dev] [Pharo-business] [Pharo-users] [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-dev] [Pharo-business] [Pharo-users] [ANN] HelloPharo - webapp deployment tool

by Sven Van Caekenberghe

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-dev] allUnimplementedCalls removed

by stepharo

On 14/8/14 16:21, Marcus Denker wrote: > On 10 Aug 2014, at 08:42, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > >> Hi Marcus, >> >> was it appropriate to remove allUnimplementedCalls from the >> SystemNavigation? We lost an important message to check the image >> health. Is there any replacement? >> > I removed it mostly because the Code Critique tool has the same functionalityâ¦ > but maybe it is good to have this for the Kernel without needed the Code critique loaded? +1 > We can add it backâ¦ > > Marcus >

Aug. 14, 2014

Re: [Pharo-dev] Submitted Improved Pharo Help (Case 13811) - but couldn't compare it?

by Marcus Denker

On 14 Aug 2014, at 16:50, Tim Mackinnon <tim(a)testit.works> wrote: > Thanks gain Marcus - I think this is what Ben or Sean were referring to. > > I donât think Iâve fully understood the role of the cache - again maybe another beer at Esug might set me straight. God knows - maybe I might be able to figure out how to fix it? > Yes, we can try :-) > Does clearing your cache let it then compare properly Yes! > - or is it more complicated than thatt > At the moment - I feel blind in all my changes, and Iâm really not sure what Iâm committing to remote - repos which is worrying. It could be that its a workflow thing - and maybe someone can show me a better workflow. > Marcus

Aug. 14, 2014

Re: [Pharo-dev] Submitted Improved Pharo Help (Case 13811) - but couldn't compare it?

by Tim Mackinnon

Thanks gain Marcus - I think this is what Ben or Sean were referring to. I donât think Iâve fully understood the role of the cache - again maybe another beer at Esug might set me straight. God knows - maybe I might be able to figure out how to fix it? Does clearing your cache let it then compare properly - or is it more complicated than that? At the moment - I feel blind in all my changes, and Iâm really not sure what Iâm committing to remote - repos which is worrying. It could be that its a workflow thing - and maybe someone can show me a better workflow. Tim On 14 Aug 2014, at 15:12, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 10 Aug 2014, at 23:44, Tim Mackinnon <tim(a)testit.works> wrote: > >> Hi Stef - I went back and opened that image again (I save it in that state) - it was 4.0-40162 build. And it still says no changes? Itâs possible that my changes were incorporated now - or possibly Iâve done something wrong (although Iâm not quite sure what). Possibly my .changes file would show my steps? >> > > I think there is a bugâ¦ > > I even added an issue entry long time ago: > > https://pharo.fogbugz.com/f/cases/6964/Changes-in-Monticello-seems-to-compa… > > The problem seems to be that even if you ask for âshow me the change to *that* repositoryâ, it actually looks in the cache and finds > the already changed one. > > Marcus

Aug. 14, 2014

Re: [Pharo-dev] Does image build process check for halts?

by Tim Mackinnon

Gosh - this would be a great talk at a conferenceâ¦ ;) Maybe at Esug someone can show me some of what is going onâ¦ I donât really understand how you are building things, but it should be possible to come up with some pragmatic things that maybe we can help with. Certainly self halt. should be a simple one to detect and get in place. In my Esug, talk I was going to show my simple (and naive) script that builds the OU image and regexâs the transcript that I pump out to the file system. It sounds like the Pharo build is much more clever - but maybe that technique might work too? Tim On 14 Aug 2014, at 15:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 08 Aug 2014, at 17:29, Tim Mackinnon <tim(a)testit.works> wrote: > >> Maybe this is a good moment to review what checks are run on every build and ensure that they are working? >> >> Itâs easy to leave in something like self halt - it would be nice to have the CI system do its stuff and send you an email that you forget (this is where CI is awesome). >> > > Yesâ¦ but nothing happens by itself. > >> Iâm also assuming in the CI process we check logs for âundefinedâ and âerrorâ msgs that would appear in the transcript right? >> > no, it does not. It fails on Error, though. And Undeclareds are checked by the test #testUndeclared of the ReleaseTest class that is run on > the final result of the build. > > Marcus

Aug. 14, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40170 Home: https://github.com/pharo-project/pharo-core

Aug. 14, 2014

[pharo-project/pharo-core] 5885f8: 40170

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 5885f80d244f774084114751148f34f5e6dfecf2 https://github.com/pharo-project/pharo-core/commit/5885f80d244f774084114751… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-08-14 (Thu, 14 Aug 2014) Changed paths: M Kernel.package/Object.class/instance/error handling/explicitRequirement.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script169.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40169.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Tests.package/TraitTest.class/instance/testing/testExplicitRequirementWithSuperclassImplementatiosAlwaysReturnsTheCorrectValue.st Log Message: ----------- 40170 http://files.pharo.org/image/40/40170.zip

Aug. 14, 2014