yeah, real solution is to remove GTSpotterEventRecorderSettings and use the Settings framework. AFAIK, guys in GTools team are already working on it :) Esteban

On 18 Mar 2015, at 03:20, Ben Coman <btc@openInWorld.com> wrote:

Thanks Nicolai. I tried your suggestion but running the CI tests then crashes the VM. I'll gather more info. cheers -ben

On Wed, Mar 18, 2015 at 7:12 AM, Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote: 2015-03-17 18:29 GMT+01:00 Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>>:

Currently the image the monkey uses to validate issues is 9 days old - which might be a problem if your bug fix today depends on or conflicts with something integrated a week ago.

I have somewhat isolated the problem to a Rubric/GTTools update, but nothing looks obvious from the package level. Its time for bed, so I haven't dug into code changes yet, but could someone from the Glamorous Team familiar with the changes for Issue 15018 take a look?

https://pharo.fogbugz.com/default.asp?15018 <https://pharo.fogbugz.com/default.asp?15018>

https://pharo.fogbugz.com/default.asp?15127 <https://pharo.fogbugz.com/default.asp?15127>

cheers -ben

possible fix: GTSpotterEventRecorderSettings only read/write preference file if this startUp is a real image start up / booting.

startUp: resuming resuming ifFalse:[ ^ self]. "We reset image preferences, because this is likely a newly downloaded image or different user and he/she should agree about sending data." self preferences exists ifFalse: [ self reset ]. self loadPreferences.

Hi, The show stopper is due to the fact that we would like to store a unique id for the computer to be able to track the data (kind of a cookie). This is what is being written on the file system (however, no information is being sent without the explicit consent). Cheers, Doru On Wed, Mar 18, 2015 at 10:55 AM, Andrei Chis <chisvasileandrei@gmail.com> wrote:

The current version from the moose repo uses the settings browser. However, with the current mechanism for exporting setting people using Moose and Pharo images will not be able to export their sendUsageData setting. That mechanism is really broken ( http://forum.world.st/Exporting-Setting-preferences-tc4812327.html)

Cheers, Andrei

On Wed, Mar 18, 2015 at 9:03 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

yeah, real solution is to remove GTSpotterEventRecorderSettings and use the Settings framework. AFAIK, guys in GTools team are already working on it :)

Esteban

On 18 Mar 2015, at 03:20, Ben Coman <btc@openInWorld.com> wrote:

Thanks Nicolai. I tried your suggestion but running the CI tests then crashes the VM. I'll gather more info. cheers -ben

On Wed, Mar 18, 2015 at 7:12 AM, Nicolai Hess <nicolaihess@web.de> wrote:

...

2015-03-17 18:29 GMT+01:00 Ben Coman <btc@openinworld.com>:

...

Currently the image the monkey uses to validate issues is 9 days old - which might be a problem if your bug fix today depends on or conflicts with something integrated a week ago.

I have somewhat isolated the problem to a Rubric/GTTools update, but nothing looks obvious from the package level. Its time for bed, so I haven't dug into code changes yet, but could someone from the Glamorous Team familiar with the changes for Issue 15018 take a look?

https://pharo.fogbugz.com/default.asp?15018

https://pharo.fogbugz.com/default.asp?15127

cheers -ben

possible fix: GTSpotterEventRecorderSettings only read/write preference file if this startUp is a real image start up / booting.

startUp: resuming resuming ifFalse:[ ^ self]. "We reset image preferences, because this is likely a newly downloaded image or different user and he/she should agree about sending data." self preferences exists ifFalse: [ self reset ]. self loadPreferences.

-- www.tudorgirba.com "Every thing has its own flow"

another thing: we are 14 days from release. if you cannot provide a version that actually works without generating undesirable effects, then the right solution is to disable that functionality and wait for Pharo 5 to add it (with enough time to do it properly). do not get me wrong: I *do want* everything in image and working, but well, with the stress of the latests days… We need to be prepared to take some drastic things (we already delayed some important things… we can delay others) Esteban

On 18 Mar 2015, at 13:22, Esteban Lorenzano <estebanlm@gmail.com> wrote:

