- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] git feature request

by Esteban Lorenzano

Hi, This flow is taken into account in the new iceberg... I cannot go into details because I'm still on holidays (and no internet) until Monday... And Nico is also taking some days. Anyway, yes... We had this flow in mind (and others, of course) when we worked in the use cases we want to support. Cheers, Esteban > On 22 Jul 2016, at 15:14, Ben Coman <btc(a)openinworld.com> wrote: > >> On Fri, Jul 22, 2016 at 3:11 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>> On Fri, Jul 22, 2016 at 11:55:46AM +0800, Ben Coman wrote: >>> I'm not sure what the roadmap is for git integration, but just a use case >>> that occurs to me while I work "a bit with git" for the first time from >>> Pharo. >>> >>> I install a project via a Baseline from git and makes a small improvement. >>> What is the easiest way to contribute back? I can't push back to the >>> personal repo I downloaded from, so the easiest thing would be a single >>> menu item to: >>> 1. Fork original repository >>> 2. Push current in-Image code to a new branch in that fork. >>> >>> Maybe even... >>> 3. Issue a pull request to the original repository. >> >> This is indeed the idiomatic way to contribute on GitHub. >> >> 1. fork >> 2. install _your fork_ with gitfiletree/remote git repo >> 3. make an improvement (you can use master branch, since it's your repo, but that's a detail) >> 4. issue a pull request > > That is how you do it if you *already* know you want to be contribute > to an application or package. But what if I was just planning to *use* > an application or package, only later I ended up tracing down a bug to > that application and fixed it. What is the *easiest* for me to push > to my personal github account from where I make the Pull Request. > Something like this [1] from within Pharo (disclaimer, I've not > performed these action before, I had to hunt a bit to find it as an > example)... > > [1] https://gist.github.com/jagregory/710671 > >> Maybe IceBerg (https://github.com/npasserini/iceberg) could have some nice interface for this eventually. > > Thanks for the link. This will be interesting to watch. > > cheers -ben >

July 22, 2016

Re: [Pharo-dev] A taste of bootstrap

by Mariano Martinez Peck

