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

Re: [Pharo-dev] Magritte = Auto-GT Presentation

by Sean P. DeNigris

Tudor Girba-2 wrote > You get a GLMMagrittePresentation and if you want to use it in the > inspector, you have to define your own extension that uses it. I'm sorry, I'm still not understanding... I only know how to hook into the inspector via <gtInspectorPresentationOrder: aNumber>. How does that relate to GLMMagrittePresentation? How specifically do I have a Magritte presentation appear by default in GT for an object? Is there an example or doc somewhere? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Magritte-Auto-GT-Presentation-tp4817448p4819110.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 12, 2015

Can't Log In to CI

by Sean P. DeNigris

Did something change in the last 12 hours? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Can-t-Log-In-to-CI-tp4819109.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 12, 2015

Re: [Pharo-dev] Jenkins Not Compiling Launcher Chapter`

by Dmitri Zagidulin

Sean, I think you have to add PharoLauncherTutorial pillar file to the inputFiles section of 'pillar.conf', for it to generate the pdf. On Sat, Apr 11, 2015 at 2:27 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > https://ci.inria.fr/pharo-contribution/job/PharoBookWorkInProgress/22/artif… > only contains the .pillar file - no html, pdf, etc. > > Anyone know why? I nosed through the config, build script, and console > output but didn't see anything obvious. Thanks. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Jenkins-Not-Compiling-Launcher-Chapter-tp4819089.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 12, 2015

Re: [Pharo-dev] Problem with asClass usage

by Tudor Girba

Hi, To make it easier to refactor these places, here is how to find asClass usages with GTSpotter: http://www.humane-assessment.com/blog/finding-asclass-usages-in-glamour-usi… :) Cheers, Doru On Wed, Apr 8, 2015 at 12:32 PM, stepharo <stepharo(a)free.fr> wrote: > Hi > > We want to raise a strong warning against the extension of the use of > asClass and friends. > asClass should not be used in Pharo distribution. I will propose to > deprecate it. > > We are working on dependency analysis, module system, remote debugging and > asClass introduces > lose class references and many related problems. > > I would like to remove this behavior because it is clear that it will just > grow up and lead to deadcode and ugly dependencies. > > First, most of the time you can avoid to query Smalltalk globals at: and > that BY CONSTRUCTION a software system should be built and it should > define its own customization. > > > Second, at least use self class environment at: #foo > > Why is it much much much better? because it does not rely on String class > resolution and as such > is much more modular. You do not want to have the resolution of a symbol > related to the place where String is defined but on where your code is > actually. > > Imagine that tomorrow your code is in its own module. Then you want to > know from your code point of you > if a binding exist not from the one of environment in which String is. > > > > > here are some examples: > > ============================== > quadrangleClass > ^ 'QuadrangleForTesting' asClass > > Strange it simply breaks. Of course it broke the smallLint rule. > > ============================== > Metacello should better define OSProcess as a dependent.Because it is not > clear what will happen > if if not there? > > extractRepositoryFrom: zipFile to: directory > "unzip <zipFile> into <directory>" > > | out err proc errorMessage | > out := FileStream forceNewFileNamed: '/tmp/zip.out'. > err := FileStream forceNewFileNamed: '/tmp/zip.err'. > errorMessage := ''. > [ > proc := #OSProcess asClass thisOSProcess > forkJob: '/usr/bin/unzip' > arguments: > {'-u'. > zipFile. > '-d'. > directory} > environment: nil > descriptors: (Array with: nil with: out with: err). > > ================== > > I do not get why we need this funky logic. > > openInBrickWindowLabeled: aLabel > > #GLMSystemWindowBrick asClassIfAbsent: [ > ^ self asMorph openInWindow ]. > > ^ #GLMSystemWindowBrick asClass new > label: aLabel; > color: Color transparent; > addBrickBack: ( > GLMBrick new > vSpaceFill > > > window > "Answer the receiver's window." > #GLMWindowBrick asClassIfAbsent: [ > ^ self ownerThatIsA: SystemWindow ]. > > ^ (self ownerThatIsA: #GLMWindowBrick asClass) > ifNil: [ self ownerThatIsA: SystemWindow ] > > > > sendUsageData: aBoolean > | settingsClass | > settingsClass := #GTSpotterEventRecorderSettings asClassIfAbsent: [ ^ > self ]. > ^ settingsClass sendUsageData: aBoolean > > > sendUsageData > | settingsClass | > settingsClass := #GTSpotterEventRecorderSettings asClassIfAbsent: [ ^ > false ]. > ^ settingsClass sendUsageData > > > -- www.tudorgirba.com "Every thing has its own flow"

April 11, 2015

Re: [Pharo-dev] why we removed debugTest from nautilus?

by Clara Allende

Le 11 avr. 2015 14:32, "ClÃ©ment Bera" <bera.clement(a)gmail.com> a Ã©crit : > > > > 2015-04-11 1:10 GMT-07:00 Nicolai Hess <nicolaihess(a)web.de>: > >> >> >> 2015-04-10 17:28 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >>> >>> Well I guess I used to click proceed and not close the debugger... >> >> >> >> I don't know who is working on the breakpoint support and I don't know how long it will take. >> Maybe we can fix thie image freeze and re-include the debugtest code until the new breakpoint support. >> >> what do you think? >> > > I think break points were done by Clara Allende. As far as I know, they work but there's no IDE support for them. I think they are not ready for this release but I am not sure about the status. Marcus can confirm it will not be ready. For this release the intention was reviewing and integrating the Reflectivity machinery, and then afterwards the breakpoints. So far Marcus has done a lot on that part (reviewing and enhancing my prototype for reflectivity), and we have discussed that the breakpoints (in the state I've left them at the end of my internship) should work out of the box. Nevertheless, I want to do a pass on them and update what's necessary once Pharo4 is released. But they won't be integrated in the release, that's for sure, because there's work to do with them... Cheers Clari > > Yes this image freeze could be fixed but I can't really work on the Pharo release this week (I'm working with Eliot on Cogit...). I could review the fix if you want just tagged me in fogbugz. >>> >>> >>> 2015-04-10 1:24 GMT-07:00 Max Leske <maxleske(a)gmail.com>: >>> >>>> For a little more context: the issue was originally raised by Clara in the thread titled "MNU: receiver of "stepToCallee:" is nilâ. IIRC the issue was easily reproducible when debugging a test, then closing the debugger (via the close icon). Clicking âProceedâ on the other hand gracefully terminated the process. >>>> >>>> Cheers, >>>> Max >>>> >>>> >>>>> On 10 Apr 2015, at 09:56, Nicolai Hess <nicolaihess(a)web.de> wrote: >>>>> >>>>> 2015-04-10 2:37 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >>>>>> >>>>>> I was using it frequently too and I have never experienced any issues... >>>>> >>>>> >>>>> Ok, can you describe a use case, what test case you can start and >>>>> close the debugger without image freeze? >>>>> >>>>> Maybe we can find what is the difference between that >>>>> test case and those that freeze the image, and than find a fix. >>>>> >>>>>> >>>>>> >>>>>> 2015-04-09 14:58 GMT-07:00 Nicolai Hess <nicolaihess(a)web.de>: >>>>>> >>>>>>> >>>>>>> 2015-04-09 23:38 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >>>>>>>> >>>>>>>> No Debug Tests? >>>>>>>> >>>>>>>> Geez, I am using that all the time. >>>>>>> >>>>>>> >>>>>>> And you're never encountered this issue 14689? >>>>>>> Or did this work in older versions? >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Phil >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Apr 9, 2015 at 10:21 PM, Marcus Denker < marcus.denker(a)inria.fr> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> > On 09 Apr 2015, at 22:32, Sean P. DeNigris < sean(a)clipperadams.com> wrote: >>>>>>>>> > >>>>>>>>> > Nicolai Hess wrote >>>>>>>>> >> http://forum.world.st/do-we-need-to-debug-testmethods-from-within-Nautilus-… >>>>>>>>> > >>>>>>>>> > Ah, I miss that too! From that thread, it seems it was removed temporarily >>>>>>>>> > until we have real breakpoints. Is there an issue for its return? >>>>>>>>> > >>>>>>>>> >>>>>>>>> Not yet. >>>>>>>>> >>>>>>>>> Marcus >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >

April 11, 2015

Re: [Pharo-dev] why we removed debugTest from nautilus?

by Ben Coman

>From the perspective of a TestCase... * "running" a test wraps execution in error handling so it can log errors without TestRunner breaking open a debugger. * "debugging" executes without that error handling so an error breaks open a debugger. The functionality required is that a debugger opens immediately on the first line of the test method. cheers -ben On Sun, Apr 12, 2015 at 3:35 AM, Max Leske <maxleske(a)gmail.com> wrote: > > On 11 Apr 2015, at 21:31, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Sun, Apr 12, 2015 at 3:07 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> Returning to build 40486 which exhibits the freeze, as a first step, why >> don't we replace all that complicated stack manipulation stuff with... >> >> NautilusUI>>debugTest: aMethod >> [ aMethod methodClass debug: aMethod selector ] fork. >> >> > Sorry. Pretend I didn't say that. That is the <run test> behaviour. > > > Really? Why does it send #debug: then?? > > cheers -ben > > >

April 11, 2015

Re: [Pharo-dev] why we removed debugTest from nautilus?

by Max Leske

> On 11 Apr 2015, at 21:31, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Sun, Apr 12, 2015 at 3:07 AM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > Returning to build 40486 which exhibits the freeze, as a first step, why don't we replace all that complicated stack manipulation stuff with... > > NautilusUI>>debugTest: aMethod > [ aMethod methodClass debug: aMethod selector ] fork. > > > Sorry. Pretend I didn't say that. That is the <run test> behaviour. Really? Why does it send #debug: then?? > cheers -ben >

April 11, 2015

Re: [Pharo-dev] why we removed debugTest from nautilus?

by Max Leske

> On 11 Apr 2015, at 21:07, Ben Coman <btc(a)openinworld.com> wrote: > > Returning to build 40486 which exhibits the freeze, as a first step, why don't we replace all that complicated stack manipulation stuff with... > > NautilusUI>>debugTest: aMethod > [ aMethod methodClass debug: aMethod selector ] fork. I donât see any immediate losses. Even the stack should look fine I guess (top context is the one we want etc.). > > cheers -ben > > On Sun, Apr 12, 2015 at 1:31 AM, ClÃ©ment Bera <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>> wrote: > > > 2015-04-11 1:10 GMT-07:00 Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>>: > > > 2015-04-10 17:28 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>>: > Well I guess I used to click proceed and not close the debugger... > > > I don't know who is working on the breakpoint support and I don't know how long it will take. > Maybe we can fix thie image freeze and re-include the debugtest code until the new breakpoint support. > > what do you think? > > > I think break points were done by Clara Allende. As far as I know, they work but there's no IDE support for them. I think they are not ready for this release but I am not sure about the status. Marcus can confirm it will not be ready. > > Yes this image freeze could be fixed but I can't really work on the Pharo release this week (I'm working with Eliot on Cogit...). I could review the fix if you want just tagged me in fogbugz. > > 2015-04-10 1:24 GMT-07:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: > > For a little more context: the issue was originally raised by Clara in the thread titled "MNU: receiver of "stepToCallee:" is nilâ. IIRC the issue was easily reproducible when debugging a test, then closing the debugger (via the close icon). Clicking âProceedâ on the other hand gracefully terminated the process. > > Cheers, > Max > > >> On 10 Apr 2015, at 09:56, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >> >> 2015-04-10 2:37 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>>: >> I was using it frequently too and I have never experienced any issues... >> >> Ok, can you describe a use case, what test case you can start and >> close the debugger without image freeze? >> >> Maybe we can find what is the difference between that >> test case and those that freeze the image, and than find a fix. >> >> >> 2015-04-09 14:58 GMT-07:00 Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>>: >> >> >> 2015-04-09 23:38 GMT+02:00 phil(a)highoctane.be <mailto:phil@highoctane.be> <phil(a)highoctane.be <mailto:phil@highoctane.be>>: >> No Debug Tests? >> >> Geez, I am using that all the time. >> >> And you're never encountered this issue 14689 <https://pharo.fogbugz.com/default.asp?14689>? >> Or did this work in older versions? >> >> >> >> >> Phil >> >> >> On Thu, Apr 9, 2015 at 10:21 PM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> > On 09 Apr 2015, at 22:32, Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: >> > >> > Nicolai Hess wrote >> >> http://forum.world.st/do-we-need-to-debug-testmethods-from-within-Nautilus-… <http://forum.world.st/do-we-need-to-debug-testmethods-from-within-Nautilus-…> >> > >> > Ah, I miss that too! From that thread, it seems it was removed temporarily >> > until we have real breakpoints. Is there an issue for its return? >> > >> >> Not yet. >> >> Marcus >> >> >> >> > > > > >

April 11, 2015

Re: [Pharo-dev] why we removed debugTest from nautilus?

by Ben Coman

On Sun, Apr 12, 2015 at 3:07 AM, Ben Coman <btc(a)openinworld.com> wrote: > Returning to build 40486 which exhibits the freeze, as a first step, why > don't we replace all that complicated stack manipulation stuff with... > > NautilusUI>>debugTest: aMethod > [ aMethod methodClass debug: aMethod selector ] fork. > > Sorry. Pretend I didn't say that. That is the <run test> behaviour. cheers -ben

April 11, 2015

Re: [Pharo-dev] why we removed debugTest from nautilus?

by Ben Coman

Returning to build 40486 which exhibits the freeze, as a first step, why don't we replace all that complicated stack manipulation stuff with... NautilusUI>>debugTest: aMethod [ aMethod methodClass debug: aMethod selector ] fork. cheers -ben On Sun, Apr 12, 2015 at 1:31 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > 2015-04-11 1:10 GMT-07:00 Nicolai Hess <nicolaihess(a)web.de>: > >> >> >> 2015-04-10 17:28 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >>> Well I guess I used to click proceed and not close the debugger... >>> >> >> >> I don't know who is working on the breakpoint support and I don't know >> how long it will take. >> Maybe we can fix thie image freeze and re-include the debugtest code >> until the new breakpoint support. >> >> what do you think? >> >> > I think break points were done by Clara Allende. As far as I know, they > work but there's no IDE support for them. I think they are not ready for > this release but I am not sure about the status. Marcus can confirm it will > not be ready. > > Yes this image freeze could be fixed but I can't really work on the Pharo > release this week (I'm working with Eliot on Cogit...). I could review > the fix if you want just tagged me in fogbugz. > >> >>> 2015-04-10 1:24 GMT-07:00 Max Leske <maxleske(a)gmail.com>: >>> >>> For a little more context: the issue was originally raised by Clara in >>>> the thread titled "MNU: receiver of "stepToCallee:" is nilâ. IIRC the >>>> issue was easily reproducible when debugging a test, then closing the >>>> debugger (via the close icon). Clicking âProceedâ on the other hand >>>> gracefully terminated the process. >>>> >>>> Cheers, >>>> Max >>>> >>>> >>>> On 10 Apr 2015, at 09:56, Nicolai Hess <nicolaihess(a)web.de> wrote: >>>> >>>> 2015-04-10 2:37 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >>>> >>>>> I was using it frequently too and I have never experienced any >>>>> issues... >>>>> >>>> >>>> Ok, can you describe a use case, what test case you can start and >>>> close the debugger without image freeze? >>>> >>>> Maybe we can find what is the difference between that >>>> test case and those that freeze the image, and than find a fix. >>>> >>>> >>>>> >>>>> 2015-04-09 14:58 GMT-07:00 Nicolai Hess <nicolaihess(a)web.de>: >>>>> >>>>> >>>>>> 2015-04-09 23:38 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >>>>>> >>>>>>> No Debug Tests? >>>>>>> >>>>>>> Geez, I am using that all the time. >>>>>>> >>>>>> >>>>>> And you're never encountered this issue 14689 >>>>>> <https://pharo.fogbugz.com/default.asp?14689>? >>>>>> Or did this work in older versions? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> >>>>>>> On Thu, Apr 9, 2015 at 10:21 PM, Marcus Denker < >>>>>>> marcus.denker(a)inria.fr> wrote: >>>>>>> >>>>>>>> >>>>>>>> > On 09 Apr 2015, at 22:32, Sean P. DeNigris <sean(a)clipperadams.com> >>>>>>>> wrote: >>>>>>>> > >>>>>>>> > Nicolai Hess wrote >>>>>>>> >> >>>>>>>> http://forum.world.st/do-we-need-to-debug-testmethods-from-within-Nautilus-… >>>>>>>> > >>>>>>>> > Ah, I miss that too! From that thread, it seems it was removed >>>>>>>> temporarily >>>>>>>> > until we have real breakpoints. Is there an issue for its return? >>>>>>>> > >>>>>>>> >>>>>>>> Not yet. >>>>>>>> >>>>>>>> Marcus >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >

April 11, 2015