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

WebTester project

by Nicolas Anquetil

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

June 25, 2017

Re: [Pharo-dev] Recursively downloading Pharo packages / Building images with Nix

by Luke Gorrie

On 23 June 2017 at 18:56, Ben Coman <btc(a)openinworld.com> wrote: > But btw note, IIUC the bootstrap hasn't got a far as programatically > creating an empty file and writing nil,true,false to it yet (if ever?). > You will always be starting with a minimal.image rather than an empty.image. > This should be fine for me. I imagine importing some images as binaries and then writing a Nix expression to customize those e.g. adding packages, running some code, etc. Just for my own purposes I am not too concerned about bloat or bootstrapping. I would be fine to build on the standard Pharo 6 or Moose 6.1 image. I mostly want to add my own packages, and their dependencies, and make minor customizations (e.g. by default have the Spotter, etc, only show the application domain and not the Smalltalk universe.)

June 25, 2017

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

by Juraj Kubelka

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 25, 2017

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

by Yuriy Tymchuk

Hey Stef, Myroslava uses the preferences framework (as you can see in the screenshot). The question is how to programmatically persist a single preference (without the preference browser). Uko Sent from my iPhone > On 24 Jun 2017, at 21:18, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Why dont you use preferences (check the chapter in deep into pharo). > Preferences are managed across images. > Stef > >> On Sat, Jun 24, 2017 at 1:50 PM, Myroslava Romaniuk <romaniuk(a)ucu.edu.ua> wrote: >> 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: >> >> >> Any help or advice would be much appreciated. >> >> Regards, >> Myroslava. >

June 25, 2017

Re: [Pharo-dev] Recursively downloading Pharo packages / Building images with Nix

by Luke Gorrie

Hi Paul, On 23 June 2017 at 22:11, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > For those projects described with Metacello baselines or configurations you > can issue a #fetch command to download all the Monticello packages needed > to > load the projects into your image.... > Thanks for this idea! Could be that a "high-brow" approach based on Metacello metadata is an interesting alternative to a "low-brow" approach based on simply scraping the package-cache/ directory after installation. Here is what I would really like (restating from another mail): To make a dump of all available packages (restricting to ones with Metacello configurations is probably fine) and, for each package, to make a list of: - The mcz files required for installation (and any other downloded resources if there are some...?) - The sha256 hash of each mcz file (assume I can get this easily if the file is downloaded) - The URL where the file was downloaded from / should be downloaded from in the future Do you think this can be determined in a straightforward way from Metacello metadata?

June 25, 2017

Re: [Pharo-dev] Recursively downloading Pharo packages / Building images with Nix

by Luke Gorrie

On 23 June 2017 at 18:58, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Sane? Why introduce your own ftp directory? > Good question... Let me try a new iteration of the idea please. Here is what I _think_ I want: - For each package in the Catalog, the list of mcz files it requires to install. - For each mcz file, its expected sha256 hash and a basically stable download URL. So if I would use this algorithm: for each package P: empty the package cache install P inspect the package cache to discover dependencies Then I should be able to work out every mcz file required by each package, and I should be able to calculate the sha256 hashes of those mcz files too, but will I be able to determine a suitable download URL? I don't immediately see how and so one alternative would be to manufacture a URL by mirroring the file somewhere.

June 25, 2017

Re: [Pharo-dev] [Pharo-users] vested interest in PharoJS?

by Norbert Hartl

> Am 24.06.2017 um 21:37 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > Did you contact noury? > About what? I'm on the pharojs slack community and talk with Noury and Dave from time to time. Norbert >> On Thu, Jun 22, 2017 at 3:49 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Am 22.06.2017 um 13:57 schrieb Siemen Baader <siemenbaader(a)gmail.com>: >> >> Very cool, Norbert. I have been watching what you are doing at 2denker and >> thought you might be interested ;) >> >> What is holding you back - do you need more from PharoJS before starting to >> use it commercially, or are you waiting for a (paid) project before you can >> start? >> >> What is keeping me? A project and the feasibility. The amber project we >> could do because the project was more of a research project so I said "why >> not". For anything serious you need to check if it is feasible to use. And >> my trials with PharoJS were only little so I don't have the feeling, yet, if >> it is a huge benefit using it. But I feel a huge potential in it so it is on >> my list of things I wanna try but not on top. >> >> Norbert >> >> >> -- Siemen >> >>> On Thu, Jun 22, 2017 at 1:08 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> I thought I responded already. We are interested in pharoJS. We developed >>> stuff with amber but stopped using it. We have one app in the app store with >>> ionic and amber and I'd like to do another one with pharoJS. Additionally I >>> think that combining pharoJS with electron could be a nice thing to have in >>> order to create desktop apps. And finally I was shortly researching native >>> callouts from javascript with javascript core on ios and it seems you can do >>> pharo code, transpile to javascript that calls javascript functions which >>> are OS-native functions. >>> >>> Norbert >>> >>>> Am 14.06.2017 um 11:46 schrieb Siemen Baader <siemenbaader(a)gmail.com>: >>>> >>>> Hi all, >>>> >>>> Is anyone else interested in PharoJS and making it mature for their own >>>> commercial mobile and single page web app (and node.js) development? >>>> >>>> I think it has a huge potential because it brings the browser runtime >>>> and many libraries and online services from the JS world to us Smalltalkers >>>> while letting us keep our agile development and good CS practices. But it >>>> does not yet have the necessary features and documentation to work smoothly. >>>> >>>> -- Siemen >>> >> >>

