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

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

by Andrei Chis

Yes these numbers should be refactored For collections only the first and the last 21 elements are displayed in the Raw view. Don't remember why 21. Cheers, Andrei On Fri, Feb 3, 2017 at 3:13 AM, Ben Coman <btc(a)openinworld.com> wrote: > Just curious what the magic numbers here relate to... > and can they be factored out to a meaningful method name? > > Context>>gtInspectorVariableValuePairs > "This is a helper method that returns a collection of > variable_name -> value > for the current object. > Subclasses can override it to specialize what appears in the variables > presentation" > | bindings | > bindings := OrderedCollection new. > 1 to: (self basicSize min: 21) do: [ :index | > bindings add: (index "asString""asTwoCharacterString" -> (self basicAt: > index)) ]. > ((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index | "self > haltIf: [ index = 99 ]." > bindings add: (index "asString" -> (self basicAt: index)) ]. > bindings > addAll: ((self class allSlots > collect: [ :slot | slot name -> (slot read: self) ]) sort > asOrderedCollection). > ^ bindings > > > cheers -ben >

Feb. 3, 2017

Re: [Pharo-dev] Pharo 6 update catalog entries

by Sven Van Caekenberghe

> On 3 Feb 2017, at 13:48, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > On 03/02/2017 13:41, Sven Van Caekenberghe wrote: >> Thanks for report this, Cyril, it should be fixed in version 2.8.2 > > That was fast, thank you. Well, the bug report was very clear, it even included the solution, and I know I can trust you, so basically did what you said ;-) > I confirm it work now. Excellent. > -- > Cyril Ferlicot > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France >

Feb. 3, 2017

Re: [Pharo-dev] PharoLauncher create image / default image name

by Peter Uhnak

> PharoLauncher-Core-ChristopheDemarey.100 Thanks! > If some still prefer the old naming, maybe the best way would be to have an option to choose the naming strategy. Unless there is a critical mass of people it's imho needless clutter in the codebase; I can patch it myself locally. For me Pharo code = configuration. :) Peter

Feb. 3, 2017

Re: [Pharo-dev] Pharo 6 update catalog entries

by Cyril Ferlicot D.

On 03/02/2017 13:41, Sven Van Caekenberghe wrote: > Thanks for report this, Cyril, it should be fixed in version 2.8.2 > > That was fast, thank you. I confirm it work now. -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Feb. 3, 2017

[pharo-project/pharo-core] b13be4: 60372

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: b13be4e6152f99bf840d5973b24a2afb231a9b08 https://github.com/pharo-project/pharo-core/commit/b13be4e6152f99bf840d5973… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-03 (Fri, 03 Feb 2017) Changed paths: M Morphic-Widgets-FastTable.package/FTRootItem.class/instance/expanding-collapsing/collapseAll.st M Morphic-Widgets-FastTable.package/FTRootItem.class/instance/expanding-collapsing/expandAll.st M Morphic-Widgets-FastTable.package/FTRootItem.class/instance/expanding-collapsing/expandAllTo_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60371.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60372.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60371.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60372.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60372 19651 showing a progress dialog each time I want to make an expandAll is incorrect https://pharo.fogbugz.com/f/cases/19651 http://files.pharo.org/image/60/60372.zip

Feb. 3, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60372 Home: https://github.com/pharo-project/pharo-core

Feb. 3, 2017

Re: [Pharo-dev] Pharo 6 update catalog entries

by Sven Van Caekenberghe

