- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Flattened traits in Pharo 7

by Pavel Krivanek

2017-06-27 14:27 GMT+02:00 Peter Uhnak <i.uhnak(a)gmail.com>: > Just so I understand... if I have extended e.g. TBehavior, I will need to > lookup all the users and copy the method everywhere? > Yes -- Pavel > > > On Tue, Jun 27, 2017 at 02:16:14PM +0200, Pavel Krivanek wrote: > > Hi, > > > > because we want to have traits only as an option where people will be > able > > to choose custom traits implementation, the Pharo kernel cannot depend on > > them. For that reason we had to flatten all classes that use traits in > the > > kernel packages. > > That means that methods from system traits as TBehavior [1] were copied > to > > the trait users and the traits were removed from the class definitions. > For > > now these traits are still present in the image. > > If you use own traits in your projects, this step will have no impact on > > you. Only if your project extends the system traits, you will need to > adopt > > it for Pharo 7. > > > > [1] complete list: TApplyingOnClassSide TBehavior TBehaviorCategorization > > TClass TClassDescription TComposingDescription TSortable TTranscript > > TTransformationCompatibility > > > > Cheers, > > -- Pavel > >

June 27, 2017

Re: [Pharo-dev] Flattened traits in Pharo 7

by Peter Uhnak

Just so I understand... if I have extended e.g. TBehavior, I will need to lookup all the users and copy the method everywhere? On Tue, Jun 27, 2017 at 02:16:14PM +0200, Pavel Krivanek wrote: > Hi, > > because we want to have traits only as an option where people will be able > to choose custom traits implementation, the Pharo kernel cannot depend on > them. For that reason we had to flatten all classes that use traits in the > kernel packages. > That means that methods from system traits as TBehavior [1] were copied to > the trait users and the traits were removed from the class definitions. For > now these traits are still present in the image. > If you use own traits in your projects, this step will have no impact on > you. Only if your project extends the system traits, you will need to adopt > it for Pharo 7. > > [1] complete list: TApplyingOnClassSide TBehavior TBehaviorCategorization > TClass TClassDescription TComposingDescription TSortable TTranscript > TTransformationCompatibility > > Cheers, > -- Pavel

June 27, 2017

Re: [Pharo-dev] Flattened traits in Pharo 7

by Juraj Kubelka

Just for curiosity: Is it a good decision? It is supposed that with Traits we can have less code duplication. And maybe the code duplication happens also in the Pharo kernel, right? Thanks for any explanation :-) Cheers, Juraj > El 27-06-2017, a las 14:16, Pavel Krivanek <pavel.krivanek(a)gmail.com> escribiÃ³: > > Hi, > > because we want to have traits only as an option where people will be able to choose custom traits implementation, the Pharo kernel cannot depend on them. For that reason we had to flatten all classes that use traits in the kernel packages. > That means that methods from system traits as TBehavior [1] were copied to the trait users and the traits were removed from the class definitions. For now these traits are still present in the image. > If you use own traits in your projects, this step will have no impact on you. Only if your project extends the system traits, you will need to adopt it for Pharo 7. > > [1] complete list: TApplyingOnClassSide TBehavior TBehaviorCategorization TClass TClassDescription TComposingDescription TSortable TTranscript TTransformationCompatibility > > Cheers, > -- Pavel

June 27, 2017

Flattened traits in Pharo 7

by Pavel Krivanek

Hi, because we want to have traits only as an option where people will be able to choose custom traits implementation, the Pharo kernel cannot depend on them. For that reason we had to flatten all classes that use traits in the kernel packages. That means that methods from system traits as TBehavior [1] were copied to the trait users and the traits were removed from the class definitions. For now these traits are still present in the image. If you use own traits in your projects, this step will have no impact on you. Only if your project extends the system traits, you will need to adopt it for Pharo 7. [1] complete list: TApplyingOnClassSide TBehavior TBehaviorCategorization TClass TClassDescription TComposingDescription TSortable TTranscript TTransformationCompatibility Cheers, -- Pavel

June 27, 2017

Re: [Pharo-dev] FileReference>>/ and path canonicalisation

by Sven Van Caekenberghe

