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

Re: [Pharo-dev] Strange Pharo 3.0 behaviour

by Max Leske

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] Strange Pharo 3.0 behaviour

by Hilaire

Le 18/03/2015 11:29, Nevena Milojkovic a Ã©crit : > 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 > > I can't reproduce your problem on LinuxMint. I thought you may have CapsLock enabled, but even with it enabled, I can delete part of selected source code with Tabs or Backscpace. May be try another VM, Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

March 18, 2015

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

by Nicolai Hess

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

error when inspecting/printing variables in the debugger

by Andrei Chis

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. 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

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"

March 18, 2015

Strange Pharo 3.0 behaviour

by Nevena Milojkovic

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 Andrei Chis

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. >> > > >

March 18, 2015

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

by Esteban Lorenzano

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 <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. >

March 18, 2015

New Cog VMs available

by Eliot Miranda

CogVM binaries as per VMMaker.oscog-eem.1096/r3282 Fix assertClassOf:is: to handle immediates upstream of isClassOfNonImm:equalTo:. Fixes a potential crash when x or y is sent to immediates (bytecodePrimX/Y). Include the GdbARMPlugin on linux (Spur only) & Mac OS X (V3 & Spur). -- best, Eliot

March 18, 2015

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

by Ben Coman

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. >

March 18, 2015