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