March 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Show Stopper Issue 15127 Pharo-4.0-Issue-Tracker-Image ci job is red

by Andrei Chis

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(a)gmail.com> wrote: > > On 18 Mar 2015, at 14:13, Andrei Chis <chisvasileandrei(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)web.de> >>>>> wrote: >>>>> >>>>>> 2015-03-17 18:29 GMT+01:00 Ben Coman <btc(a)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" >> > > >

March 18, 2015

Re: [Pharo-dev] Show Stopper Issue 15127 Pharo-4.0-Issue-Tracker-Image ci job is red

by Esteban Lorenzano

> On 18 Mar 2015, at 14:13, Andrei Chis <chisvasileandrei(a)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(a)tudorgirba.com <mailto: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… <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(a)gmail.com <mailto: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(a)gmail.com <mailto: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(a)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(a)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(a)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(a)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(a)web.de <mailto:nicolaihess@web.de>> wrote: >>>> 2015-03-17 18:29 GMT+01:00 Ben Coman <btc(a)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" >> > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow" >

March 18, 2015

Re: [Pharo-dev] Show Stopper Issue 15127 Pharo-4.0-Issue-Tracker-Image ci job is red

by Andrei Chis

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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)web.de> >>>> wrote: >>>> >>>>> 2015-03-17 18:29 GMT+01:00 Ben Coman <btc(a)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" >

March 18, 2015

Re: [Pharo-dev] Rubric mutability issue in RubTextComposer binary search

by Guillermo Polito

I agree with Stephan... I don't think that Rubric is built to be thread safe. Also, making Rubric thread safe will probably be a lot of work... Why do not ensuring in spotter that only one thread at a time can modify the text editor? El mar., 17 de mar. de 2015 a la(s) 11:42 p. m., Stephan Eggermont < stephan(a)stack.nl> escribiÃ³: > Hi Alex, > > On 17/03/15 22:19, Aliaksei Syrel wrote: > > seems like there is a rather rare bug in Rubric. I opened an issue with > > explanation: > > > > https://pharo.fogbugz.com/f/cases/15153/Rubric-mutability- > issue-in-RubTextComposer-binary-search > > > > Would be nice to fix it until release. It was caught in Spotter - as it > > heavily uses multithreading. Any suggestions are welcome if it is known > :) > > Why is that an issue in Rubric? Sounds like you might need a monitor in > Spotter? > > Stephan > > >

March 18, 2015

Re: [Pharo-dev] error when inspecting/printing variables in the debugger

by Andrei Chis

Thanks Nicolai. The problem might be related to 14606 but I'm not sure. Don't have time to look more into it but I can give you a reproduce it if you want. On Wed, Mar 18, 2015 at 12:23 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-03-18 12:05 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > >> Hi, >> >> When inspecting/orinting variables in the debugger I sometimes get >> UndefinedObject(Object)>>doesNotUnderstand: #indexForVarNamed: >> in >> OCCopyingTempVariable>>indexInTempVectorFromIR: >> >> This happens when the variable is declare as a local variable in the >> method and access from some nested blocks. >> I think there was a bug about something related, but from what I remember >> it was fixed. >> > > This was: > 13260 <https://pharo.fogbugz.com/default.asp?13260> > inspecting variables in the debugger fails in some cases > > and two that are related to the above fix > 14079 <https://pharo.fogbugz.com/default.asp?14079> > Inconsistent information in debugger (pharo 4) > 14606 <https://pharo.fogbugz.com/default.asp?14606> > Can't see some variables values while debugging closure > > > > >> >> Cheers, >> Andrei >> > >

March 18, 2015

Re: [Pharo-dev] Show Stopper Issue 15127 Pharo-4.0-Issue-Tracker-Image ci job is red

by Tudor Girba

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(a)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(a)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(a)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(a)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(a)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(a)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(a)web.de> >>> wrote: >>> >>>> 2015-03-17 18:29 GMT+01:00 Ben Coman <btc(a)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"

March 18, 2015

Re: [Pharo-dev] Strange Pharo 3.0 behaviour

by Nevena Milojkovic

Itâs working! Thanks a lot! Nevena > On 18 Mar 2015, at 13:17, Max Leske <maxleske(a)gmail.com> wrote: > > You might be experiencing an OSX glitch which has been annoying me for quite a while now. Switching between applications / desktops somehow makes the image believe that the option key has been pressed and so many key presses donât work as youâre used to. > > Solution: hit option once and you should be good (works for me every time). > > Cheers, > Max > > >> On 18 Mar 2015, at 11:29, Nevena Milojkovic <nevena(a)iam.unibe.ch> wrote: >> >> Hi all, >> >> I am experiencing some strange Pharo 3.0 behaviour. Nautilus doesnât allow me to change the source code in a regular way. For example, the only way I can delete the parts of source code is if I select them and then press space. Backspace, as well as tab, are not working. It seems like whenever I press backspace or tab it tries to save the changes in the source code, like I had pressed Command+S, and it move the cursor at the beginning of the method. Sometimes it just stops after a few tries to do something, and continues normally, sometimes not. It happens also with the fresh Pharo 3.0 image. >> Anybody experienced this? Anybody has a solution? >> >> Thanks a lot, >> Nevena Milojkovic >> >> >> >> >> > >

March 18, 2015

Re: [Pharo-dev] Show Stopper Issue 15127 Pharo-4.0-Issue-Tracker-Image ci job is red

by Esteban Lorenzano

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(a)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(a)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(a)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(a)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(a)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(a)web.de <mailto:nicolaihess@web.de>> wrote: >>> 2015-03-17 18:29 GMT+01:00 Ben Coman <btc(a)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" >

March 18, 2015

Re: [Pharo-dev] Show Stopper Issue 15127 Pharo-4.0-Issue-Tracker-Image ci job is red

by Marcus Denker

> On 18 Mar 2015, at 11:45, Tudor Girba <tudor(a)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). > Maybe an idea would to postpone all this to Pharo5. This is some big intrusive mechanism that needs care and multiple iterations to get done. Right now we can not really afford to break the system in a way that everyone has to stop to work, which is the case now. Marcus

March 18, 2015

Re: [Pharo-dev] Show Stopper Issue 15127 Pharo-4.0-Issue-Tracker-Image ci job is red

by Esteban Lorenzano

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(a)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(a)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(a)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(a)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(a)web.de <mailto:nicolaihess@web.de>> wrote: >> 2015-03-17 18:29 GMT+01:00 Ben Coman <btc(a)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"

March 18, 2015