On Fri, Jul 22, 2016 at 11:38 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > 2016-07-22 16:24 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> >> >> On Fri, Jul 22, 2016 at 4:12 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> Hi Pavel, >>> >>> Congrats for your hard work! You know me well, so don't take my next >>> question as negative. >>> You have been working in minimal images since years. Guille has also >>> done quite some work, and many other people as well. >>> My question is.... have we decreased the effort to keep it working as >>> Pharo evolves? Previously, there were always problems with the >>> dependencies: a single commit to Pharo would add or break a dependency and >>> so we cannot bootstrap anymore. In other words...there was still a lot of >>> human action needed to check and fix dependencies. Is this still the case? >>> >> >> Complex questions requires complex answers :). It's not a yes, neither a >> no. >> >> - We have automatized the dependency analyses >> - We added Lint rules that ensure that no new dependencies are added to >> the kernel because of an integration >> - We will be adding soon enough more tools to automatically validate and >> ensure the health of the bootstrap, and to detect possible problems. >> >> Buuut, >> >> - Lint rules can (and sometimes are) ignored >> - Not everybody is aware of how to maintain dependencies or even they do >> not know they should care about it >> >> So the human factor is still of big importance (and risk), and educating >> people is harder than machines ^^ >> > > I must say that current need of human work required for proper reloading > of all Pharo packages is too high. It can be better only as soon as the > bootstrapping will be part of our development/release process. > Exactly!!! Totally agree. And..what are the plans of getting the bootstrapping as part of the development and release process? I am sure it is on the roadmap. > > On the other hand, dependency problems are now quite rare and are very > rare in the kernel packages. > > That's very good to hear! > -- Pavel > > >> >> >>> Cheers, >>> >>> >>> >>> On Fri, Jul 22, 2016 at 10:37 AM, Pavel Krivanek < >>> pavel.krivanek(a)gmail.com> wrote: >>> >>>> >>>> >>>> 2016-07-22 15:22 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >>>> >>>>> On Fri, Jul 22, 2016 at 9:12 PM, Pavel Krivanek >>>>> <pavel.krivanek(a)gmail.com> wrote: >>>>> > Hi, >>>>> > >>>>> > as you maybe know, we are working on Pharo image bootstrap - the >>>>> process >>>>> > that can generate an image from source codes and initialize it >>>>> correctly. >>>>> > Because of practical reasons we do not bootstrap the standard image >>>>> at once >>>>> > but we are trying to bootstrap a small headless kernel image and >>>>> then load >>>>> > the rest of the system into it. >>>>> > >>>>> > The good news is that we are successful in our effor. We are already >>>>> able to >>>>> > produce well usable images as you can test here: >>>>> >>>>> Great to hear of your continuing progress. >>>>> >>>>> > >>>>> > https://goo.gl/fn1VbP >>>>> > >>>>> > From the Pharo/Squeak point of view this image is very special >>>>> because it >>>>> > doesn't contain any object inherited from 70's. Pharo lost its >>>>> umbilical >>>>> > cord. >>>>> >>>>> Does this mean you are starting with a zero byte file and adding nil, >>>>> true, false, etc...? >>>>> Or what is the size of the image you start with? >>>>> >>>> >>>> No, we are not generating image file directly. We use special VM >>>> simulator and then save its object memory. >>>> Our bootstrapped image has about 5MB now (in Spur format). >>>> >>>> >>>>> >>>>> cheers -ben >>>>> >>>>> > >>>>> > Notice that the initial display width is too narrow and and we still >>>>> need a >>>>> > lot of work on the building process, but In the next weeks and >>>>> months it >>>>> > will change a lot the Pharo development - especially as soon as it >>>>> will be >>>>> > combined with Git support. >>>>> > >>>>> > Cheers, >>>>> > -- Pavel >>>>> > >>>>> > >>>>> >>>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> > -- Mariano http://marianopeck.wordpress.com

July 22, 2016

Re: [Pharo-dev] A taste of bootstrap

by Pavel Krivanek

2016-07-22 16:24 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > > > On Fri, Jul 22, 2016 at 4:12 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Hi Pavel, >> >> Congrats for your hard work! You know me well, so don't take my next >> question as negative. >> You have been working in minimal images since years. Guille has also done >> quite some work, and many other people as well. >> My question is.... have we decreased the effort to keep it working as >> Pharo evolves? Previously, there were always problems with the >> dependencies: a single commit to Pharo would add or break a dependency and >> so we cannot bootstrap anymore. In other words...there was still a lot of >> human action needed to check and fix dependencies. Is this still the case? >> > > Complex questions requires complex answers :). It's not a yes, neither a > no. > > - We have automatized the dependency analyses > - We added Lint rules that ensure that no new dependencies are added to > the kernel because of an integration > - We will be adding soon enough more tools to automatically validate and > ensure the health of the bootstrap, and to detect possible problems. > > Buuut, > > - Lint rules can (and sometimes are) ignored > - Not everybody is aware of how to maintain dependencies or even they do > not know they should care about it > > So the human factor is still of big importance (and risk), and educating > people is harder than machines ^^ > I must say that current need of human work required for proper reloading of all Pharo packages is too high. It can be better only as soon as the bootstrapping will be part of our development/release process. On the other hand, dependency problems are now quite rare and are very rare in the kernel packages. -- Pavel > > >> Cheers, >> >> >> >> On Fri, Jul 22, 2016 at 10:37 AM, Pavel Krivanek < >> pavel.krivanek(a)gmail.com> wrote: >> >>> >>> >>> 2016-07-22 15:22 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >>> >>>> On Fri, Jul 22, 2016 at 9:12 PM, Pavel Krivanek >>>> <pavel.krivanek(a)gmail.com> wrote: >>>> > Hi, >>>> > >>>> > as you maybe know, we are working on Pharo image bootstrap - the >>>> process >>>> > that can generate an image from source codes and initialize it >>>> correctly. >>>> > Because of practical reasons we do not bootstrap the standard image >>>> at once >>>> > but we are trying to bootstrap a small headless kernel image and then >>>> load >>>> > the rest of the system into it. >>>> > >>>> > The good news is that we are successful in our effor. We are already >>>> able to >>>> > produce well usable images as you can test here: >>>> >>>> Great to hear of your continuing progress. >>>> >>>> > >>>> > https://goo.gl/fn1VbP >>>> > >>>> > From the Pharo/Squeak point of view this image is very special >>>> because it >>>> > doesn't contain any object inherited from 70's. Pharo lost its >>>> umbilical >>>> > cord. >>>> >>>> Does this mean you are starting with a zero byte file and adding nil, >>>> true, false, etc...? >>>> Or what is the size of the image you start with? >>>> >>> >>> No, we are not generating image file directly. We use special VM >>> simulator and then save its object memory. >>> Our bootstrapped image has about 5MB now (in Spur format). >>> >>> >>>> >>>> cheers -ben >>>> >>>> > >>>> > Notice that the initial display width is too narrow and and we still >>>> need a >>>> > lot of work on the building process, but In the next weeks and months >>>> it >>>> > will change a lot the Pharo development - especially as soon as it >>>> will be >>>> > combined with Git support. >>>> > >>>> > Cheers, >>>> > -- Pavel >>>> > >>>> > >>>> >>>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > >

