May 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Coral is green

by phil＠highoctane.be

On Sat, May 24, 2014 at 1:29 AM, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Fri, May 23, 2014 at 10:26:54PM +0200, Stephan Eggermont wrote: > > David wrote: > > >In any case, the change affects one source file in the VM platform > > >sources, so if you can arrange to get that included in the Pharo VM > > >builds, that should provide a working VM that you can use for OSProcess > on > > >Pharo. > > > > I noticed that this is only a unix vm change. Should this be working > > already on Mac and Windows? > > > > Definitely not for Windows. > > I'm honestly not sure where we stand on Mac VMs. If the VM is based on the > unix platform sources, then it will work, otherwise probably not. > > The specific feature that affects the OSProcess tests is the ability to > support #forkSqueak, which uses a Unix fork() mechanism to start an exact > copy of the running VM and image with very little memory overhead. This is > used in the OSProcess test suite in order to set up test cases that deal > with the interaction of two or more OS processes. > > Think about what is required to ask the VM to pause for a moment, split > itself in two like an amoeba, and then have both of the VM instances start > running again as if nothing had happened. That means pausing and restarting > some signal handlers, pausing the connection to the X display so a new one > can be created for the second VM process, and restarting the various > threads > that were running in the original VM. Most of this was already working for > Cog. Eliot came up with a way to restart the timer threads for Cog and > wonder of wonders, that was all it took to get #forkSqueak working on Cog. > It would be terrific to have this working again smoothly on Linux. I am using CentOS6. > > Dave > >

May 24, 2014

Re: [Pharo-dev] What is your seaside application?

by Tudor Girba

This post is not yet visible. Doru On Sat, May 24, 2014 at 8:37 AM, stepharo <stepharo(a)free.fr> wrote: > http://pharoweekly.wordpress.com/2014/05/24/multi-users- > and-agile-planning-tool/ > > :) > > > On 23/5/14 22:24, Stephan Eggermont wrote: > >> Story Board >> Story Board is a multi user, drag and drop, agile planning tool. Each >> user can create projects and invite other users to participate. >> Architecture >> This application is build with Deltawerken and Seaside 3.1. Please use >> the configuration to load this application. >> Loading >> Gofer new >> url: 'http://ss3.gemstone.com/ss/StoryBoard'; >> package: 'ConfigurationOfStoryBoard'; >> load. >> (Smalltalk at: #ConfigurationOfStoryBoard) project bleedingEdge load >> >> Change the admin password in a workspace >> (SBUser userWithId: 'Admin') password: '<your new password>' >> Video >> Getting started:https://vimeo.com/49195501 >> Links >> http://ss3.gemstone.com/ss/Deltawerken.html >> http://www.seaside.st >> >> > > -- www.tudorgirba.com "Every thing has its own flow"

May 24, 2014

Re: [Pharo-dev] What is your seaside application?

by stepharo

http://pharoweekly.wordpress.com/2014/05/24/multi-users-and-agile-planning-… :) On 23/5/14 22:24, Stephan Eggermont wrote: > Story Board > Story Board is a multi user, drag and drop, agile planning tool. Each user can create projects and invite other users to participate. > Architecture > This application is build with Deltawerken and Seaside 3.1. Please use the configuration to load this application. > Loading > Gofer new > url: 'http://ss3.gemstone.com/ss/StoryBoard'; > package: 'ConfigurationOfStoryBoard'; > load. > (Smalltalk at: #ConfigurationOfStoryBoard) project bleedingEdge load > > Change the admin password in a workspace > (SBUser userWithId: 'Admin') password: '<your new password>' > Video > Getting started:https://vimeo.com/49195501 > Links > http://ss3.gemstone.com/ss/Deltawerken.html > http://www.seaside.st >

May 24, 2014

Re: [Pharo-dev] What is your seaside application?

by stepharo

