date:20170203

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

2017-02-03 Thread Dimitris Chloupis

All my projects must be Pharo 6 ready because most of them were created
inside Pharo 6 anyway. But thanks for the reminder . Time to make sure they
work as expected.
On Fri, 3 Feb 2017 at 15:06, Sven Van Caekenberghe  wrote:

> On 3 Feb 2017, at 13:48, Cyril Ferlicot D. 
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
>

Re: [Pharo-dev] PharoSpur32Vm

2017-02-03 Thread Nicolai Hess

2017-02-04 1:44 GMT+01:00 Nicolai Hess :

>
>
> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano :
>
>>
>> On 22 Jan 2017, at 13:19, Nicolai Hess  wrote:
>>
>>
>>
>> 2017-01-22 10:21 GMT+01:00 Clément Bera :
>>
>>> Hi,
>>>
>>> I believe they're built from* https://github.com/OpenSmalltalk/vm
>>> * using travis and appveyor. On
>>> the gitbhub readme there are relevant links. All built artifacts are also
>>> kept on bintray for history.
>>>
>>>
>>>
>> Thank you!
>>
>>
>> no, they aren’t :)
>> instead, they are built here: https://github.com/pharo-project/pharo-vm
>>
>> (README still not updated)
>>
>
> what did changed ? I am not able to build the vm on windows anymore
> (something wrong with generating the generator.image, I'll now reset my
> local pharo-vm build directory and see if it works afterwards).
>

see attached the stderr log :