July 22, 2016

Re: [Pharo-dev] A taste of bootstrap

by Guillermo Polito

On Fri, Jul 22, 2016 at 4:12 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi Pavel, > > Congrats for your hard work! You know me well, so don't take my next > question as negative. > You have been working in minimal images since years. Guille has also done > quite some work, and many other people as well. > My question is.... have we decreased the effort to keep it working as > Pharo evolves? Previously, there were always problems with the > dependencies: a single commit to Pharo would add or break a dependency and > so we cannot bootstrap anymore. In other words...there was still a lot of > human action needed to check and fix dependencies. Is this still the case? > Complex questions requires complex answers :). It's not a yes, neither a no. - We have automatized the dependency analyses - We added Lint rules that ensure that no new dependencies are added to the kernel because of an integration - We will be adding soon enough more tools to automatically validate and ensure the health of the bootstrap, and to detect possible problems. Buuut, - Lint rules can (and sometimes are) ignored - Not everybody is aware of how to maintain dependencies or even they do not know they should care about it So the human factor is still of big importance (and risk), and educating people is harder than machines ^^ > Cheers, > > > > On Fri, Jul 22, 2016 at 10:37 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com > > wrote: > >> >> >> 2016-07-22 15:22 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >> >>> On Fri, Jul 22, 2016 at 9:12 PM, Pavel Krivanek >>> <pavel.krivanek(a)gmail.com> wrote: >>> > Hi, >>> > >>> > as you maybe know, we are working on Pharo image bootstrap - the >>> process >>> > that can generate an image from source codes and initialize it >>> correctly. >>> > Because of practical reasons we do not bootstrap the standard image at >>> once >>> > but we are trying to bootstrap a small headless kernel image and then >>> load >>> > the rest of the system into it. >>> > >>> > The good news is that we are successful in our effor. We are already >>> able to >>> > produce well usable images as you can test here: >>> >>> Great to hear of your continuing progress. >>> >>> > >>> > https://goo.gl/fn1VbP >>> > >>> > From the Pharo/Squeak point of view this image is very special because >>> it >>> > doesn't contain any object inherited from 70's. Pharo lost its >>> umbilical >>> > cord. >>> >>> Does this mean you are starting with a zero byte file and adding nil, >>> true, false, etc...? >>> Or what is the size of the image you start with? >>> >> >> No, we are not generating image file directly. We use special VM >> simulator and then save its object memory. >> Our bootstrapped image has about 5MB now (in Spur format). >> >> >>> >>> cheers -ben >>> >>> > >>> > Notice that the initial display width is too narrow and and we still >>> need a >>> > lot of work on the building process, but In the next weeks and months >>> it >>> > will change a lot the Pharo development - especially as soon as it >>> will be >>> > combined with Git support. >>> > >>> > Cheers, >>> > -- Pavel >>> > >>> > >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