you should ask a clear question/ request in the seaside mailing-list. On 23/5/14 22:16, Leonardo Silva wrote: > > From: stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> > > Subject: Re: [Pharo-dev] What is your seaside application? > > Date: May 23, 2014 at 3:06:56 PM GMT-4 > > To: Pharo Development List <pharo-dev(a)lists.pharo.org > <mailto:pharo-dev@lists.pharo.org>> > > Reply-To: Pharo Development List <pharo-dev(a)lists.pharo.org > <mailto:pharo-dev@lists.pharo.org>> > > > > > >> Hi! > >> > >> Leonardo is a smart PhD Brazilien student, who is discovering the > treasures we have built. > > Welcome Leonardo > > Thank you! > > >> He would like to analyze Seaside applications to analyze event > propagation. > > What do you mean by event propagation because I do not really how it > relates to Seasid. > > I am interested in events you can trigger in web pages. For example: a > user clicks on a button and the script code associated causes a state > change in the Document Object Model (DOM) and sends a XHR request > (XMLHttpRequest) to the server. The server eventually answers this > request, closing the sequence of events. I want to trace these > sequences of events from a running application. > > >> I told Leonardo that the Pharo and Seaside communities are great > and he will probably get help from us. > > we are :) > > That's very nice > > >> So, a simple and quick-to-answer question, what is your Seaside > application and how to access the code of it? > > > > many of web app are private because business oriented. > > I understand, but it would be nice to have some examples of web > applications using script languages, even if I don't have access to > all source code. > > Cheers, > > Leonardo

May 24, 2014

Re: [Pharo-dev] Advice for a newb

by stepharo

> By all means use the change list for crash recovery, or even change > sets. But unlike change sets, Monticello's updates provide support > for any number of steps. Typically with a change set you have to > manually reorder things. Yes > I've used change sets a lot in the past to pull off a number of > "adventurous" system changes. But now I'm familiar with Monticello it > feels like its by far the best way. Yes but it depends which changes he is doing. Imagine a change that break MC. Stef

May 24, 2014

Re: [Pharo-dev] Advice for a newb

by stepharo

Hi I ***know*** remember that I was the guy that pushed the use of MC to manage 3.9. still there are some cases were MC does not work. Stef

May 24, 2014

Re: [Pharo-dev] Coral is green

by David T. Lewis

On Fri, May 23, 2014 at 10:26:54PM +0200, Stephan Eggermont wrote: > David wrote: > >In any case, the change affects one source file in the VM platform > >sources, so if you can arrange to get that included in the Pharo VM > >builds, that should provide a working VM that you can use for OSProcess on > >Pharo. > > I noticed that this is only a unix vm change. Should this be working > already on Mac and Windows? > Definitely not for Windows. I'm honestly not sure where we stand on Mac VMs. If the VM is based on the unix platform sources, then it will work, otherwise probably not. The specific feature that affects the OSProcess tests is the ability to support #forkSqueak, which uses a Unix fork() mechanism to start an exact copy of the running VM and image with very little memory overhead. This is used in the OSProcess test suite in order to set up test cases that deal with the interaction of two or more OS processes. Think about what is required to ask the VM to pause for a moment, split itself in two like an amoeba, and then have both of the VM instances start running again as if nothing had happened. That means pausing and restarting some signal handlers, pausing the connection to the X display so a new one can be created for the second VM process, and restarting the various threads that were running in the original VM. Most of this was already working for Cog. Eliot came up with a way to restart the timer threads for Cog and wonder of wonders, that was all it took to get #forkSqueak working on Cog. Dave

May 23, 2014

Re: [Pharo-dev] [squeak-dev] Re: Advice for a newb

by David T. Lewis

On Fri, May 23, 2014 at 02:30:36PM -0700, Eliot Miranda wrote: > On Fri, May 23, 2014 at 12:47 PM, stepharo <stepharo(a)free.fr> wrote: > > > > > On 20/5/14 04:41, Rick Kitts wrote: > > > > Hello. I was wondering if anyone could point me to or otherwise suggest > > some best practices for working on Kernel code. I???m futzing about with the > > Duration class (in the interest of fixing 13215) > > > > Thanks! > > > > and have discovered that it???s really easy to crash Pharo if I break that > > class. I assume there are other classes that would exhibit the same > > behavior. > > > > Yes like Array or OrderedCollection. > > > > We are working on a bootstrap of pharo and it could help for brain surgery > > (but in that case the system may simply not build at all). > > So the suggestion of Ron to use ChangeSet is a good one. > > > > But it is also possible to do it with Monticello, using "updates", which > are really baseline versions of a package. The idea is to make the > necessary changes that support your next, potentially suicidal step, commit > a baseline for that support, and then commit the change that depends on the > support. The Monticello update scheme ensures that the baseline is loaded > before your second commit. This process can be repeated as many times as > necessary to make a sequence of interdependent changes happen in order. > > For example, I've just added multiple bytecode support to Squeak trunk. > That needed some code on Squeak's BytecodeEncoder and subclasses, which > are in the Compiler package, *before* loading the Kernel code that depended > on that BytecodeEncoder support. If things don't happen in the right order > the compiler, debugger, and tool facilities such as references & > assignments would break. Indeed, the Squeak update stream is wonderful. I remember being initially worried that MC was too heavyweight to use as a replacement for the change set update stream. But I was wrong, it works very well and also brings the benefits of Monticello versioning along for the ride. It's not just good in theory, either. In practice, I'm usually using a trunk image, and I am in the habit of doing regular updates from the trunk stream to make sure I am in sync. It works very well and problems are rare. This is an interesting contrast with the work flows that I see discussed on the Pharo list. There, the emphasis seems to be more on the code, so the idea seems to be to build images that developers will open as fresh environments into which they will load their code. The working images are treated as transient artifacts, with the code living in Monticello or git repositories. It's a perfectly valid approach, and it might well be preferred for large project teams doing coordinated development. For me personally, I tend to look at things the other way around. It took me a long time to unlearn some habits from C and Fortran and sccs and such. But finally I more or less got the hang of it, and I am now quite comfortable working within a living image and using the source code tools to take care of the source code. The thing that really makes this work for me is the update stream. That is what makes it effortless to maintain a working image, while still keeping fully in sync with the latest community updates. Dave