honestly, what misses completely the point is the idea of reading and saving your preferences each time the image is open. this is not java, we do not have a stateless environment… once you have it in the image and your image is save, there is no point on save/restore outside (which is what you are doing with that hand-made settings stuff).

this:

startUp: resuming "We reset image preferences, because this is likely a newly downloaded image or different user and he/she should agree about sending data." self preferences exists ifFalse: [ self reset ]. self loadPreferences.

loads your preferences (ideally always the same) each time you save the image (not just each time you open it, which is already BAD, but each time you do a save).

I’m still waiting for a quick replacement, because it is braking a lot of things for me: the CI building, the spur building, etc.

cheers, Esteban

...

On 18 Mar 2015, at 11:45, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote:

Hi,

The show stopper is due to the fact that we would like to store a unique id for the computer to be able to track the data (kind of a cookie). This is what is being written on the file system (however, no information is being sent without the explicit consent).

Cheers, Doru

On Wed, Mar 18, 2015 at 10:55 AM, Andrei Chis <chisvasileandrei@gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: The current version from the moose repo uses the settings browser. However, with the current mechanism for exporting setting people using Moose and Pharo images will not be able to export their sendUsageData setting. That mechanism is really broken (http://forum.world.st/Exporting-Setting-preferences-tc4812327.html <http://forum.world.st/Exporting-Setting-preferences-tc4812327.html>)

Cheers, Andrei

On Wed, Mar 18, 2015 at 9:03 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: yeah, real solution is to remove GTSpotterEventRecorderSettings and use the Settings framework. AFAIK, guys in GTools team are already working on it :)

Esteban

...

On 18 Mar 2015, at 03:20, Ben Coman <btc@openInWorld.com <mailto:btc@openInWorld.com>> wrote:

Thanks Nicolai. I tried your suggestion but running the CI tests then crashes the VM. I'll gather more info. cheers -ben

On Wed, Mar 18, 2015 at 7:12 AM, Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote: 2015-03-17 18:29 GMT+01:00 Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>>:

Currently the image the monkey uses to validate issues is 9 days old - which might be a problem if your bug fix today depends on or conflicts with something integrated a week ago.

I have somewhat isolated the problem to a Rubric/GTTools update, but nothing looks obvious from the package level. Its time for bed, so I haven't dug into code changes yet, but could someone from the Glamorous Team familiar with the changes for Issue 15018 take a look?

https://pharo.fogbugz.com/default.asp?15018 <https://pharo.fogbugz.com/default.asp?15018>

https://pharo.fogbugz.com/default.asp?15127 <https://pharo.fogbugz.com/default.asp?15127>

cheers -ben

possible fix: GTSpotterEventRecorderSettings only read/write preference file if this startUp is a real image start up / booting.

startUp: resuming resuming ifFalse:[ ^ self]. "We reset image preferences, because this is likely a newly downloaded image or different user and he/she should agree about sending data." self preferences exists ifFalse: [ self reset ]. self loadPreferences.

-- www.tudorgirba.com <http://www.tudorgirba.com/>

"Every thing has its own flow"

In the new version from the moose repo nothing is written automatically or on image start-up to disk. Also: - the preferences for sending usage data are handled through the settings browser - *only if* you set the preference for sending usage data to true, a *cookie* like file is stored once to disk the first time data is send. Does it sound better? Cheers, Andrei On Wed, Mar 18, 2015 at 1:40 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

Esteban,

You are not addressing the right issue. The settings are already made to use the Settings framework:

https://pharo.fogbugz.com/f/cases/15104/Spotter-settings-should-also-appear-...

What Andrei mentioned is that in the way saving Settings for the whole computer is implemented now is quite unusable.

Anyway, the current issue is that we would like to store a unique id to identify the computer. This is not a setting.

Cheers, Doru

On Wed, Mar 18, 2015 at 1:29 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

another thing: we are 14 days from release. if you cannot provide a version that actually works without generating undesirable effects, then the right solution is to disable that functionality and wait for Pharo 5 to add it (with enough time to do it properly).

do not get me wrong: I *do want* everything in image and working, but well, with the stress of the latests days… We need to be prepared to take some drastic things (we already delayed some important things… we can delay others)

Esteban

On 18 Mar 2015, at 13:22, Esteban Lorenzano <estebanlm@gmail.com> wrote:

honestly, what misses completely the point is the idea of reading and saving your preferences each time the image is open. this is not java, we do not have a stateless environment… once you have it in the image and your image is save, there is no point on save/restore outside (which is what you are doing with that hand-made settings stuff).

this:

startUp: resuming "We reset image preferences, because this is likely a newly downloaded image or different user and he/she should agree about sending data." self preferences exists ifFalse: [ self reset ]. self loadPreferences.

loads your preferences (ideally always the same) each time you save the image (not just each time you open it, which is already BAD, but each time you do a save).

I’m still waiting for a quick replacement, because it is braking a lot of things for me: the CI building, the spur building, etc.

cheers, Esteban

On 18 Mar 2015, at 11:45, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

The show stopper is due to the fact that we would like to store a unique id for the computer to be able to track the data (kind of a cookie). This is what is being written on the file system (however, no information is being sent without the explicit consent).

Cheers, Doru

On Wed, Mar 18, 2015 at 10:55 AM, Andrei Chis <chisvasileandrei@gmail.com

...

wrote:

...

The current version from the moose repo uses the settings browser. However, with the current mechanism for exporting setting people using Moose and Pharo images will not be able to export their sendUsageData setting. That mechanism is really broken ( http://forum.world.st/Exporting-Setting-preferences-tc4812327.html)

Cheers, Andrei

On Wed, Mar 18, 2015 at 9:03 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

yeah, real solution is to remove GTSpotterEventRecorderSettings and use the Settings framework. AFAIK, guys in GTools team are already working on it :)

Esteban

On 18 Mar 2015, at 03:20, Ben Coman <btc@openInWorld.com> wrote:

Thanks Nicolai. I tried your suggestion but running the CI tests then crashes the VM. I'll gather more info. cheers -ben

On Wed, Mar 18, 2015 at 7:12 AM, Nicolai Hess <nicolaihess@web.de> wrote:

...

2015-03-17 18:29 GMT+01:00 Ben Coman <btc@openinworld.com>:

...

Currently the image the monkey uses to validate issues is 9 days old - which might be a problem if your bug fix today depends on or conflicts with something integrated a week ago.

I have somewhat isolated the problem to a Rubric/GTTools update, but nothing looks obvious from the package level. Its time for bed, so I haven't dug into code changes yet, but could someone from the Glamorous Team familiar with the changes for Issue 15018 take a look?

https://pharo.fogbugz.com/default.asp?15018

https://pharo.fogbugz.com/default.asp?15127

cheers -ben

possible fix: GTSpotterEventRecorderSettings only read/write preference file if this startUp is a real image start up / booting.

startUp: resuming resuming ifFalse:[ ^ self]. "We reset image preferences, because this is likely a newly downloaded image or different user and he/she should agree about sending data." self preferences exists ifFalse: [ self reset ]. self loadPreferences.

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com

"Every thing has its own flow"

When data is being send. Now there is just a method #ensureComputerID called before data is being send (so only if sendUsageData is set to true). This method checks if there is a cookie. If not it creates one. If there is it loads it. That's all. On Wed, Mar 18, 2015 at 2:21 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

On 18 Mar 2015, at 14:13, Andrei Chis <chisvasileandrei@gmail.com> wrote:

In the new version from the moose repo nothing is written automatically or on image start-up to disk. Also: - the preferences for sending usage data are handled through the settings browser - *only if* you set the preference for sending usage data to true, a *cookie* like file is stored once to disk the first time data is send.

Does it sound better?

yes… and when do you read it?

Esteban

Cheers, Andrei

On Wed, Mar 18, 2015 at 1:40 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

...

Esteban,

You are not addressing the right issue. The settings are already made to use the Settings framework:

https://pharo.fogbugz.com/f/cases/15104/Spotter-settings-should-also-appear-...

What Andrei mentioned is that in the way saving Settings for the whole computer is implemented now is quite unusable.

Anyway, the current issue is that we would like to store a unique id to identify the computer. This is not a setting.

Cheers, Doru

On Wed, Mar 18, 2015 at 1:29 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

another thing: we are 14 days from release. if you cannot provide a version that actually works without generating undesirable effects, then the right solution is to disable that functionality and wait for Pharo 5 to add it (with enough time to do it properly).

