- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] So, again, why 'object inspect' should answer an object?

by Igor Stasenko

ah, ok.. maybe i use outdated image? On 26 August 2013 22:41, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I think we agreed that > - #inspect: returns the inspected value > - #inspector: returns the inspector for the given value > > I thought we fixed exactly the bug you experience since Ben complained a > lot about it ;) > > On 2013-08-26, at 22:32, Igor Stasenko <siguctua(a)gmail.com> wrote: > > ... or another reason to answer the inspector window.. > > because right now it is badly broken: > > > > EyeInspector class>>inspect: anObject > > InspectorWrapper openInspector: (self inspector: anObject). > > ^ anObject > > > > but: > > > > Morph>>inspectInMorphic: evt > > evt hand attachMorph: ((Smalltalk tools inspect: self) extent: 300@200 > ) > > > > that explains why, when i taking the morph's halo > > and then use debug context menu and press inspect it, > > it puts morph info the hand, and changing its dimensions.. > > instead of putting inspector window into hand! > > > > you can imagine how annoying it is, when you want to debug morphic code. > > > > The solution is, of course to answer an inspector window instead of > > inspected object.. or, since people argued against this, for such cases, > > there should be extra protocol, like > > > > Smalltalk tools inspectorWindowOn: object > > > > (i changed the code to answer a window right now, but we need to solve > that > > dilemma) > > > > -- > > Best regards, > > Igor Stasenko. > > -- Best regards, Igor Stasenko.

Aug. 26, 2013

Can someone explain me what this code doing?

by Igor Stasenko

NewValueHolder>>contents: anObject | oldValue | lock ifTrue: [ ^ self ]. lock := true. oldValue := contents. contents := anObject. [ self contentsChanged: oldValue ] ensure: [ lock := false ]. ^ contents it is really interesting.. it appears you cannot change the contents of value holder (as you can see it will simply ignore it) when it 'locked' during announcing the change event. i know, this will prevent it from entering recursive loop, but i would instead throw an error in such case(s) because code which modifying the value as a reaction on value change is something really stupid and must be fixed, instead of putting workaround which will block the value holder from accepting new value(s).. and that is really bad: - notification(s) about some property change should not block the value from being able to be changed -- Best regards, Igor Stasenko.

Aug. 26, 2013

Re: [Pharo-dev] So, again, why 'object inspect' should answer an object?

by Camillo Bruni

I think we agreed that - #inspect: returns the inspected value - #inspector: returns the inspector for the given value I thought we fixed exactly the bug you experience since Ben complained a lot about it ;) On 2013-08-26, at 22:32, Igor Stasenko <siguctua(a)gmail.com> wrote: > ... or another reason to answer the inspector window.. > because right now it is badly broken: > > EyeInspector class>>inspect: anObject > InspectorWrapper openInspector: (self inspector: anObject). > ^ anObject > > but: > > Morph>>inspectInMorphic: evt > evt hand attachMorph: ((Smalltalk tools inspect: self) extent: 300@200) > > that explains why, when i taking the morph's halo > and then use debug context menu and press inspect it, > it puts morph info the hand, and changing its dimensions.. > instead of putting inspector window into hand! > > you can imagine how annoying it is, when you want to debug morphic code. > > The solution is, of course to answer an inspector window instead of > inspected object.. or, since people argued against this, for such cases, > there should be extra protocol, like > > Smalltalk tools inspectorWindowOn: object > > (i changed the code to answer a window right now, but we need to solve that > dilemma) > > -- > Best regards, > Igor Stasenko.

Aug. 26, 2013

Re: [Pharo-dev] So, again, why 'object inspect' should answer an object?

by Esteban A. Maringolo

As a side note: In Dolphin it returns the inspector :) Esteban A. Maringolo 2013/8/26 Igor Stasenko <siguctua(a)gmail.com>: > > > > On 26 August 2013 22:32, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> ... or another reason to answer the inspector window.. >> because right now it is badly broken: >> >> EyeInspector class>>inspect: anObject >> InspectorWrapper openInspector: (self inspector: anObject). >> ^ anObject >> >> but: >> >> Morph>>inspectInMorphic: evt >> evt hand attachMorph: ((Smalltalk tools inspect: self) extent: >> 300@200) >> >> that explains why, when i taking the morph's halo >> and then use debug context menu and press inspect it, >> it puts morph info the hand, and changing its dimensions.. >> instead of putting inspector window into hand! >> >> you can imagine how annoying it is, when you want to debug morphic code. >> >> The solution is, of course to answer an inspector window instead of >> inspected object.. or, since people argued against this, for such cases, >> there should be extra protocol, like >> >> Smalltalk tools inspectorWindowOn: object >> >> (i changed the code to answer a window right now, but we need to solve >> that dilemma) >> > ... i mean, changed in my working image. not in Pharo :) > >> >> -- >> Best regards, >> Igor Stasenko. > > > > > -- > Best regards, > Igor Stasenko.

Aug. 26, 2013