Hi Alistair, I think it is great that you are working on FileSystem and are trying to contribute. I appreciate your effort to find consensus. But, and please take this as positive criticism, I feel a bit uneasy when I read your reasoning, but maybe I am wrong. You see, the way I understand FileSystem (what I think was the original design idea), it is a cross platform abstraction over concrete file systems and paths. A FileReference holds a FileSystem and a Path. A Path is just a collection of elements that leads to a location, the leaf possibly being interpreted as a file with an extension (although that last point is just a convention). It seems great effort was put into avoiding the use of separators. Pharo is an object oriented system with appropriate abstractions, FileSystem gives us one approach to this difficult problem. In your reasoning, your truth, your reference is always the Unix file system and the way paths are handled there. You expect a number of things based on that, but maybe that was/is not the design goal. I said this before, but I am not sure we should interpret the argument of #/. I think that FileLocator root / 'foo' / 'bar' / 'readme.txt'. is more abstract (fitting to the original goal) then '/foo' asFileReference / 'bar/readme.txt'. because it totally avoids a reference to the platform dependent path separator. The same goes for '..' as (FileLocator root / 'foo' / 'bar' / 'down') parent / 'readme.txt'. is a more object oriented way to write '/foo/bar/down/../readme.txt', IMO. Windows is an important target for Pharo, they use $\ not $/. Do you see my point ? BTW, I consider the fact that current, '/foo' asFileReference / 'bar/readme.txt' works with #exists even though 'bar/readme.txt' was not fully parsed/resolved a bug, or a happy coincidence at best. Another point is the distinction between internal/external and/or concrete/abstract paths. Should something like '..' remain part of a path. Never, always, only when it can be resolved ? What about special characters ? Should we support ~ ? Sometimes I would like that too, but maybe FileLocator home is enough. All this being said, I think FileSystem can and should be improved, but carefully. It would be good if more people joined this discussion. Sven > On 26 Jun 2017, at 10:12, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Pharo's FileSystem behaviour is currently somewhat inconsistent in its > treatment of path strings. > > To be able to demonstrate the limitations and fixes, I'm assuming that > the following files and directories have been created (/dev/shm is a > memory based file system in Ubuntu): > > cd /dev/shm > mkdir -p d1/d2/d3/d4 > touch d1/t1.txt d1/d2/t2.txt d1/d2/d3/t3.txt d1/d2/d3/d4/t4.txt > pushd d1 && ln -s d2/d3 ./s3 && popd > > > > 1. Path's are canonicalised during initial creation, but are not when > extending the path, i.e. sending #/ > > E.g. > > '/dev/shm/d1/d2/../t1.txt' asFileReference " File @ /dev/shm/d1/t1.txt" > > '/dev/shm/d1/' asFileReference / 'd2/../t1.txt' " File @ /dev/shm/d1/d2/../t1.txt" > > Automatic canonicalisation is problematic as the code doesn't handle > symbolic links in the path name: > > ('/dev/shm/d1/' asFileReference / 's3/../t2.txt') exists " true (correct answer)" > > '/dev/shm/d1/s3/../t2.txt' asFileReference exists " false (wrong answer)" > > > 2. In an attempt to be completely general, the argument to #/ is assumed > to be a single directory / file. This is incorrect as the path > delimiter is not allowed to be part of the file name. The result is > that path comparisons and operations such as #parent give unexpected > results. > > E.g. > > ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') exists " true" > > ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') parent " File @ /dev/shm/d1" > > > My PR modified FileSystem so that: > > 1. Canonicalisation is separated out as an operation that has to be > manually requested: > > '/dev/shm/d1/d2/../t1.txt' asFileReference " File @ /dev/shm/d1/d2/../t1.txt" > > '/dev/shm/d1/d2/../t1.txt' asFileReference canonicalize " File @ /dev/shm/d1/t1.txt" > > > 2. The argument to #/ can be either a single file / directory name or a > path. > > ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') parent " File @ /dev/shm/d1/d2/d3" > > > > 3. Adds unit tests to cover the changed behaviour. > > > While I believe that these changes improve Pharo overall, making it more > intuitive and consistent, modifying the path creation to remove > canonicalisation is not backward compatible and requires a change to > PathTest>>testRelativeFromStringNormalization and > PathTest>>testRelativeFromStringNormalizationParent to manually > canonicalise the paths. > > Before I submit the patch, does anyone have any strong objections to the > changes as described above? > > Thanks, > Alistair >