'Errors in script loaded from u:\github\pharo-vm\scripts\LoadVMMaker.st'
[31mMessageNotUnderstood: receiver of "default:" is nil
[0mUndefinedObject(Object)>>doesNotUnderstand: #default:
BaseSoundSystem class>>initialize
MCMethodDefinition>>postloadOver:




> Are we still working with branch spur-64, or are we back on master ?
>
>
>
>>
>> Esteban
>>
>>
>>
>>>
>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess 
>>> wrote:
>>>
 Where are the latest Pharo-spur-vms (32bit) are built?
 I don't see them on the build server, only the buildresults at
 http://files.pharo.org/vm/pharo-spur32/linux/

 The latest builds on the buildserver are from the last year only.

 nicolai

>>>
>>>
>>
>>
>


stderr
Description: Binary data

Re: [Pharo-dev] PharoSpur32Vm

2017-02-03 Thread Nicolai Hess

2017-01-23 8:59 GMT+01:00 Esteban Lorenzano :

>
> On 22 Jan 2017, at 13:19, Nicolai Hess  wrote:
>
>
>
> 2017-01-22 10:21 GMT+01:00 Clément Bera :
>
>> Hi,
>>
>> I believe they're built from* https://github.com/OpenSmalltalk/vm
>> * using travis and appveyor. On the
>> gitbhub readme there are relevant links. All built artifacts are also kept
>> on bintray for history.
>>
>>
>>
> Thank you!
>
>
> no, they aren’t :)
> instead, they are built here: https://github.com/pharo-project/pharo-vm
>
> (README still not updated)
>

what did changed ? I am not able to build the vm on windows anymore
(something wrong with generating the generator.image, I'll now reset my
local pharo-vm build directory and see if it works afterwards).
Are we still working with branch spur-64, or are we back on master ?



>
> Esteban
>
>
>
>>
>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess 
>> wrote:
>>
>>> Where are the latest Pharo-spur-vms (32bit) are built?
>>> I don't see them on the build server, only the buildresults at
>>> http://files.pharo.org/vm/pharo-spur32/linux/
>>>
>>> The latest builds on the buildserver are from the last year only.
>>>
>>> nicolai
>>>
>>
>>
>
>

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

2017-02-03 Thread Aliaksei Syrel

They could be extracted to class vars for example TWENTY_ONE := 21. Later
if performance is still not good enough they may be changed for example to
TWENTY_ONE := 15.
(joke)

Cheers,
Alex

On 3 February 2017 at 17:08, Tudor Girba  wrote:

> There is very little meaning behind the number.
>
> The previous inspector showed the first 100 and the last 10 elements. 100
> is anyway too large for a quick inspection, so we picked another number. I
> wanted 42 but that was still large, so we are now at 21.
>
> Doru
>
>
> > On Feb 3, 2017, at 4:20 PM, Andrei Chis 
> wrote:
> >
> > 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  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
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Beauty is where we see it."
>
>
>
>
>
>

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

2017-02-03 Thread Tudor Girba

There is very little meaning behind the number.

The previous inspector showed the first 100 and the last 10 elements. 100 is 
anyway too large for a quick inspection, so we picked another number. I wanted 
42 but that was still large, so we are now at 21.

Doru


> On Feb 3, 2017, at 4:20 PM, Andrei Chis  wrote:
> 
> 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  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
> 

--
www.tudorgirba.com
www.feenk.com

"Beauty is where we see it."

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

2017-02-03 Thread 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  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
>

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

2017-02-03 Thread Sven Van Caekenberghe


> On 3 Feb 2017, at 13:48, Cyril Ferlicot D.  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
>

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

2017-02-03 Thread 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

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

2017-02-03 Thread 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



signature.asc
Description: OpenPGP digital signature

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

2017-02-03 Thread 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.  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

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

2017-02-03 Thread GitHub

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: b13be4e6152f99bf840d5973b24a2afb231a9b08
  
https://github.com/pharo-project/pharo-core/commit/b13be4e6152f99bf840d5973b24a2afb231a9b08
  Author: Jenkins Build Server 
  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

[Pharo-dev] [pharo-project/pharo-core]

2017-02-03 Thread GitHub

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

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

2017-02-03 Thread 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



signature.asc
Description: OpenPGP digital signature

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

2017-02-03 Thread 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  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
>> 
> 
> 
> 
>

Re: [Pharo-dev] Zinc / REST misunderstanding

2017-02-03 Thread 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: '';
   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  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  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: http:///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 ...
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* Connected 
to  () port 80 (#0)
* Server auth using Basic with user 'anquetil'

PUT /redmine/issues/430.json HTTP/1.1
Host: 
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   1100 0  100   110  0546 --:--:-- --:--:-- --:--:--   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   1100 0  100   110  0105  0:00:01  0:00:01 --:--:--   105
* Connection #0 to host  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:///redmine/' asZnUrl )
 contentType: (ZnMimeType main: 'application' sub: 'json')) ;
 contentLength: cont size.
 ZnClient new
 beOneShot ;
 entity: ent ;
 username: 'anquetil' password: '' ;
 put: 'http:///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:///redmine/issues/430.json' ;
 entity: ent ;
 username: 'anquetil' password: '' ;
 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:



The response of ZnClient is "200 OK", with again the same headers as reported 
by curl



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

[Pharo-dev] [pharo-project/pharo-core] 3e046e: 50768

2017-02-03 Thread GitHub

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 3e046ef0045f650761884511f756c714e65a31a4
  
https://github.com/pharo-project/pharo-core/commit/3e046ef0045f650761884511f756c714e65a31a4
  Author: Jenkins Build Server 
  Date:   2017-02-03 (Fri, 03 Feb 2017)

  Changed paths:
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50767.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50768.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50767.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50768.st
M 
ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M 
Settings-Polymorph.package/PolymorphSystemSettings.class/class/morphic/morphicMenuSettingsOn_.st

  Log Message:
  ---
  50768
19623 System Settings has "Menues" instead of "Menu"
https://pharo.fogbugz.com/f/cases/19623

http://files.pharo.org/image/50/50768.zip

[Pharo-dev] [pharo-project/pharo-core]

2017-02-03 Thread GitHub

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

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

2017-02-03 Thread Nicolai Hess

Am 03.02.2017 12:35 nachm. schrieb "Peter Uhnak" :

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?

PharoLauncher-Core-ChristopheDemarey.100



(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
>

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

2017-02-03 Thread Peter Uhnak

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
>

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

Re: [Pharo-dev] PharoSpur32Vm

Re: [Pharo-dev] PharoSpur32Vm

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

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

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

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

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

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

[Pharo-dev] [pharo-project/pharo-core]

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

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

Re: [Pharo-dev] Zinc / REST misunderstanding

[Pharo-dev] [pharo-project/pharo-core] 3e046e: 50768

[Pharo-dev] [pharo-project/pharo-core]

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

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

19 matches

Site Navigation

Mail list logo

Footer information