do not get me wrong: I *do want* everything in image and working, but well, with the stress of the latests days… We need to be prepared to take some drastic things (we already delayed some important things… we can delay others)

Esteban

On 18 Mar 2015, at 13:22, Esteban Lorenzano <estebanlm@gmail.com> wrote:

honestly, what misses completely the point is the idea of reading and saving your preferences each time the image is open. this is not java, we do not have a stateless environment… once you have it in the image and your image is save, there is no point on save/restore outside (which is what you are doing with that hand-made settings stuff).

this:

startUp: resuming "We reset image preferences, because this is likely a newly downloaded image or different user and he/she should agree about sending data." self preferences exists ifFalse: [ self reset ]. self loadPreferences.

loads your preferences (ideally always the same) each time you save the image (not just each time you open it, which is already BAD, but each time you do a save).

I’m still waiting for a quick replacement, because it is braking a lot of things for me: the CI building, the spur building, etc.

cheers, Esteban

On 18 Mar 2015, at 11:45, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

The show stopper is due to the fact that we would like to store a unique id for the computer to be able to track the data (kind of a cookie). This is what is being written on the file system (however, no information is being sent without the explicit consent).

Cheers, Doru

On Wed, Mar 18, 2015 at 10:55 AM, Andrei Chis < chisvasileandrei@gmail.com> wrote:

...

The current version from the moose repo uses the settings browser. However, with the current mechanism for exporting setting people using Moose and Pharo images will not be able to export their sendUsageData setting. That mechanism is really broken ( http://forum.world.st/Exporting-Setting-preferences-tc4812327.html)

Cheers, Andrei

On Wed, Mar 18, 2015 at 9:03 AM, Esteban Lorenzano <estebanlm@gmail.com

...

wrote:

...

yeah, real solution is to remove GTSpotterEventRecorderSettings and use the Settings framework. AFAIK, guys in GTools team are already working on it :)

Esteban

On 18 Mar 2015, at 03:20, Ben Coman <btc@openInWorld.com> wrote:

Thanks Nicolai. I tried your suggestion but running the CI tests then crashes the VM. I'll gather more info. cheers -ben

On Wed, Mar 18, 2015 at 7:12 AM, Nicolai Hess <nicolaihess@web.de> wrote:

...

2015-03-17 18:29 GMT+01:00 Ben Coman <btc@openinworld.com>:

...

Currently the image the monkey uses to validate issues is 9 days old - which might be a problem if your bug fix today depends on or conflicts with something integrated a week ago.

I have somewhat isolated the problem to a Rubric/GTTools update, but nothing looks obvious from the package level. Its time for bed, so I haven't dug into code changes yet, but could someone from the Glamorous Team familiar with the changes for Issue 15018 take a look?

https://pharo.fogbugz.com/default.asp?15018

https://pharo.fogbugz.com/default.asp?15127

cheers -ben

possible fix: GTSpotterEventRecorderSettings only read/write preference file if this startUp is a real image start up / booting.

startUp: resuming resuming ifFalse:[ ^ self]. "We reset image preferences, because this is likely a newly downloaded image or different user and he/she should agree about sending data." self preferences exists ifFalse: [ self reset ]. self loadPreferences.

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com

"Every thing has its own flow"

A new version that fixes this is ready to integrate: https://pharo.fogbugz.com/f/cases/15149/Integrate-GTools Cheers, Andrei On Wed, Mar 18, 2015 at 3:21 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

perfect!

On 18 Mar 2015, at 14:25, Andrei Chis <chisvasileandrei@gmail.com> wrote:

When data is being send.

Now there is just a method #ensureComputerID called before data is being send (so only if sendUsageData is set to true). This method checks if there is a cookie. If not it creates one. If there is it loads it. That's all.

On Wed, Mar 18, 2015 at 2:21 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

On 18 Mar 2015, at 14:13, Andrei Chis <chisvasileandrei@gmail.com> wrote:

In the new version from the moose repo nothing is written automatically or on image start-up to disk. Also: - the preferences for sending usage data are handled through the settings browser - *only if* you set the preference for sending usage data to true, a *cookie* like file is stored once to disk the first time data is send.