July 22, 2016

Re: [Pharo-dev] git feature request

by Peter Uhnak

On Fri, Jul 22, 2016 at 04:11:32PM +0200, Peter Uhnak wrote: > On Fri, Jul 22, 2016 at 09:14:25PM +0800, Ben Coman wrote: > > On Fri, Jul 22, 2016 at 3:11 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > On Fri, Jul 22, 2016 at 11:55:46AM +0800, Ben Coman wrote: > > >> I'm not sure what the roadmap is for git integration, but just a use case > > >> that occurs to me while I work "a bit with git" for the first time from > > >> Pharo. > > >> > > >> I install a project via a Baseline from git and makes a small improvement. > > >> What is the easiest way to contribute back? I can't push back to the > > >> personal repo I downloaded from, so the easiest thing would be a single > > >> menu item to: > > >> 1. Fork original repository > > >> 2. Push current in-Image code to a new branch in that fork. > > >> > > >> Maybe even... > > >> 3. Issue a pull request to the original repository. > > > > > > This is indeed the idiomatic way to contribute on GitHub. > > > > > > 1. fork > > > 2. install _your fork_ with gitfiletree/remote git repo > > > 3. make an improvement (you can use master branch, since it's your repo, but that's a detail) > > > 4. issue a pull request > > > > That is how you do it if you *already* know you want to be contribute > > to an application or package. But what if I was just planning to *use* > > an application or package, only later I ended up tracing down a bug to > > that application and fixed it. What is the *easiest* for me to push > > to my personal github account from where I make the Pull Request. > > Something like this [1] from within Pharo (disclaimer, I've not > > performed these action before, I had to hunt a bit to find it as an > > example)... > > > > This would depend a bit on how you installed the project to start with. > > If you installed it with gitfiletree/remote git repo, then you can follow what you've just posted, because it's the same. > > However if you installed it via the github:// protocol (or it was automatically pulled in via some other project's BaselineOf or ConfigurationOf), > then it's a bit of pain, because you can't just pull in another project with the same baseline (Metacello it thinks it's a different project). > > Luckily, you should be able to explicitly permit the conflict: > > Metacello new > baseline: 'MyProject'; > repository: 'gitfiletree://wherever'; > onConflict: [:ex | ex allow ]; > load Oh, and after this you would follow the same approach. Let's hope IceBerg streamlines this. > > We should be documenting these things somewhereâ¦ > > Peter

July 22, 2016

Re: [Pharo-dev] A taste of bootstrap

by Mariano Martinez Peck

Hi Pavel, Congrats for your hard work! You know me well, so don't take my next question as negative. You have been working in minimal images since years. Guille has also done quite some work, and many other people as well. My question is.... have we decreased the effort to keep it working as Pharo evolves? Previously, there were always problems with the dependencies: a single commit to Pharo would add or break a dependency and so we cannot bootstrap anymore. In other words...there was still a lot of human action needed to check and fix dependencies. Is this still the case? Cheers, On Fri, Jul 22, 2016 at 10:37 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > 2016-07-22 15:22 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > >> On Fri, Jul 22, 2016 at 9:12 PM, Pavel Krivanek >> <pavel.krivanek(a)gmail.com> wrote: >> > Hi, >> > >> > as you maybe know, we are working on Pharo image bootstrap - the process >> > that can generate an image from source codes and initialize it >> correctly. >> > Because of practical reasons we do not bootstrap the standard image at >> once >> > but we are trying to bootstrap a small headless kernel image and then >> load >> > the rest of the system into it. >> > >> > The good news is that we are successful in our effor. We are already >> able to >> > produce well usable images as you can test here: >> >> Great to hear of your continuing progress. >> >> > >> > https://goo.gl/fn1VbP >> > >> > From the Pharo/Squeak point of view this image is very special because >> it >> > doesn't contain any object inherited from 70's. Pharo lost its umbilical >> > cord. >> >> Does this mean you are starting with a zero byte file and adding nil, >> true, false, etc...? >> Or what is the size of the image you start with? >> > > No, we are not generating image file directly. We use special VM simulator > and then save its object memory. > Our bootstrapped image has about 5MB now (in Spur format). > > >> >> cheers -ben >> >> > >> > Notice that the initial display width is too narrow and and we still >> need a >> > lot of work on the building process, but In the next weeks and months it >> > will change a lot the Pharo development - especially as soon as it will >> be >> > combined with Git support. >> > >> > Cheers, >> > -- Pavel >> > >> > >> >> > -- Mariano http://marianopeck.wordpress.com

July 22, 2016

Re: [Pharo-dev] git feature request

by Peter Uhnak

On Fri, Jul 22, 2016 at 09:14:25PM +0800, Ben Coman wrote: > On Fri, Jul 22, 2016 at 3:11 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > On Fri, Jul 22, 2016 at 11:55:46AM +0800, Ben Coman wrote: > >> I'm not sure what the roadmap is for git integration, but just a use case > >> that occurs to me while I work "a bit with git" for the first time from > >> Pharo. > >> > >> I install a project via a Baseline from git and makes a small improvement. > >> What is the easiest way to contribute back? I can't push back to the > >> personal repo I downloaded from, so the easiest thing would be a single > >> menu item to: > >> 1. Fork original repository > >> 2. Push current in-Image code to a new branch in that fork. > >> > >> Maybe even... > >> 3. Issue a pull request to the original repository. > > > > This is indeed the idiomatic way to contribute on GitHub. > > > > 1. fork > > 2. install _your fork_ with gitfiletree/remote git repo > > 3. make an improvement (you can use master branch, since it's your repo, but that's a detail) > > 4. issue a pull request > > That is how you do it if you *already* know you want to be contribute > to an application or package. But what if I was just planning to *use* > an application or package, only later I ended up tracing down a bug to > that application and fixed it. What is the *easiest* for me to push > to my personal github account from where I make the Pull Request. > Something like this [1] from within Pharo (disclaimer, I've not > performed these action before, I had to hunt a bit to find it as an > example)... > This would depend a bit on how you installed the project to start with. If you installed it with gitfiletree/remote git repo, then you can follow what you've just posted, because it's the same. However if you installed it via the github:// protocol (or it was automatically pulled in via some other project's BaselineOf or ConfigurationOf), then it's a bit of pain, because you can't just pull in another project with the same baseline (Metacello it thinks it's a different project). Luckily, you should be able to explicitly permit the conflict: Metacello new baseline: 'MyProject'; repository: 'gitfiletree://wherever'; onConflict: [:ex | ex allow ]; load We should be documenting these things somewhereâ¦ Peter

July 22, 2016

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

by Max Leske

> On 22 Jul 2016, at 07:26, Ben Coman <btc(a)openInWorld.com> wrote: > > > > On Fri, Jul 22, 2016 at 4:42 AM, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > > > On Sun, Jul 17, 2016 at 6:46 AM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > > Do you have some test code or a test image I could run to reproduce > the problem? > > > The problem is that I cannot reproduce it immediately. It takes me some days and likely some image save and start again until I reproduce it. > > Could you try > How about something that invokes > > > > Now I have one thing for you to try. In the move of DelaySchedulerXxx > from milliseconds to microseconds, the code for dealing with clock > wrap-around was removed, but I wonder if it was also covering clock > jitter as a side effect. Could you try again the SpinScheduler but > restore this code... > > From handletTimerEvent... > "Check for clock wrap-around." > millisecondNowTick < activeDelayStartTime ifTrue: [ > "clock wrapped" > self saveResumptionTimes. > self restoreResumptionTimes ]. > activeDelayStartTime := millisecondNowTick. > > From runTimerEventLoop... > Time millisecondClockValue < millisecondNowTick > ifTrue:[ timingSemaphore signal ]. "retry" > > From startup... > activeDelayStartTime := Time millisecondClockValue. > > > OK, I put back the code into the spin scheduler. Then I kept using milisecond one until I finished the changes. Then I saved image and switch to spin one: the image hungs. I cannot even interrupt it. I attach my modifications. > Do they look correct? > > I confirm that locked my image also. > > One change of milli to micro was missed at the bottom of runTimeEventLoop... > That is... > Time millisecondClockValue < microsecondNowTick > to... > Time microsecondClockValue < microsecondNowTick > > (just a case of domestic blindness) [1] :) :) And I reviewed your code and missed itâ¦ > > cheers -ben > > [1] http://www.urbandictionary.com/define.php?term=domestic%20blindness <http://www.urbandictionary.com/define.php?term=domestic%20blindness> > > P.S. A trick to debug delays is to bypass interCycleDelay by at the top of it putting... > true ifTrue: [^self]. > >