June 27, 2017

Epicea feedback

by Jan BlizniÄenko

Hello I'd like to thank you for creating the Epicea. It is way more user-friendly and dependable than previous change-handling tool. Browsing, applying and reverting changes is way easier. Just one note: It is not exactly clear from first look how to properly reapply changes after an image has been closed without saving. If I select all changes I want to apply without using any filter, those changes are reapplied in wrong order (if I changed a method two times, first the new version is applied and then the old one). As far as I understood, I have to use filter to show only latest changes, but I think it could be clearer in the UI that I need to do so (or something completely different?) for applying changes. Thank you Jan -- View this message in context: http://forum.world.st/Epicea-feedback-tp4952661.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 27, 2017

Re: [Pharo-dev] WebTester project

by phil＠highoctane.be

Nicolas, It is still nice to have a thing that helps with web pages testing and that does not requires external libraries in order to work (even if limited in abilities). We have got Soup etc, but I have also been using this: https://github.com/ericchiang/pup and it is super powerful for scraping data. If one could wrap or port or remix it with Soup in Pharo it would be super cool. (let's dream and we also get a jq wrapper and all of it in Scale... > students someone?) Phil On Tue, Jun 27, 2017 at 10:51 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Nicolas, > > you can also checkout: > > http://smalltalkhub.com/#!/~TorstenBergmann/WebDriver > > This implements the JsonWireProtocol so it is not necessary to install > Java/Selenium and is > (hopefully) a cleaner implementation together with tests. Pharo only. > > Simple How to: > ============== > - The project is currently written and working for Windows platform (but > will be > platform independent later) > > - run > > Metacello new > configuration: 'WebDriver'; > smalltalkhubUser: 'TorstenBergmann' project: 'WebDriver'; > load. > > to load the project and all dependencies > > - Download ChromeDriver.exe and put it into the image directory > https://chromedriver.storage.googleapis.com/index.html?path=2.30/ > > You can also set a different location in "WebDriver" -> "Settings" > > - in the World menu choose "WebDriver" -> "ChromeDriver" -> "Run Chrome > Driver" > > - open a playground and run > > wd := WDWebDriver new. > wd url: 'http://www.pharo.org'. > wd screenshotForm inspect > > which should open a chrome window. > > It's not yet finished but if you like you can help completing it. > > Bye > T. > >

June 27, 2017

Re: [Pharo-dev] WebTester project

by Torsten Bergmann

Hi Nicolas, you can also checkout: http://smalltalkhub.com/#!/~TorstenBergmann/WebDriver This implements the JsonWireProtocol so it is not necessary to install Java/Selenium and is (hopefully) a cleaner implementation together with tests. Pharo only. Simple How to: ============== - The project is currently written and working for Windows platform (but will be platform independent later) - run Metacello new configuration: 'WebDriver'; smalltalkhubUser: 'TorstenBergmann' project: 'WebDriver'; load. to load the project and all dependencies - Download ChromeDriver.exe and put it into the image directory https://chromedriver.storage.googleapis.com/index.html?path=2.30/ You can also set a different location in "WebDriver" -> "Settings" - in the World menu choose "WebDriver" -> "ChromeDriver" -> "Run Chrome Driver" - open a playground and run wd := WDWebDriver new. wd url: 'http://www.pharo.org'. wd screenshotForm inspect which should open a chrome window. It's not yet finished but if you like you can help completing it. Bye T.

June 27, 2017

Re: [Pharo-dev] FileReference>>/ and path canonicalisation

by Stephane Ducasse