Does it sound better?

yes… and when do you read it?

Esteban

Cheers, Andrei

On Wed, Mar 18, 2015 at 1:40 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

...

Esteban,

You are not addressing the right issue. The settings are already made to use the Settings framework:

https://pharo.fogbugz.com/f/cases/15104/Spotter-settings-should-also-appear-...

What Andrei mentioned is that in the way saving Settings for the whole computer is implemented now is quite unusable.

Anyway, the current issue is that we would like to store a unique id to identify the computer. This is not a setting.

Cheers, Doru

On Wed, Mar 18, 2015 at 1:29 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

another thing: we are 14 days from release. if you cannot provide a version that actually works without generating undesirable effects, then the right solution is to disable that functionality and wait for Pharo 5 to add it (with enough time to do it properly).

do not get me wrong: I *do want* everything in image and working, but well, with the stress of the latests days… We need to be prepared to take some drastic things (we already delayed some important things… we can delay others)

Esteban

On 18 Mar 2015, at 13:22, Esteban Lorenzano <estebanlm@gmail.com> wrote:

honestly, what misses completely the point is the idea of reading and saving your preferences each time the image is open. this is not java, we do not have a stateless environment… once you have it in the image and your image is save, there is no point on save/restore outside (which is what you are doing with that hand-made settings stuff).

this:

startUp: resuming "We reset image preferences, because this is likely a newly downloaded image or different user and he/she should agree about sending data." self preferences exists ifFalse: [ self reset ]. self loadPreferences.

loads your preferences (ideally always the same) each time you save the image (not just each time you open it, which is already BAD, but each time you do a save).

I’m still waiting for a quick replacement, because it is braking a lot of things for me: the CI building, the spur building, etc.

cheers, Esteban

On 18 Mar 2015, at 11:45, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

The show stopper is due to the fact that we would like to store a unique id for the computer to be able to track the data (kind of a cookie). This is what is being written on the file system (however, no information is being sent without the explicit consent).

Cheers, Doru

On Wed, Mar 18, 2015 at 10:55 AM, Andrei Chis < chisvasileandrei@gmail.com> wrote:

...

The current version from the moose repo uses the settings browser. However, with the current mechanism for exporting setting people using Moose and Pharo images will not be able to export their sendUsageData setting. That mechanism is really broken ( http://forum.world.st/Exporting-Setting-preferences-tc4812327.html)

Cheers, Andrei

On Wed, Mar 18, 2015 at 9:03 AM, Esteban Lorenzano < estebanlm@gmail.com> wrote:

...

yeah, real solution is to remove GTSpotterEventRecorderSettings and use the Settings framework. AFAIK, guys in GTools team are already working on it :)

Esteban

On 18 Mar 2015, at 03:20, Ben Coman <btc@openInWorld.com> wrote:

Thanks Nicolai. I tried your suggestion but running the CI tests then crashes the VM. I'll gather more info. cheers -ben

On Wed, Mar 18, 2015 at 7:12 AM, Nicolai Hess <nicolaihess@web.de> wrote:

...

2015-03-17 18:29 GMT+01:00 Ben Coman <btc@openinworld.com>:

...

Currently the image the monkey uses to validate issues is 9 days old - which might be a problem if your bug fix today depends on or conflicts with something integrated a week ago.

I have somewhat isolated the problem to a Rubric/GTTools update, but nothing looks obvious from the package level. Its time for bed, so I haven't dug into code changes yet, but could someone from the Glamorous Team familiar with the changes for Issue 15018 take a look?

https://pharo.fogbugz.com/default.asp?15018

https://pharo.fogbugz.com/default.asp?15127

cheers -ben

possible fix: GTSpotterEventRecorderSettings only read/write preference file if this startUp is a real image start up / booting.

startUp: resuming resuming ifFalse:[ ^ self]. "We reset image preferences, because this is likely a newly downloaded image or different user and he/she should agree about sending data." self preferences exists ifFalse: [ self reset ]. self loadPreferences.

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com

"Every thing has its own flow"