Re: [Pharo-dev] So, again, why 'object inspect' should answer an object?

by Igor Stasenko

On 26 August 2013 22:32, Igor Stasenko <siguctua(a)gmail.com> wrote: > ... or another reason to answer the inspector window.. > because right now it is badly broken: > > EyeInspector class>>inspect: anObject > InspectorWrapper openInspector: (self inspector: anObject). > ^ anObject > > but: > > Morph>>inspectInMorphic: evt > evt hand attachMorph: ((Smalltalk tools inspect: self) extent: 300@200 > ) > > that explains why, when i taking the morph's halo > and then use debug context menu and press inspect it, > it puts morph info the hand, and changing its dimensions.. > instead of putting inspector window into hand! > > you can imagine how annoying it is, when you want to debug morphic code. > > The solution is, of course to answer an inspector window instead of > inspected object.. or, since people argued against this, for such cases, > there should be extra protocol, like > > Smalltalk tools inspectorWindowOn: object > > (i changed the code to answer a window right now, but we need to solve > that dilemma) > > ... i mean, changed in my working image. not in Pharo :) > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Aug. 26, 2013

So, again, why 'object inspect' should answer an object?

by Igor Stasenko

... or another reason to answer the inspector window.. because right now it is badly broken: EyeInspector class>>inspect: anObject InspectorWrapper openInspector: (self inspector: anObject). ^ anObject but: Morph>>inspectInMorphic: evt evt hand attachMorph: ((Smalltalk tools inspect: self) extent: 300@200) that explains why, when i taking the morph's halo and then use debug context menu and press inspect it, it puts morph info the hand, and changing its dimensions.. instead of putting inspector window into hand! you can imagine how annoying it is, when you want to debug morphic code. The solution is, of course to answer an inspector window instead of inspected object.. or, since people argued against this, for such cases, there should be extra protocol, like Smalltalk tools inspectorWindowOn: object (i changed the code to answer a window right now, but we need to solve that dilemma) -- Best regards, Igor Stasenko.

Aug. 26, 2013

Re: [Pharo-dev] WhatsUp from: 2013-08-19 until: 2013-08-31

by phil＠highoctane.be

### Here's what I've been up to since the last WhatsUp: - Made a working web app stack and started an application that uses it. Kind of works. - Asked around for the Pharo advantage - Pushed Pharo technology for a project and associated funding. So far, so good - Got DBXTalk working with MySQL on OSX - Had holidays :-) ### What's next, until 2013-08-31 (*): - Refresh one site to host my Pharo offering

Aug. 26, 2013

Re: [Pharo-dev] WhatsUp from: 2013-08-19 until: 2013-08-31

by Sven Van Caekenberghe

On 19 Aug 2013, at 07:00, seaside(a)rmod.lille.inria.fr wrote: > Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! > > ### Here's what I've been up to since the last WhatsUp: - Published 'Building and deploying your first web app with Pharo - Understanding HTTP fundamentals through Zinc HTTP Components' [ http://zn.stfx.eu/zn/build-and-deploy-1st-webapp ] - Started new Pharo Consultants listing [ http://consultants.pharo.org ] - Started new Pharo Contributors listing [ http://contributors.pharo.org ] - Published code to generate these pages [ http://www.smalltalkhub.com/#!/~Pharo/PharoPeople ] - Published Stamp 'an implementation of STOMP, a protocol to interact with message-oriented middleware (RabbitMQ)' [ http://www.smalltalkhub.com/#!/~SvenVanCaekenberghe/Stamp ] > ### What's next, until 2013-08-31 (*): - Publish a proof of concept demo of Zinc-Server-Sent-Events (HTML5 Server-Sent Events) - Zinc refactoring/cleanup (ongoing) - Try again to fix Zinc socket stream bugs on Windows (failing unit tests) - Study Url/ZnUrl unification for Pharo 3 - Study Character-Encoding/Decoding unification for Pharo 3 - Study MIMEType/ZnMimeType unification for Pharo 3 Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Aug. 26, 2013

Re: [Pharo-dev] Spec tabs, which one is active ?

by Benjamin

A workaround could be that when a tab is selected, it set an instance variable with the correct value. This way , you can always do something like myCanvas generates. where myCanvas is set by the tab. And in addition, you do not have to use a switch case :) Ben On Aug 26, 2013, at 3:58 PM, Erwan Douaille <douailleerwan(a)gmail.com> wrote: > Hi, > > I'm using TabManager and i would like to know which tab is active. I didn't found any methods for that. > Any clue ? > > In UIPainter, i will use it to know which tab canvas i have to generate. > > Thanks :) > > -- > Best regards, > > Douaille Erwan <douaille.erwan(a)gmail.com>

Aug. 26, 2013

Re: [Pharo-dev] Need of a review

by Damien Cassou

On Mon, Aug 26, 2013 at 4:14 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I'll do a pass, since I burnt my fingers already on that code right before the 2.0 release :) I saw you just reviewed the code. Thank you. Now, this code is ready for inclusion. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Aug. 26, 2013