Thanks Alistair I'm buzzy and I was trying to learn how to integrate issues in Pharo 70 but so far I was too tired when pavel explained that to me. On Mon, Jun 26, 2017 at 10:12 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Pharo's FileSystem behaviour is currently somewhat inconsistent in its > treatment of path strings. > > To be able to demonstrate the limitations and fixes, I'm assuming that > the following files and directories have been created (/dev/shm is a > memory based file system in Ubuntu): > > cd /dev/shm > mkdir -p d1/d2/d3/d4 > touch d1/t1.txt d1/d2/t2.txt d1/d2/d3/t3.txt d1/d2/d3/d4/t4.txt > pushd d1 && ln -s d2/d3 ./s3 && popd > > > > 1. Path's are canonicalised during initial creation, but are not when > extending the path, i.e. sending #/ > > E.g. > > '/dev/shm/d1/d2/../t1.txt' asFileReference " File @ /dev/shm/d1/t1.txt" > > '/dev/shm/d1/' asFileReference / 'd2/../t1.txt' " File @ /dev/shm/d1/d2/../t1.txt" > > Automatic canonicalisation is problematic as the code doesn't handle > symbolic links in the path name: > > ('/dev/shm/d1/' asFileReference / 's3/../t2.txt') exists " true (correct answer)" > > '/dev/shm/d1/s3/../t2.txt' asFileReference exists " false (wrong answer)" > > > 2. In an attempt to be completely general, the argument to #/ is assumed > to be a single directory / file. This is incorrect as the path > delimiter is not allowed to be part of the file name. The result is > that path comparisons and operations such as #parent give unexpected > results. > > E.g. > > ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') exists " true" > > ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') parent " File @ /dev/shm/d1" > > > My PR modified FileSystem so that: > > 1. Canonicalisation is separated out as an operation that has to be > manually requested: > > '/dev/shm/d1/d2/../t1.txt' asFileReference " File @ /dev/shm/d1/d2/../t1.txt" > > '/dev/shm/d1/d2/../t1.txt' asFileReference canonicalize " File @ /dev/shm/d1/t1.txt" > > > 2. The argument to #/ can be either a single file / directory name or a > path. > > ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') parent " File @ /dev/shm/d1/d2/d3" > > > > 3. Adds unit tests to cover the changed behaviour. > > > While I believe that these changes improve Pharo overall, making it more > intuitive and consistent, modifying the path creation to remove > canonicalisation is not backward compatible and requires a change to > PathTest>>testRelativeFromStringNormalization and > PathTest>>testRelativeFromStringNormalizationParent to manually > canonicalise the paths. > > Before I submit the patch, does anyone have any strong objections to the > changes as described above? > > Thanks, > Alistair >

June 27, 2017

Re: [Pharo-dev] WebTester project

by Stephane Ducasse

Nicolas this is the one I mentioned that wraps selenium On Sun, Jun 25, 2017 at 4:55 PM, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> wrote: > nope :-( > > but it was fun anyway > > nicolas > > > On 25/06/2017 16:48, Max Leske wrote: > > Are you aware of the work that Johan did on Parasol > (https://github.com/SeasideSt/Parasol)? > > Max > > On 25 Jun 2017, at 16:45, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> > wrote: > > > Hi all, > > I developped a first version of a WebTestCase class. > > It uses SUnit and Zinc to get pages from the internet and test some > conditions on them. > > The main work is actually to offer higher level search facilities inspired > from what I saw in Selenium > > There is an example, that logs in and out of Github (and checks that we > logged in and out) > > --- > testLoginAndOutOfGitHub > | node | > self defaultUrl: 'http://github.com/'. > self getDefaultUrl. > > self assert: (self searchString: 'Sign in') notNil. > self clickLinkValue: 'Sign in'. > > self assert: (self searchString: 'Sign in to GitHub') notNil. > "5 fields to inform for login > 3 of them have values inside the login page: commit, utf8, > authenticity_token" > self enter: user forName: 'login'. > self enter: pass forName: 'password'. > self enterDefaultValueForName: 'commit'. > self enterDefaultValueForName: 'utf8'. > self enterDefaultValueForName: 'authenticity_token'. > "bug in the page, there is a </form> before the real <form ...>" > node := self searchNodeTag: 'form' afterNode: (self searchNodeTag: > 'form'). > self submitForm: node. > > "similar for signout, submit a form with 2 default values" > node := self searchFormOwning: (self searchString: 'Sign out'). > self enterDefaultValueForName: 'utf8'. > self enterDefaultValueForName: 'authenticity_token'. > self submitForm: node. > > "we are out" > self assert: (self searchString: 'Sign in') notNil. > --- > > No configOf or Catalog yet. I am too lazy > > can be found at: > > MCSmalltalkhubRepository > owner: 'nicolasAnquetil' > project: 'WebTest' > user: '' > password: '' > > > nicolas > > -- > Nicolas Anquetil -- MCF (HDR) > Project-Team RMod > > > > > -- > Nicolas Anquetil -- MCF (HDR) > Project-Team RMod

June 27, 2017