I think there is a misunderstanding. The settings are implemented as requested to be uniform even though the solution is less likely to get proper results. We should probably revisit the settings solution in Pharo 5. In the meantime we also have a solution to make the CI happy and only write the extra file on disk if the user does choose to send anonymous data. So, these problems are fixed. Cheers, Doru On Wed, Mar 18, 2015 at 5:58 PM, stepharo <stepharo@free.fr> wrote:

Then you postpone it to Pharo 5.0 We postponed a lot of changes recently more than people could think of :)

Stef

Le 18/3/15 13:40, Tudor Girba a écrit :

Esteban,

You are not addressing the right issue. The settings are already made to use the Settings framework:

https://pharo.fogbugz.com/f/cases/15104/Spotter-settings-should-also-appear-...

What Andrei mentioned is that in the way saving Settings for the whole computer is implemented now is quite unusable.

Anyway, the current issue is that we would like to store a unique id to identify the computer. This is not a setting.

Cheers, Doru

On Wed, Mar 18, 2015 at 1:29 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

another thing: we are 14 days from release. if you cannot provide a version that actually works without generating undesirable effects, then the right solution is to disable that functionality and wait for Pharo 5 to add it (with enough time to do it properly).

do not get me wrong: I *do want* everything in image and working, but well, with the stress of the latests days… We need to be prepared to take some drastic things (we already delayed some important things… we can delay others)

Esteban

On 18 Mar 2015, at 13:22, Esteban Lorenzano <estebanlm@gmail.com> wrote:

honestly, what misses completely the point is the idea of reading and saving your preferences each time the image is open. this is not java, we do not have a stateless environment… once you have it in the image and your image is save, there is no point on save/restore outside (which is what you are doing with that hand-made settings stuff).

this:

startUp: resuming "We reset image preferences, because this is likely a newly downloaded image or different user and he/she should agree about sending data." self preferences exists ifFalse: [ self reset ]. self loadPreferences.

loads your preferences (ideally always the same) each time you save the image (not just each time you open it, which is already BAD, but each time you do a save).

I’m still waiting for a quick replacement, because it is braking a lot of things for me: the CI building, the spur building, etc.

cheers, Esteban

On 18 Mar 2015, at 11:45, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

The show stopper is due to the fact that we would like to store a unique id for the computer to be able to track the data (kind of a cookie). This is what is being written on the file system (however, no information is being sent without the explicit consent).

Cheers, Doru

On Wed, Mar 18, 2015 at 10:55 AM, Andrei Chis <chisvasileandrei@gmail.com

...

wrote:

...

The current version from the moose repo uses the settings browser. However, with the current mechanism for exporting setting people using Moose and Pharo images will not be able to export their sendUsageData setting. That mechanism is really broken ( http://forum.world.st/Exporting-Setting-preferences-tc4812327.html)

Cheers, Andrei

On Wed, Mar 18, 2015 at 9:03 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

yeah, real solution is to remove GTSpotterEventRecorderSettings and use the Settings framework. AFAIK, guys in GTools team are already working on it :)

Esteban

On 18 Mar 2015, at 03:20, Ben Coman <btc@openInWorld.com> wrote:

Thanks Nicolai. I tried your suggestion but running the CI tests then crashes the VM. I'll gather more info. cheers -ben

On Wed, Mar 18, 2015 at 7:12 AM, Nicolai Hess <nicolaihess@web.de> wrote:

...

2015-03-17 18:29 GMT+01:00 Ben Coman <btc@openinworld.com>:

...

Currently the image the monkey uses to validate issues is 9 days old - which might be a problem if your bug fix today depends on or conflicts with something integrated a week ago.

I have somewhat isolated the problem to a Rubric/GTTools update, but nothing looks obvious from the package level. Its time for bed, so I haven't dug into code changes yet, but could someone from the Glamorous Team familiar with the changes for Issue 15018 take a look?

https://pharo.fogbugz.com/default.asp?15018

https://pharo.fogbugz.com/default.asp?15127

cheers -ben

possible fix: GTSpotterEventRecorderSettings only read/write preference file if this startUp is a real image start up / booting.

startUp: resuming resuming ifFalse:[ ^ self]. "We reset image preferences, because this is likely a newly downloaded image or different user and he/she should agree about sending data." self preferences exists ifFalse: [ self reset ]. self loadPreferences.

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com "Every thing has its own flow"