June 24, 2017

Re: [Pharo-dev] New User and the Rectangle class.

by Stephane Ducasse

We spent several days fixing the complete system to avoid this crappy broken rectangle. Now it is time to deprecated this bad api. https://pharo.fogbugz.com/f/cases/20180/Deprecate-fractions-offsets-and-fra… On Sat, Jun 24, 2017 at 9:42 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Here is the comment > > fractions: fractionsOrNil > "Do not use this API if you do not have already have the rectangles > that should be passed as argument. > If you are creating the rectangles representing the numbers you need, > better use the accessors: > (LayoutFrame identity > topOffset: topHeight; > bottomFraction: 0; > bottomOffset: self buttonsBarHeight; > leftOffset: -1; > rightOffset: 1) > In particular > do not use (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)) but favor > LayoutFrame identity which is faster and more readable. > " > ^ self fractions: fractionsOrNil offsets: nil > > On Sat, Jun 24, 2017 at 9:38 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> Yes I thought that they were because they are a BAD design. >> No need to create dummy rectangle when you have a fully nice api. >> >> On Thu, Jun 22, 2017 at 3:48 PM, Trey Tomes <trey.tomes(a)gmail.com> wrote: >>> I did not know about the GitHub tutorial. I'll take a look for it. >>> >>> Will fraction:offset: be deprecated then you think? >>> >>> ~Trey >>> >>> On Thu, Jun 22, 2017 at 12:20 AM, Stephane Ducasse <stepharo.self(a)gmail.com> >>> wrote: >>>> >>>> Avoid fraction:offset: it is a bad interface. >>>> >>>> >>>> >>>> On Thu, Jun 22, 2017 at 7:20 AM, Stephane Ducasse >>>> <stepharo.self(a)gmail.com> wrote: >>>> > Welcome Trey >>>> > >>>> > This is nice. Did you see that we started long time ago to have a >>>> > version of the original tutorial on github to port it to Pharo. Feel >>>> > free to send pull requests. >>>> > >>>> > About this API. the old API was not good because it forced you to >>>> > create a bogus rectangle often for nothing >>>> > and also points for nothing. >>>> > It is better to use the accessors to set the value since a layoutFrame >>>> > is initialized first. >>>> > Have a look at the users of LayoutFrame or asLayoutFrame. >>>> > There is no raison to create a point 0@200 if you can just use the >>>> > correct accessors to set 200. >>>> > >>>> > stef >>>> > >>>> > >>>> > >>>> > On Wed, Jun 21, 2017 at 12:10 AM, Trey Tomes <trey.tomes(a)gmail.com> >>>> > wrote: >>>> >> Hello! >>>> >> >>>> >> I'm new to this list, so I apologize if this topic has already been >>>> >> considered. >>>> >> >>>> >> I have been re-creating the Laser Game tutorial in Pharo 6, and have >>>> >> encountered something that may be an error within Pharo. >>>> >> >>>> >> The LayoutFrame has the ability to use negative values for the bottom >>>> >> and >>>> >> right sides of the rectangle assigned to the offsets, e.g. >>>> >> >>>> >> LayoutFrame fraction: ((0@0 corner: (1@1)) offsets: ((4@4 corner: >>>> >> (-4@-4)). >>>> >> >>>> >> This is useful, as it allows the system to automatically calculate the >>>> >> margins inset from the bottom and right sides of the container. >>>> >> >>>> >> In Pharo 6, this does not work. The setLeft:right:top:bottom: and >>>> >> setPoint:point: messages both use the min: and max: messages to >>>> >> rearrange >>>> >> the Rectangle so that the smallest numbers get pushed to the top and >>>> >> left. >>>> >> >>>> >> In order to get things to render correctly in my system, I had to >>>> >> change >>>> >> these messages to look like this: >>>> >> >>>> >> setLeft: left right: right top: top bottom: bottom >>>> >> self setPoint: (left@top) point: (right@bottom). >>>> >> >>>> >> setPoint: pt1 point: pt2 >>>> >> origin := pt1. >>>> >> corner := pt2. >>>> >> >>>> >> >>>> >> In place of this: >>>> >> >>>> >> setLeft: left right: right top: top bottom: bottom >>>> >> origin := (left min: right) @ (top min: bottom). >>>> >> corner := (left max: right) @ (top max: bottom). >>>> >> >>>> >> setPoint: pt1 point: pt2 >>>> >> origin := (pt1 x min: pt2 x) @ (pt1 y min: pt2 y). >>>> >> corner := (pt1 x max: pt2 x) @ (pt1 y max: pt2 y). >>>> >> >>>> >> >>>> >> I haven't found any bad side-effects to changing this yet, but is there >>>> >> a >>>> >> reason the Rectangle class was changed? >>>> >> >>>> >> Thanks, >>>> >> Trey >>>> >>>