May 23, 2014

Re: [Pharo-dev] What is your seaside application?

by Leonardo Silva

Thanks Stephan! I will check it out. On Fri, May 23, 2014 at 5:24 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Story Board > Story Board is a multi user, drag and drop, agile planning tool. Each user > can create projects and invite other users to participate. > Architecture > This application is build with Deltawerken and Seaside 3.1. Please use the > configuration to load this application. > Loading > Gofer new > url: 'http://ss3.gemstone.com/ss/StoryBoard'; > package: 'ConfigurationOfStoryBoard'; > load. > (Smalltalk at: #ConfigurationOfStoryBoard) project bleedingEdge load > > Change the admin password in a workspace > (SBUser userWithId: 'Admin') password: '<your new password>' > Video > Getting started: https://vimeo.com/49195501 > Links > http://ss3.gemstone.com/ss/Deltawerken.html > http://www.seaside.st >

May 23, 2014

Re: [Pharo-dev] Advice for a newb

by Eliot Miranda

On Fri, May 23, 2014 at 12:47 PM, stepharo <stepharo(a)free.fr> wrote: > > On 20/5/14 04:41, Rick Kitts wrote: > > Hello. I was wondering if anyone could point me to or otherwise suggest > some best practices for working on Kernel code. Iâm futzing about with the > Duration class (in the interest of fixing 13215) > > Thanks! > > and have discovered that itâs really easy to crash Pharo if I break that > class. I assume there are other classes that would exhibit the same > behavior. > > Yes like Array or OrderedCollection. > > We are working on a bootstrap of pharo and it could help for brain surgery > (but in that case the system may simply not build at all). > So the suggestion of Ron to use ChangeSet is a good one. > But it is also possible to do it with Monticello, using "updates", which are really baseline versions of a package. The idea is to make the necessary changes that support your next, potentially suicidal step, commit a baseline for that support, and then commit the change that depends on the support. The Monticello update scheme ensures that the baseline is loaded before your second commit. This process can be repeated as many times as necessary to make a sequence of interdependent changes happen in order. For example, I've just added multiple bytecode support to Squeak trunk. That needed some code on Squeak's BytecodeEncoder and subclasses, which are in the Compiler package, *before* loading the Kernel code that depended on that BytecodeEncoder support. If things don't happen in the right order the compiler, debugger, and tool facilities such as references & assignments would break. By all means use the change list for crash recovery, or even change sets. But unlike change sets, Monticello's updates provide support for any number of steps. Typically with a change set you have to manually reorder things. I've used change sets a lot in the past to pull off a number of "adventurous" system changes. But now I'm familiar with Monticello it feels like its by far the best way. > > Now once I got change that crash (just a tight endless loop) as soon as > you change anything and there you have to rollback and turn around the self > referencing aspect. > > > I suppose I could just be really cautious and save my image after every > change but that seems so error prone that Iâm hoping that there are > idiomatic ways of working on kernel code (beyond just save ones image early > and often) so I donât lose work. Iâm asking because the naive solution > (copy the original class, modify it to suit, delete the original and rename > the new class to the original) of course doesnât work. > > TIA for any suggestions or assistance and apologies in advance if this > is RTFM, I didnât see anything (didnât look very hard either though). > > âRick > > > -- best, Eliot

May 23, 2014