July 22, 2016

[ANN] Pillar 4.0.0

by Thibault ARLOING

Hello, I'm happy to announce the latest release of Pillar. This release has been possible because of the hard work of Damien Cassou, Cyril Ferlicot, Yann Dubois, Thibault Arloing and Lukas Komarek. What did it bring and what are the largest changes ? * Huge cleaning of code and Dependencies * Many bug fixes * Huge refactoring of internal parts * Extract phase management into an external project (LightPhaser) * Transformers and Phases are all Pipes Remove Compilation cycle * Remove template handling from Pillar * Remove generation of pillarpostExport.sh * Pillar now exports files to JSON format * Command for pillar archetypes "./pillar archetype book", book can be replaced by other archetype names (see Pillar documentation) * Possibility to load an archetype with a Makefile to compile pillar files Features * Check phase to check syntax * EPub exporter for e-books (use pillar archetypes for this) * Semantic links to Youtube and Wikipedia * Citations for LaTeX * Structures (see Pillar documentation) * Footnotes for HTML, Markdown, LaTeX and AsciiDoc * Improvement of parsing configuration failure message Major changes * Metadata field in configuration to separate data from configuration properties * Support files in configuration does no longer exists * "disableTransformers" property is now named "disabledPhases" * AsciiDoc file extension is now ".asciidoc" * Pillar now manages one input file, not a collection of input files anymore * Parameter inputFiles is now replaced by inputFile The documentation of Pillar will be update as soon as possible to fit those changes. Cheers, Thibault

