June 2017 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Esteban's ChangeLog week of 19 June 2017

by Francisco Ortiz PeÃ±aloza

Great news Esteban, thanks! On Mon, Jun 26, 2017 at 10:40 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Mon, Jun 26, 2017 at 2:00 PM, <estebanlm(a)gmail.com> wrote: > >> Hello! >> >> This is my weekly ChangeLog, from 19 June 2017 to 25 June 2017. >> You can see it in a better format by going here: >> http://log.smallworks.eu/web/search?from=19/6/2017&to=25/6/2017 >> >> ChangeLog >> ========= >> >> 21 June 2017: >> ------------- >> >> * Succeed!! >> >> I made [iceberg](http://github.com/pharo-vcs/iceberg) to work on >> 64bits! >> >> Now, I need to promote a new VM as stable (and probably backported it >> to Pharo 6.0) >> >> * After 1.5 days still working on 64bits version of [iceberg]( >> http://github.com/pharo-vcs/iceberg) and that >> annoying malloc crash. Last idea was the believing something is wrong >> with sizes and marshallings so I >> verified all: >> >> * I reviewed all structures and callbacks. >> * I took a look to each function call. >> >> I got some differences that needed to be fixed and perticularly a lot >> of +size_t+ that were wrongly >> mapped as +FFIUInt32+ and I have some movement: it is not crashing >> anymore on malloc (which is a >> relief), but is still crashing someplace later. > > > Great news. Thanks for your persistence. > > cheers -ben > > P.S. And shows the benefit in an open source project of having paid > engineers to work on the hard stuff. >

June 26, 2017

Re: [Pharo-dev] Saving a setting in Pharo

by Myroslava Romaniuk

Thanks Juraj, it should be exactly what I need. I'll check it out. On 25 June 2017 at 13:36, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > Hi Myroslava, > > it should be possible by > > SystemSettingsPersistence storeIdentifier: #settingId > > Maybe the easiest way to pick your id is to look at the setting file. I do > not remember how it is generated. > > There are a few more methods, depending on what object you have in hand. > Check storing protocol. > > Regards, > Juraj > > > El 24-06-2017, a las 13:50, Myroslava Romaniuk <romaniuk(a)ucu.edu.ua> > escribiÃ³: > > > > For my GSoC project I've been working on the rule toggle so I created a > setting that bans a rule for the whole image. > > > > But I'm thinking that some of you might want to disable a certain rule > for all the following images too. > > > > Hence my question: how to save a setting programatically so that the > same setting would immediately work for the next image as well? > > > > For now I only know how to do it manually but I need a more elegant way > to do this: > > <image.png> > > > > Any help or advice would be much appreciated. > > > > Regards, > > Myroslava. > > > -- Ð Ð¿Ð¾Ð²Ð°Ð³Ð¾Ñ, ÐÐ¸ÑÐ¾ÑÐ»Ð°Ð²Ð° Ð Ð¾Ð¼Ð°Ð½ÑÐº.

June 26, 2017

[ANN] Dates Pharo Sprints

by Marcus Denker

Hi, I have added Events for all the next Pharo Sprint Dates in the Events page: https://association.pharo.org/events There is one for each month with the exception of August (holidays, ESUG the week after). Marcus

June 26, 2017