June 24, 2017

Re: [Pharo-dev] New User and the Rectangle class.

by Stephane Ducasse

Here is the comment fractions: fractionsOrNil "Do not use this API if you do not have already have the rectangles that should be passed as argument. If you are creating the rectangles representing the numbers you need, better use the accessors: (LayoutFrame identity topOffset: topHeight; bottomFraction: 0; bottomOffset: self buttonsBarHeight; leftOffset: -1; rightOffset: 1) In particular do not use (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)) but favor LayoutFrame identity which is faster and more readable. " ^ self fractions: fractionsOrNil offsets: nil On Sat, Jun 24, 2017 at 9:38 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Yes I thought that they were because they are a BAD design. > No need to create dummy rectangle when you have a fully nice api. > > On Thu, Jun 22, 2017 at 3:48 PM, Trey Tomes <trey.tomes(a)gmail.com> wrote: >> I did not know about the GitHub tutorial. I'll take a look for it. >> >> Will fraction:offset: be deprecated then you think? >> >> ~Trey >> >> On Thu, Jun 22, 2017 at 12:20 AM, Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >>> >>> Avoid fraction:offset: it is a bad interface. >>> >>> >>> >>> On Thu, Jun 22, 2017 at 7:20 AM, Stephane Ducasse >>> <stepharo.self(a)gmail.com> wrote: >>> > Welcome Trey >>> > >>> > This is nice. Did you see that we started long time ago to have a >>> > version of the original tutorial on github to port it to Pharo. Feel >>> > free to send pull requests. >>> > >>> > About this API. the old API was not good because it forced you to >>> > create a bogus rectangle often for nothing >>> > and also points for nothing. >>> > It is better to use the accessors to set the value since a layoutFrame >>> > is initialized first. >>> > Have a look at the users of LayoutFrame or asLayoutFrame. >>> > There is no raison to create a point 0@200 if you can just use the >>> > correct accessors to set 200. >>> > >>> > stef >>> > >>> > >>> > >>> > On Wed, Jun 21, 2017 at 12:10 AM, Trey Tomes <trey.tomes(a)gmail.com> >>> > wrote: >>> >> Hello! >>> >> >>> >> I'm new to this list, so I apologize if this topic has already been >>> >> considered. >>> >> >>> >> I have been re-creating the Laser Game tutorial in Pharo 6, and have >>> >> encountered something that may be an error within Pharo. >>> >> >>> >> The LayoutFrame has the ability to use negative values for the bottom >>> >> and >>> >> right sides of the rectangle assigned to the offsets, e.g. >>> >> >>> >> LayoutFrame fraction: ((0@0 corner: (1@1)) offsets: ((4@4 corner: >>> >> (-4@-4)). >>> >> >>> >> This is useful, as it allows the system to automatically calculate the >>> >> margins inset from the bottom and right sides of the container. >>> >> >>> >> In Pharo 6, this does not work. The setLeft:right:top:bottom: and >>> >> setPoint:point: messages both use the min: and max: messages to >>> >> rearrange >>> >> the Rectangle so that the smallest numbers get pushed to the top and >>> >> left. >>> >> >>> >> In order to get things to render correctly in my system, I had to >>> >> change >>> >> these messages to look like this: >>> >> >>> >> setLeft: left right: right top: top bottom: bottom >>> >> self setPoint: (left@top) point: (right@bottom). >>> >> >>> >> setPoint: pt1 point: pt2 >>> >> origin := pt1. >>> >> corner := pt2. >>> >> >>> >> >>> >> In place of this: >>> >> >>> >> setLeft: left right: right top: top bottom: bottom >>> >> origin := (left min: right) @ (top min: bottom). >>> >> corner := (left max: right) @ (top max: bottom). >>> >> >>> >> setPoint: pt1 point: pt2 >>> >> origin := (pt1 x min: pt2 x) @ (pt1 y min: pt2 y). >>> >> corner := (pt1 x max: pt2 x) @ (pt1 y max: pt2 y). >>> >> >>> >> >>> >> I haven't found any bad side-effects to changing this yet, but is there >>> >> a >>> >> reason the Rectangle class was changed? >>> >> >>> >> Thanks, >>> >> Trey >>> >>

June 24, 2017

Re: [Pharo-dev] New User and the Rectangle class.

by Stephane Ducasse

Yes I thought that they were because they are a BAD design. No need to create dummy rectangle when you have a fully nice api. On Thu, Jun 22, 2017 at 3:48 PM, Trey Tomes <trey.tomes(a)gmail.com> wrote: > I did not know about the GitHub tutorial. I'll take a look for it. > > Will fraction:offset: be deprecated then you think? > > ~Trey > > On Thu, Jun 22, 2017 at 12:20 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Avoid fraction:offset: it is a bad interface. >> >> >> >> On Thu, Jun 22, 2017 at 7:20 AM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >> > Welcome Trey >> > >> > This is nice. Did you see that we started long time ago to have a >> > version of the original tutorial on github to port it to Pharo. Feel >> > free to send pull requests. >> > >> > About this API. the old API was not good because it forced you to >> > create a bogus rectangle often for nothing >> > and also points for nothing. >> > It is better to use the accessors to set the value since a layoutFrame >> > is initialized first. >> > Have a look at the users of LayoutFrame or asLayoutFrame. >> > There is no raison to create a point 0@200 if you can just use the >> > correct accessors to set 200. >> > >> > stef >> > >> > >> > >> > On Wed, Jun 21, 2017 at 12:10 AM, Trey Tomes <trey.tomes(a)gmail.com> >> > wrote: >> >> Hello! >> >> >> >> I'm new to this list, so I apologize if this topic has already been >> >> considered. >> >> >> >> I have been re-creating the Laser Game tutorial in Pharo 6, and have >> >> encountered something that may be an error within Pharo. >> >> >> >> The LayoutFrame has the ability to use negative values for the bottom >> >> and >> >> right sides of the rectangle assigned to the offsets, e.g. >> >> >> >> LayoutFrame fraction: ((0@0 corner: (1@1)) offsets: ((4@4 corner: >> >> (-4@-4)). >> >> >> >> This is useful, as it allows the system to automatically calculate the >> >> margins inset from the bottom and right sides of the container. >> >> >> >> In Pharo 6, this does not work. The setLeft:right:top:bottom: and >> >> setPoint:point: messages both use the min: and max: messages to >> >> rearrange >> >> the Rectangle so that the smallest numbers get pushed to the top and >> >> left. >> >> >> >> In order to get things to render correctly in my system, I had to >> >> change >> >> these messages to look like this: >> >> >> >> setLeft: left right: right top: top bottom: bottom >> >> self setPoint: (left@top) point: (right@bottom). >> >> >> >> setPoint: pt1 point: pt2 >> >> origin := pt1. >> >> corner := pt2. >> >> >> >> >> >> In place of this: >> >> >> >> setLeft: left right: right top: top bottom: bottom >> >> origin := (left min: right) @ (top min: bottom). >> >> corner := (left max: right) @ (top max: bottom). >> >> >> >> setPoint: pt1 point: pt2 >> >> origin := (pt1 x min: pt2 x) @ (pt1 y min: pt2 y). >> >> corner := (pt1 x max: pt2 x) @ (pt1 y max: pt2 y). >> >> >> >> >> >> I haven't found any bad side-effects to changing this yet, but is there >> >> a >> >> reason the Rectangle class was changed? >> >> >> >> Thanks, >> >> Trey >> >

June 24, 2017