July 22, 2016

Re: [Pharo-dev] A taste of bootstrap

by Pavel Krivanek

2016-07-22 15:22 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > On Fri, Jul 22, 2016 at 9:12 PM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > > > as you maybe know, we are working on Pharo image bootstrap - the process > > that can generate an image from source codes and initialize it correctly. > > Because of practical reasons we do not bootstrap the standard image at > once > > but we are trying to bootstrap a small headless kernel image and then > load > > the rest of the system into it. > > > > The good news is that we are successful in our effor. We are already > able to > > produce well usable images as you can test here: > > Great to hear of your continuing progress. > > > > > https://goo.gl/fn1VbP > > > > From the Pharo/Squeak point of view this image is very special because it > > doesn't contain any object inherited from 70's. Pharo lost its umbilical > > cord. > > Does this mean you are starting with a zero byte file and adding nil, > true, false, etc...? > Or what is the size of the image you start with? > No, we are not generating image file directly. We use special VM simulator and then save its object memory. Our bootstrapped image has about 5MB now (in Spur format). > > cheers -ben > > > > > Notice that the initial display width is too narrow and and we still > need a > > lot of work on the building process, but In the next weeks and months it > > will change a lot the Pharo development - especially as soon as it will > be > > combined with Git support. > > > > Cheers, > > -- Pavel > > > > > >

July 22, 2016