> 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] > <mailto:[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 > > <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] > <mailto:[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] >> <mailto:[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] >>> <mailto:[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" >> > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow" >
