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 <[email protected]> wrote: > > On 18 Mar 2015, at 14:13, Andrei Chis <[email protected]> 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 <[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" >> > > >
