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 <[email protected]> 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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>> wrote:
>> 2015-03-17 18:29 GMT+01:00 Ben Coman <[email protected]
>> <mailto:[email protected]>>:
>>
>> 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"