Thanks for report this, Cyril, it should be fixed in version 2.8.2 > On 3 Feb 2017, at 13:36, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > On 02/02/2017 17:18, Sven Van Caekenberghe wrote: >> Good idea, Torsten! >> >> I updated the following (with new #stable releases and catalog configs for Pharo 3,4,5 & 6): >> >> - NeoCSV >> - NeoJSON >> - Ston >> - ZTimestamp >> - Stamp >> - ZincHTTPComponents >> - Zodiac >> - WebSockets >> - Zinc SSO >> >> These were already running 6.0 builds on the CI servers. >> >> Sven >> >> > > Hi Sven, > > There is an error for the ZincHTTPComponents one in > ConfigurationOfZincHTTPComponents>>#version281: > > `package: 'Zinc-Seaside' with: 'Zinc-Seaside-JohanBrichau.46'` > > should be > > `package: 'Zinc-Seaside' with: 'Zinc-Seaside-SvenVanCaekenberghe.46'` > > > It breaks Seaside of Pharo 5-6. > > Thank you for the updates! > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France

Feb. 3, 2017

Re: [Pharo-dev] Pharo 6 update catalog entries

by Cyril Ferlicot D.

On 02/02/2017 17:18, Sven Van Caekenberghe wrote: > Good idea, Torsten! > > I updated the following (with new #stable releases and catalog configs for Pharo 3,4,5 & 6): > > - NeoCSV > - NeoJSON > - Ston > - ZTimestamp > - Stamp > - ZincHTTPComponents > - Zodiac > - WebSockets > - Zinc SSO > > These were already running 6.0 builds on the CI servers. > > Sven > > Hi Sven, There is an error for the ZincHTTPComponents one in ConfigurationOfZincHTTPComponents>>#version281: `package: 'Zinc-Seaside' with: 'Zinc-Seaside-JohanBrichau.46'` should be `package: 'Zinc-Seaside' with: 'Zinc-Seaside-SvenVanCaekenberghe.46'` It breaks Seaside of Pharo 5-6. Thank you for the updates! -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Feb. 3, 2017

Re: [Pharo-dev] PharoLauncher create image / default image name

by Christophe Demarey

Hi, Yes, I changed it on purpose after a small survey of people in the mod group. The old naming was very annoying, especially with some templates coming from Jenkins. If some still prefer the old naming, maybe the best way would be to have an option to choose the naming strategy. Christophe > Le 3 fÃ©vr. 2017 Ã 12:34, Peter Uhnak <i.uhnak(a)gmail.com> a Ã©crit : > > I was also looking at this, but couldn't figure out how to change it back, > > Do you know in what specific commit this happened? > > (I prefer the old naming, since it included context and I knew whether the image was Pharo or Moose). > > Thanks, > Peter > > On Wed, Feb 01, 2017 at 08:23:33PM +0100, Cyril Ferlicot D. wrote: >> Le 01/02/2017 Ã 20:18, Nicolai Hess a Ã©crit : >>> I started to use a more recent version of pharo launcher, and somehow it >>> changed how it creates the default image name when creating a new image. >>> For example, select an entry from "Pharo 6.0 (beta)" template, the old >>> behavior sets the default name to >>> Pharo 6.0 (beta) - 60353 >>> but now, the template name is omitted, it only sets >>> 60535 >>> >>> was this change on purpose ? I can not find an issue about this on >>> https://github.com/pharo-project/pharo-launcher/issues >>> >>> (I actually don't care much about which format to use, it is just that >>> all my images I used from the prior version, and the new one now appear >>> on different positions in the images list) >>> >>> nicolai >> >> Hi, >> >> This change was made by Christophe I think and was in purpose. >> >> Template name before: Name of the "location" (ex: Common Tools, Pharo >> Contribution Jenkins, Pharo 6.0â¦) - Name of the build >> >> Now: Name of the build >> >> -- >> Cyril Ferlicot >> >> http://www.synectique.eu >> >> 2 rue Jacques PrÃ©vert 01, >> 59650 Villeneuve d'ascq France >> > > > >

Feb. 3, 2017

Re: [Pharo-dev] Zinc / REST misunderstanding

by Nicolas Anquetil

great I will not have time to look at it today, but I will definitely follow your suggestions, especially the contentReader:/contentWriter: part, coupled with JSON thanks again nicolas On 02/02/2017 18:29, Sven Van Caekenberghe wrote: > Well, now that it works, we can make it better ;-) > > This is a more correct way to do your call: > > ZnClient new > beOneShot; > contentWriter: [ :data | ZnEntity > with: (STONJSON toString: data ) > type: ZnMimeType applicationJson ]; > url: 'http://server.com/redmine/issues/430.json'; > username: 'anquetil' password: '<mypasswd>'; > contents: { #issue -> { > #subject -> 'Subject different changed'. > #notes -> 'The subject was changed changed' } asDictionary } asDictionary; > put. > > It is all in one expression now, but there normally is a common configuration part for the ZnClient, and then a part that is different for each call. #contentWriter: is part of the configuration, while #contents: is your data. The content writer takes your data in as objects and turns it into a typed entity. (There is also a corresponding #contentReader: that you can use to parse JSON coming back, if necessary). > > Sven > >> On 2 Feb 2017, at 17:31, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> wrote: >> >> >> Hi >> >> thanks Sven, it now works. >> >> from your answer, I could infer the final solution. Apart from your suggestions, the content-type: also had to be called on ZnClient and voila! >> >> nicolas >> >> >> On 02/02/2017 17:11, Sven Van Caekenberghe wrote: >>>> On 2 Feb 2017, at 16:51, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> wrote: >>>> >>>> >>>> Hi, >>>> >>>> I am trying to create a small Redmine wrapper with Zinc, using Redmine REST API >>>> >>>> And I am having a problem to update issues in redmine from zinc. >>>> In curl, I can do: >>>> >>>> curl -v -H "Content-Type: application/json" -X PUT --data-binary '{ >>>> "issue": { >>>> "subject": "Subject different changed", >>>> "notes": "The subject was changed changed" >>>> } >>>> }' -u anquetil:<mypasswd> http://<theserver>/redmine/issues/430.json >>>> and this updates issue #430 by changing its subject and notes. >>>> >>>> For information, the trace given by curl (-v) is: >>>> >>>> * Trying <theserver>... >>>> % Total % Received % Xferd Average Speed Time Time Time Current >>>> Dload Upload Total Spent Left Speed >>>> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to <theserver> (<theserver>) port 80 (#0) >>>> * Server auth using Basic with user 'anquetil' >>>>> PUT /redmine/issues/430.json HTTP/1.1 >>>>> Host: <theserver> >>>>> Authorization: Basic YW5xdWV0aWw6UjNkTTFuMy1wYXNz >>>>> User-Agent: curl/7.47.0 >>>>> Accept: */* >>>>> Content-Type: application/json >>>>> Content-Length: 110 >>>>> >>>> } [110 bytes data] >>>> * upload completely sent off: 110 out of 110 bytes >>>> 100 110 0 0 100 110 0 546 --:--:-- --:--:-- --:--:-- 544< HTTP/1.1 200 OK >>>> < Date: Thu, 02 Feb 2017 12:18:41 GMT >>>> < Server: Apache/2.2.22 (Ubuntu) >>>> < X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.21 >>>> < X-Rack-Cache: invalidate, pass >>>> < X-Request-Id: 73f75565... >>>> < X-UA-Compatible: IE=Edge,chrome=1 >>>> < Cache-Control: no-cache >>>> < X-Runtime: 0.994081 >>>> < Set-Cookie: _redmine_session=BAh7ByIP...; path=/; HttpOnly >>>> < Set-Cookie: autologin=; path=/; expires=Thu, 01-Jan-1970 00:00:00 GMT >>>> < Status: 200 >>>> < Content-Length: 0 >>>> < Content-Type: application/json; charset=utf-8 >>>> < >>>> 100 110 0 0 100 110 0 105 0:00:01 0:00:01 --:--:-- 105 >>>> * Connection #0 to host <theserver> left intact >>>> The problem is that I cannot replicate that with Zinc: >>>> >>>> cont := '{ >>>> "issue": { >>>> "subject": "Subject different changed", >>>> "notes": "The subject was changed changed" >>>> } >>>> }'. >>>> ent := ((ZnHeaders requestHeadersFor: 'http://<theserver>/redmine/' asZnUrl ) >>>> contentType: (ZnMimeType main: 'application' sub: 'json')) ; >>>> contentLength: cont size. >>>> ZnClient new >>>> beOneShot ; >>>> entity: ent ; >>>> username: 'anquetil' password: '<mypasswd>' ; >>>> put: 'http://<theserver>/redmine/issues/430.json' contents: cont ; >>>> response. >>> You are doing something double (ent & cont are the same). Also, I usually start by setting the URL and continue from there. Could you try: >>> >>> ZnClient new >>> beOneShot ; >>> url: 'http://<theserver>/redmine/issues/430.json' ; >>> entity: ent ; >>> username: 'anquetil' password: '<mypasswd>' ; >>> put ; >>> yourself. >>> >>> I would inspect the instance so you can see both the request and response. >>> >>> Does this work ? >>> >>> Also, the JSON can be generated from objects instead of being written as a string, but you knew that, right ? >>> >>>> if I inspect the ZnHeader constructed, it seems to have all headers that curl traces except the Authorization: Basic one: >>>> >>>> <cicgeiiljjcidaam.png> >>>> >>>> The response of ZnClient is "200 OK", with again the same headers as reported by curl >>>> >>>> <mjlnpnjhhegjmhnl.png> >>>> >>>> Yet the issue remains unchanged on the redmine server (contrary to curl evidently) >>>> >>>> Can anyone explain where the error could be ? >>>> Any help will be gladly welcome >>>> >>>> nicolas >>>> >>>> -- >>>> Nicolas Anquetil -- MCF (HDR) >>>> Project-Team RMod >>>> >> -- >> Nicolas Anquetil -- MCF (HDR) >> Project-Team RMod >> >> > -- Nicolas Anquetil -- MCF (HDR) Project-Team RMod

Feb. 3, 2017