August 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [update 2.0] #20619

by Sven Van Caekenberghe

On 24 Aug 2013, at 18:29, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Yes, super cool! Yeah, pure magic ! > On Sat, Aug 24, 2013 at 6:10 AM, MartinW <wm(a)fastmail.fm> wrote: > Goubier Thierry wrote > > Thanks Esteban :) > > > > The speedup on loading MC packages is 3x or more, so I though it is a > > crime not to make it available immediately, since there is no bug reports > > in all our tests and usages. > > Thanks Thierry for the backport! > > Yes, thank you both! While i haven't measured anything it feels MUCH faster > when i load extensive configurations. > > > > -- > View this message in context: http://forum.world.st/update-2-0-20619-tp4703465p4704839.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > > -- > Mariano > http://marianopeck.wordpress.com

Aug. 27, 2013

Re: [Pharo-dev] Debugger recursion

by jan.struz

I'm on Pharo 2, exactly this case - infinite loops or image crashes, I will try it in Pharo 3, and see the difference. ClÃ©ment Bera-4 wrote > Hello, > > Are you on Pharo 2 or 3 ? > > In Pharo 2, debugging or inspecting with ProtoObject subclasses resulted > in > infinite loops or image crashes. I tried to have a look with the new > debugger and inspectors in Pharo 3 but there is still some work to do. > > > 2013/8/24 jan.struz < > public+pharo@ > > > >> StÃ©phane Ducasse wrote >> > On Aug 23, 2013, at 7:13 PM, jan.struz < >> >> > public+pharo@ >> >> > > wrote: >> > >> >> Proxy implementation >> > >> > did you have a look at Ghost because mariano spent nearly a year on it. >> > >> > I do not really know what are the messages supposed to be supported by >> > ProtoObject to be debugged >> > May be it is not in the contract of ProtoObject and as such it produces >> > normally an infinite loop. >> > >> > Stef >> >> ok, so the rule is: never subclass ProtoObject to make Debugger crazy.. >> I will definitely look at Ghost, it has already been on my todo list.. >> >> thanks >> >> >> >> >> >> ----- >> Save The World! >> -- >> View this message in context: >> http://forum.world.st/Debugger-recursion-tp4704703p4704864.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> ----- Save The World! -- View this message in context: http://forum.world.st/Debugger-recursion-tp4704703p4705301.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 27, 2013

Compilation code in grease not compatible with Pharo 3.0

by Damien Cassou

Hi, how can I make the following code compile in Pharo 3.0? This is part of Grease ( https://ci.inria.fr/pharo-contribution/job/Grease/PHARO=30,VERSION=stable,V… ): GRPharoPlatform>>compile: aString into: aClass classified: aSymbol "The trick here is to be as silently a possible so that the package is not marked dirty when running WAFileLibrary test. This also makes running tests much faster." | methodNode compiledMethod selector methodAndNode | methodNode := aClass compilerClass new compile: aString in: aClass notifying: nil ifFail: [ GRError signal: 'syntax error' ]. selector := methodNode selector. methodAndNode := CompiledMethodWithNode generateMethodFromNode: methodNode trailer: aClass defaultMethodTrailer. compiledMethod := methodAndNode method. compiledMethod putSource: aString fromParseNode: methodAndNode node inFile: 2 withPreamble: [ :file | aClass printCategoryChunk: aSymbol asString on: file priorMethod: (aClass compiledMethodAt: selector ifAbsent: [ nil ]). file cr ]. aClass addSelectorSilently: selector withMethod: compiledMethod. self doSilently: [ aClass organization classify: selector under: aSymbol ] -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Aug. 27, 2013

Fwd: New Consortium Member: COETIC

by Marcus Denker

Begin forwarded message: > From: Marcus Denker <marcus.denker(a)inria.fr> > Subject: New Consortium Member: COETIC > Date: August 27, 2013 4:44:55 PM GMT+02:00 > > The Pharo Consortium welcomes a new member company: COETIC > > COETIC is joining as a Bronze Member. > > More about... > > - COETIC: http://www.coetic.com > - Pharo: http://pharo.org > - Pharo Consortium: http://consortium.pharo.org > >

Aug. 27, 2013

Re: [Pharo-dev] Rubrik, scroll to end?

by Tudor Girba

I also thinks it sounds good now. I love this type of discussions. Doru On Tue, Aug 27, 2013 at 3:19 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > > Alain wrote: > >Maybe something like: > >#scrollToEndOfText, #scrollToBeginningOfText, #scrollToEndOfLine, > #scrollToBeginningOfLine. > >#pageUp, #pageDown, #pageLeft, #pageRight. > > Clear to me, thank you > > Stephan > > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 27, 2013

[update 3.0] #30347

by Marcus Denker

30347 ----- 11464 Switch RBPackageEnvironment to RPackage https://pharo.fogbugz.com/f/cases/11464 11449 Remove Time class >> #namesForTimes: https://pharo.fogbugz.com/f/cases/11449 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Tests-Environment… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Environment-Marcu… http://smalltalkhub.com/mc/Pharo/Pharo30/main/RPackage-Core-MarcusDenker.25… http://smalltalkhub.com/mc/Pharo/Pharo30/main/NECompletion-MarcusDenker.128… http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-MarcusDenker.554.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1577.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/HudsonBuildTools20-MarcusDenk…

Aug. 27, 2013

Re: [Pharo-dev] Rubrik, scroll to end?

by Stephan Eggermont

Alain wrote: >Maybe something like: >#scrollToEndOfText, #scrollToBeginningOfText, #scrollToEndOfLine, #scrollToBeginningOfLine. >#pageUp, #pageDown, #pageLeft, #pageRight. Clear to me, thank you Stephan

Aug. 27, 2013

Re: [Pharo-dev] Rubrik, scroll to end?

by plantec

Hi Stephan, Thanks for your feedbacks, finding good names is always an issue for me. Maybe something like: #scrollToEndOfText, #scrollToBeginningOfText, #scrollToEndOfLine, #scrollToBeginningOfLine. #pageUp, #pageDown, #pageLeft, #pageRight. Cheers Alain Le 27 aoÃ»t 2013 Ã 12:54, Stephan Eggermont <stephan(a)stack.nl> a Ã©crit : > In my experience, top and bottom are terminology from the visible domain, > not from the contents. That could confuse users. In a non-wrapped text, > is there going to be a scroll to top left and bottom right, or rather to > the beginning of the first/last line? Or as it is now, ignoring the horizontal > position? > > Stephan > > >

Aug. 27, 2013

Re: [Pharo-dev] Debugger recursion

by ClÃ©ment Bera

Hello, Are you on Pharo 2 or 3 ? In Pharo 2, debugging or inspecting with ProtoObject subclasses resulted in infinite loops or image crashes. I tried to have a look with the new debugger and inspectors in Pharo 3 but there is still some work to do. 2013/8/24 jan.struz <public+pharo(a)struz.cz> > StÃ©phane Ducasse wrote > > On Aug 23, 2013, at 7:13 PM, jan.struz < > > > public+pharo@ > > > > wrote: > > > >> Proxy implementation > > > > did you have a look at Ghost because mariano spent nearly a year on it. > > > > I do not really know what are the messages supposed to be supported by > > ProtoObject to be debugged > > May be it is not in the contract of ProtoObject and as such it produces > > normally an infinite loop. > > > > Stef > > ok, so the rule is: never subclass ProtoObject to make Debugger crazy.. > I will definitely look at Ghost, it has already been on my todo list.. > > thanks > > > > > > ----- > Save The World! > -- > View this message in context: > http://forum.world.st/Debugger-recursion-tp4704703p4704864.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Aug. 27, 2013

Re: [Pharo-dev] Rubrik, scroll to end?

by Stephan Eggermont

In my experience, top and bottom are terminology from the visible domain, not from the contents. That could confuse users. In a non-wrapped text, is there going to be a scroll to top left and bottom right, or rather to the beginning of the first/last line? Or as it is now, ignoring the horizontal position? Stephan

Aug. 27, 2013

[update 3.0] #30346

by Marcus Denker

30346 ----- 11452 Adding a trait to a composition makes too many changes to a class https://pharo.fogbugz.com/f/cases/11452 11426 Extract the logic that opens the .sources and .changes files https://pharo.fogbugz.com/f/cases/11426 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.9… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Slot-MarcusDenker.375.diff

Aug. 27, 2013

Re: [Pharo-dev] Installing Rubrik into 3alpha

by plantec

Hi Esteban, RubTextModel does not work. It was for Spec but I don't have enough time to dig more and make it work. So, I will remove this class. Cheers Alain Le 15 aoÃ»t 2013 Ã 12:08, Esteban Lorenzano <estebanlm(a)gmail.com> a Ã©crit : > Hi, > > I tried to install Rubrik in 3alpha (yes, yes, I know... is development, etc., etc., but I wanted to test precisely how it is behaving a text package with the changes we are introducing :) ) > Well... configuration fails because there is a "repeated slot", enabledHolder. > > This is because RubTextModel is shadowing a property that already exists on AbstractBasicWidget (and that's not allowed with new opal compiler). > > Now... I just removed it on RubTextModel and everything is working so... I wonder if this change could be introduced so I can continue playing without need to hack it each time? ;) > > cheers, > Esteban

Aug. 27, 2013

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

by Benjamin

I thought there was such a registration method :s Ben On Aug 27, 2013, at 11:25 AM, Erwan Douaille <douailleerwan(a)gmail.com> wrote: > > > > 2013/8/26 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> > A workaround could be that when a tab is selected, it set an instance variable with the correct value. > > Yes, it will be cool. But i didn't find something like "whenTabSelectionChanged:" in tabManager or tab model. > How can i catch the selection event? > 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 :) > > yes > 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> > > > Thanks :) > > -- > Best regards, > > Douaille Erwan <douaille.erwan(a)gmail.com>

Aug. 27, 2013

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

by Erwan Douaille

2013/8/26 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> > A workaround could be that when a tab is selected, it set an instance > variable with the correct value. > > Yes, it will be cool. But i didn't *find* something like "whenTabSelectionChanged:" in tabManager or tab model. How can i catch the selection event? > 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 :) > > yes > 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> > > > Thanks :) -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

Aug. 27, 2013

Re: [Pharo-dev] Rubrik, scroll to end?

by plantec

Hi, I've added #scrollToTop and #scrollToBottom in RubScrolledTextMorph. Notice that you can use a RubConfigurationChanged announcement to reconfigure views: | consoleTextModel | consoleTextModel := RubScrolledTextModel new. (consoleTextModel newScrolledText beWrapped embeddedInMorphicWindowLabeled: 'Rubric try') openInWorld. consoleTextModel setText: 'some text .....'. consoleTextModel announce: (RubConfigurationChanged new configurationBlock: [:view | view scrollToBottom ]) or: | consoleTextModel | consoleTextModel := RubScrolledTextModel new. (consoleTextModel newScrolledText beWrapped embeddedInMorphicWindowLabeled: 'Rubric try') openInWorld. consoleTextModel setText: 'some text .....'. consoleTextModel reconfigureViewWith: [:view | view scrollToBottom ]. Cheers Alain Le 23 aoÃ»t 2013 Ã 11:49, Esteban Lorenzano <estebanlm(a)gmail.com> a Ã©crit : > in an incredible ugly way, yes... :) > > consoleTextModel := RubScrolledTextModel new. > consoleTextArea := consoleTextModel newScrolledText beWrapped. > > ... > > consoleTextArea scrollPane > vScrollbarValue: 1; > updateScrollbars. > > On Aug 23, 2013, at 11:44 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > >> Esteban, >> >> Did you success to do it? do you know how to "scroll-to-end" in spec/morph? >> >> MartÃn >> >> >> On Thu, Aug 15, 2013 at 5:56 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Hi guys, >> >> anyone knows how to do a "scroll-to-end" with rubrik? >> >> thanks, >> Esteban >> >> >

Aug. 27, 2013

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

by Igor Stasenko

On 19 August 2013 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: > > Mainly working on TxModel rendering with Athens and laying it out. Have slow but steady progress (need to solve a lot of tiny details, along the way > ### What's next, until 2013-08-31 (*): > Finish a text view morph and put more flesh in text layout & rendering engine, provide a coordinate feedback (point<->position).. and start thinking about notificaitons for doing smart updates (so when user edits or navigates the text, to update minimal portions on screen/recompute minimal necessary layout) > (*) we'll be expecting results by then ;) > > -- Best regards, Igor Stasenko.

Aug. 27, 2013

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

by Igor Stasenko

done https://pharo.fogbugz.com/default.asp?11465#83505 On 26 August 2013 22:54, Camillo Bruni <camillobruni(a)gmail.com> wrote: > that is pretty new, so we didn't fix this issue then :/ (or more probably, > we didn't fix all users). > > => can you open an issue with a description on how to reproduce it? > > > On 2013-08-26, at 22:52, Igor Stasenko <siguctua(a)gmail.com> wrote: > > (oops.. pressed send before finishing mail) > > > > Pharo3.0 > > Latest update: #30335 > > > > .. so it just 10 days old > > > > > > On 26 August 2013 22:51, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > >> 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. > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > -- Best regards, Igor Stasenko.

Aug. 27, 2013

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

by Igor Stasenko

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 > > well, it won't work that way.. #inspector: returns the inspector model , but not the actual morph i don't know how to get the window morph from it (maybe its easy?).. I mean, even if you change this to use #inspector: instead of #inspect: Morph>>inspectInMorphic: evt evt hand attachMorph: ((Smalltalk tools inspect: self) extent: 300@200) it won't work (#extent: did not understood by inspector object, neither you can attach it to hand). So, i forced to change this method to look like this: inspectInMorphic: evt Smalltalk tools inspect: self yeah.. i will open the issue then. -- Best regards, Igor Stasenko.

Aug. 27, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/… 1 regressions found. Zinc.Zodiac.ZnHTTPSTests.testGetPharoVersion

Aug. 27, 2013

Re: [Pharo-dev] [update 3.0] #30345

by StÃ©phane Ducasse

Thanks I plan to retry to do some integration now that I have the information about what to do when it fails. On Aug 27, 2013, at 10:05 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 30345 > ----- > > 11462 Wrong comment in testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses > https://pharo.fogbugz.com/f/cases/11462 > > 11463 RBRefactoringChangeTests >> #testAddMetaclassPattern takes too much time > https://pharo.fogbugz.com/f/cases/11463 > > 11460 TabModel>>closeable: is not working > https://pharo.fogbugz.com/f/cases/11460 > > > Diff information: > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-MarcusDenker.615.diff > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.229… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Tests-Changes-Mar… >

Aug. 27, 2013

[update 3.0] #30345

by Marcus Denker

30345 ----- 11462 Wrong comment in testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses https://pharo.fogbugz.com/f/cases/11462 11463 RBRefactoringChangeTests >> #testAddMetaclassPattern takes too much time https://pharo.fogbugz.com/f/cases/11463 11460 TabModel>>closeable: is not working https://pharo.fogbugz.com/f/cases/11460 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-MarcusDenker.615.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.229… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Tests-Changes-Mar…

Aug. 27, 2013

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

by Camillo Bruni

that is pretty new, so we didn't fix this issue then :/ (or more probably, we didn't fix all users). => can you open an issue with a description on how to reproduce it? On 2013-08-26, at 22:52, Igor Stasenko <siguctua(a)gmail.com> wrote: > (oops.. pressed send before finishing mail) > > Pharo3.0 > Latest update: #30335 > > .. so it just 10 days old > > > On 26 August 2013 22:51, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> 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. >> > > > > -- > Best regards, > Igor Stasenko.

Aug. 26, 2013

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

by Igor Stasenko

(oops.. pressed send before finishing mail) Pharo3.0 Latest update: #30335 .. so it just 10 days old On 26 August 2013 22:51, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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. > -- Best regards, Igor Stasenko.

Aug. 26, 2013

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

Re: [Pharo-dev] what is the new way to do Smalltalk at: #MyClass?

by Camille Teruel

On 26 aoÃ»t 2013, at 15:04, Igor Stasenko wrote: > > > > On 26 August 2013 14:34, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 26 aoÃ»t 2013, at 13:31, Igor Stasenko wrote: > >> the intent was to replace >> Smalltalk at: >> Smalltalk globals at: >> >> idioms with shorter one, and get rid of referencing Smalltalk global. >> The are not for solving future problems with introduction of environments. > > We want to get rid of Smalltalk globals because it currently resolve to an instance of SmalltalkImage, a class that does way too much things, including holding the currently unique environment, while a global could directly refer to it. > > Also the references to Smalltalk globals that where really wrong are already gone and were in compiler. > >> And even if you introduce them, i still think you need a way to refer to globals (they are likely to stay) > > Globals are global to their environment. We could also call them environment variable. > > Nope. In current system it is something else. It is a global variable not local to any environment. In the current system (in fact since Pharo 1.3 I think) we have that: Object subclass: #A. envA := SystemDictionary new. envA at: #Smalltalk put: 33. A environment: envA. A compile: 'st ^ Smalltalk'. A new st -----> 33 > And you will certainly have problems with old (and not so) code, if you swap the meaning (and underlying semantic) > of globals to anything else you may want. Again, that doesn't change the semantic! The problems will only appear once several environment will be introduced. Code in dev tools that try to fetch a global via ThisEnvironment (the one of tool package) instead of someClass environment (the one of a class the tool display, inspect, browse...). The very same problems would happen with #asClass, except that this time, we'll have to revisit all the senders of #asClass and company. > This is what i trying to point out. In this case, #asClass is good, because it makes sure that old semantics will be preserved, > no matter what changes we may do. It just ensure to lock the system in its current state... > It also will allow us to revisit all senders of #asClass and easily change them to something else when we will be ready for that.. > and btw it will be much easier comparing to visiting all uses of Smalltalk or all uses of ThisEnvironment. So browsing senders of #asClass, #asClassIfPresent:, #asClassIfAbsent: and #asClassIfAbsent:ifPresent: is much more easy than browsing reference to ThisEnvironment? And you would most probably never have to visit the reference to ThisEnvironment...

Aug. 26, 2013

Re: [Pharo-dev] Need of a review

by Camillo Bruni

I'll do a pass, since I burnt my fingers already on that code right before the 2.0 release :) On 2013-08-26, at 16:12, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Could someone please review this change? > > Extract the logic that opens the .sources and .changes files > > This logic is currently in the SmalltalkImage class. The code is hard > to read and enhance. Extracting the logic to its own class will fix > these issues. > > https://pharo.fogbugz.com/default.asp?11426 > > -- > 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

Need of a review

by Damien Cassou

Could someone please review this change? Extract the logic that opens the .sources and .changes files This logic is currently in the SmalltalkImage class. The code is hard to read and enhance. Extracting the logic to its own class will fix these issues. https://pharo.fogbugz.com/default.asp?11426 -- 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

[update 3.0] #30344

by Marcus Denker

30344 ----- 6821 Inconsistent String>>asDate behaviour https://pharo.fogbugz.com/f/cases/6821 11446 recategorize compareWith:ifLesser:ifEqual:ifGreater: https://pharo.fogbugz.com/f/cases/11446 11431 #sorted: is broken for some collections https://pharo.fogbugz.com/f/cases/11431 11459 Failing test: .testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits https://pharo.fogbugz.com/f/cases/11459 (this changes Athens, I will commit this back into the Athens repo later) Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tabs-MarcusDenker.29.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1575.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/CollectionsTests-MarcusDenker… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Traits-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Sequenceable-Marc… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Athens-Cairo-MarcusDenker.51.…

Aug. 26, 2013

Re: [Pharo-dev] what is the new way to do Smalltalk at: #MyClass?

by Frank Shearar

On 26 August 2013 13:34, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 26 aoÃ»t 2013, at 13:31, Igor Stasenko wrote: > > the intent was to replace > Smalltalk at: > Smalltalk globals at: > > idioms with shorter one, and get rid of referencing Smalltalk global. > > The are not for solving future problems with introduction of environments. > > > We want to get rid of Smalltalk globals because it currently resolve to an > instance of SmalltalkImage, a class that does way too much things, including > holding the currently unique environment, while a global could directly > refer to it. > > Also the references to Smalltalk globals that where really wrong are already > gone and were in compiler. > > And even if you introduce them, i still think you need a way to refer to > globals (they are likely to stay) > > > Globals are global to their environment. We could also call them environment > variable. > > > Whatever we will use for binding symbols in local environment, this is > orthogonal. > > Now you proposing introduce > ThisEnvironment at: > > > which getting back where we started from. > > > No because ThisEnvironment would be an instance of Environment (basically a > refactored SystemDictionary) not of SmalltalkImage. > So who should be in charge of knowing how to handle accessible variable? > An instance of Environment with a nice api or an instance of Symbol by > herself? Squeak 4.5 already does this. Please take a look at the Environment class and see how it works, especially as far as getting it into the image in the first place. frank > Unless , in your vision ThisEnvironment handled by compiler (like > thisContext).. > > so there will be no new global, but ThisEnvironment bound at compile time. > > > anyways, it will be semantically different from what we have now, > it will lookup for symbol in local environment, instead of global one. > > > ThisEnvironment would not be different than any other global. > There is no semantic change, no magic, nothing. > That's what the compiler already does. > The compiler use the environment of the class of the method being compiled > to resolve globals. > It happens that all classes currently share the same environment, that's > something else. > > > And this is not going to happen (you cannot replace > Smalltalk globals at: with ThisEnvironment at: without overlooking all the > places where it used)... > while replacing it with #asClass is fine (because semantics stays same). > > > Also, #asClass means 'give me the class or throw error', while > Smalltalk globals at: , obviously don't do that and gives you any object > bound to given symbol, if it there. > > > Any control? > at:ifAbsent: > at:ifPresent: > at:ifAbsent:ifPresent: > are already there and if you want to ensure the global is a class you could > have: classNamed:ifAbsent:ifPresent: > > > > > > On 26 August 2013 12:31, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> >> >> On 26 aoÃ»t 2013, at 10:56, Esteban Lorenzano wrote: >> >> > >> > On Aug 25, 2013, at 9:40 AM, Camille Teruel <camille.teruel(a)gmail.com> >> > wrote: >> > >> >> >> >> On 24 aoÃ»t 2013, at 19:20, Camillo Bruni wrote: >> >> >> >>> We have now: >> >>> >> >>> String >> #asClass >> >>> String >> #asClassIfAbsent: >> >>> String >> #asClassIfPresent: >> >> >> >> I don't understand why we need this new way. >> >> Is it just to avoid calling 'Smalltalk globals at: #MyClass'? >> > >> > exactly >> > >> >> Because these names are confusing, and the 'as' prefix suggests a >> >> conversion while it's an access (with indirection but still a mere access). >> >> And #asClass has no sender. >> >> If you think 'Smalltalk globals at: #MyClass' is really too long to >> >> type, lets just create a new global ThisEnvironment := Smalltalk globals. >> > >> > this was already discussed. With #asClass and relatives what you have is >> > a better abstraction jut because you are decoupled of "Smalltalk globals", >> > it is not a big win now, but it open doors to better designs with >> > environments, etc. >> > At least, that was my understanding when the issue arise at the >> > beginning. >> >> It's not a better abstraction, it's a worse one. >> Sending #asClass to a symbol will ever execute the same method that anyway >> as to rely on a global: Smalltalk. >> And this global is solved in only one environment: the one of the class >> Symbol where #asClass and co. are implemented. >> So if you want separated environments you know what kind of thing you'll >> end up writing? >> >> '#Foo asClassInEnvitonment: self class environment' >> >> or implementing: >> >> Symbol>>#asClass >> ^ self asClassInEnvironment: thisContext sender receiver class >> environment >> >> However, as soon as the compiler use the environment of the compiled >> method's class to solves the globals it contains, Smalltalk can refer to >> anything. >> So the only problem with: 'Smalltalk globals at:' is that you send a >> message #globals to the global Smalltalk to fetch the environment while we >> could just have a global ThisEnvironment pointing to itself. >> >> Writting 'ThisEnvironment at: #Foo' is much more natural. >> >> If we want separated environments, each environment just have to define a >> binding ThisEnvironment pointing to itself and everything works well. >> What I don't like with #asClass and co. is the style: you talk to a symbol >> instead of an environment. >> It's like saying: '#key valueIn: aDict' instead of: 'aDict at: #key', >> 'letter beSentBy: postman to: receiver' instead of: 'postman send: letter >> to: receiver', etc... >> >> In Smalltalk we already have self to refer to the current receiver and >> thisContext to refer to the current stack frame. If we want different >> environments, is it that weird to have a ThisEnvironment to refer to the >> current environment? >> >> > >> > Esteban >> > >> >> >> >> >> >>> >> >>> On 2013-08-24, at 17:55, Fernando Olivero <fernando.olivero(a)usi.ch> >> >>> wrote: >> >>>> I prefer to evaluate >> >>>> >> >>>> Smalltalk globals classNamed: #MyClass >> >>>> >> >>>> Fernando >> >>>> >> >>>> On Sat, Aug 24, 2013 at 11:57 AM, StÃ©phane Ducasse >> >>>> <stephane.ducasse(a)inria.fr> wrote: >> >>>>> >> >>>>> Is it >> >>>>> >> >>>>> asClass? >> >>>>> >> >>>>> Stef >> >>>>> >> >>>> >> >>> >> >>> >> >> >> >> >> > >> > >> >> > > > > -- > Best regards, > Igor Stasenko. > >

Aug. 26, 2013

Re: [Pharo-dev] what is the new way to do Smalltalk at: #MyClass?

by Camillo Bruni

https://pharo.fogbugz.com/f/cases/10583/Use-System-instead-of-Smalltalk-to-… On 2013-08-26, at 15:54, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > ... and Smalltalk should be renamed into Pharo anyway. > > :-p > > Phil > > > > On Monday, August 26, 2013, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> >> >> On 26 August 2013 14:34, Camille Teruel <camille.teruel(a)gmail.com> wrote: >>> >>> On 26 aoÃ»t 2013, at 13:31, Igor Stasenko wrote: >>> >>> the intent was to replace >>> Smalltalk at: >>> Smalltalk globals at: >>> >>> idioms with shorter one, and get rid of referencing Smalltalk global. >>> >>> The are not for solving future problems with introduction of > environments. >>> >>> We want to get rid of Smalltalk globals because it currently resolve to > an instance of SmalltalkImage, a class that does way too much things, > including holding the currently unique environment, while a global could > directly refer to it. >>> Also the references to Smalltalk globals that where really wrong are > already gone and were in compiler. >>> >>> And even if you introduce them, i still think you need a way to refer to > globals (they are likely to stay) >>> >>> Globals are global to their environment. We could also call them > environment variable. >> >> Nope. In current system it is something else. It is a global variable not > local to any environment. >> And you will certainly have problems with old (and not so) code, if you > swap the meaning (and underlying semantic) >> of globals to anything else you may want. >> This is what i trying to point out. In this case, #asClass is good, > because it makes sure that old semantics will be preserved, >> no matter what changes we may do. >> It also will allow us to revisit all senders of #asClass and easily > change them to something else when we will be ready for that.. >> and btw it will be much easier comparing to visiting all uses of > Smalltalk or all uses of ThisEnvironment. >> >> >> > > -- > --- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 > Mail:phil@highoctane.be | Web: http://philippeback.eu > Blog: http://philippeback.be | Twitter: @philippeback > Youtube: http://www.youtube.com/user/philippeback/videos > > High Octane SPRL > rue cour Boisacq 101 | 1301 Bierges | Belgium > > Pharo Consortium Member - http://consortium.pharo.org/ > Featured on the Software Process and Measurement Cast - > http://spamcast.libsyn.com > Sparx Systems Enterprise Architect and Ability Engineering EADocX Value > Added Reseller

Aug. 26, 2013

Re: [Pharo-dev] what is the new way to do Smalltalk at: #MyClass?

by StÃ©phane Ducasse

On Aug 26, 2013, at 3:54 PM, phil(a)highoctane.be wrote: > ... and Smalltalk should be renamed into Pharo anyway. > > :-p :) Camillo already wants systems. Stef

Aug. 26, 2013

Spec tabs, which one is active ?

by Erwan Douaille

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] what is the new way to do Smalltalk at: #MyClass?

by phil＠highoctane.be

... and Smalltalk should be renamed into Pharo anyway. :-p Phil On Monday, August 26, 2013, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 26 August 2013 14:34, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> >> On 26 aoÃ»t 2013, at 13:31, Igor Stasenko wrote: >> >> the intent was to replace >> Smalltalk at: >> Smalltalk globals at: >> >> idioms with shorter one, and get rid of referencing Smalltalk global. >> >> The are not for solving future problems with introduction of environments. >> >> We want to get rid of Smalltalk globals because it currently resolve to an instance of SmalltalkImage, a class that does way too much things, including holding the currently unique environment, while a global could directly refer to it. >> Also the references to Smalltalk globals that where really wrong are already gone and were in compiler. >> >> And even if you introduce them, i still think you need a way to refer to globals (they are likely to stay) >> >> Globals are global to their environment. We could also call them environment variable. > > Nope. In current system it is something else. It is a global variable not local to any environment. > And you will certainly have problems with old (and not so) code, if you swap the meaning (and underlying semantic) > of globals to anything else you may want. > This is what i trying to point out. In this case, #asClass is good, because it makes sure that old semantics will be preserved, > no matter what changes we may do. > It also will allow us to revisit all senders of #asClass and easily change them to something else when we will be ready for that.. > and btw it will be much easier comparing to visiting all uses of Smalltalk or all uses of ThisEnvironment. > > > -- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

Aug. 26, 2013

Re: [Pharo-dev] what is the new way to do Smalltalk at: #MyClass?

by Igor Stasenko

On 26 August 2013 14:34, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 26 aoÃ»t 2013, at 13:31, Igor Stasenko wrote: > > the intent was to replace > Smalltalk at: > Smalltalk globals at: > > idioms with shorter one, and get rid of referencing Smalltalk global. > > The are not for solving future problems with introduction of environments. > > > We want to get rid of Smalltalk globals because it currently resolve to an > instance of SmalltalkImage, a class that does way too much things, > including holding the currently unique environment, while a global could > directly refer to it. > > Also the references to Smalltalk globals that where really wrong are > already gone and were in compiler. > > And even if you introduce them, i still think you need a way to refer to > globals (they are likely to stay) > > > Globals are global to their environment. We could also call them > environment variable. > > Nope. In current system it is something else. It is a global variable not local to any environment. And you will certainly have problems with old (and not so) code, if you swap the meaning (and underlying semantic) of globals to anything else you may want. This is what i trying to point out. In this case, #asClass is good, because it makes sure that old semantics will be preserved, no matter what changes we may do. It also will allow us to revisit all senders of #asClass and easily change them to something else when we will be ready for that.. and btw it will be much easier comparing to visiting all uses of Smalltalk or all uses of ThisEnvironment.

Aug. 26, 2013

Re: [Pharo-dev] what is the new way to do Smalltalk at: #MyClass?

by Camille Teruel

On 26 aoÃ»t 2013, at 13:31, Igor Stasenko wrote: > the intent was to replace > Smalltalk at: > Smalltalk globals at: > > idioms with shorter one, and get rid of referencing Smalltalk global. > The are not for solving future problems with introduction of environments. We want to get rid of Smalltalk globals because it currently resolve to an instance of SmalltalkImage, a class that does way too much things, including holding the currently unique environment, while a global could directly refer to it. Also the references to Smalltalk globals that where really wrong are already gone and were in compiler. > And even if you introduce them, i still think you need a way to refer to globals (they are likely to stay) Globals are global to their environment. We could also call them environment variable. > Whatever we will use for binding symbols in local environment, this is orthogonal. > Now you proposing introduce > ThisEnvironment at: > > which getting back where we started from. No because ThisEnvironment would be an instance of Environment (basically a refactored SystemDictionary) not of SmalltalkImage. So who should be in charge of knowing how to handle accessible variable? An instance of Environment with a nice api or an instance of Symbol by herself? > Unless , in your vision ThisEnvironment handled by compiler (like thisContext).. > so there will be no new global, but ThisEnvironment bound at compile time. > > anyways, it will be semantically different from what we have now, > it will lookup for symbol in local environment, instead of global one. ThisEnvironment would not be different than any other global. There is no semantic change, no magic, nothing. That's what the compiler already does. The compiler use the environment of the class of the method being compiled to resolve globals. It happens that all classes currently share the same environment, that's something else. > And this is not going to happen (you cannot replace > Smalltalk globals at: with ThisEnvironment at: without overlooking all the places where it used)... > while replacing it with #asClass is fine (because semantics stays same). > > Also, #asClass means 'give me the class or throw error', while > Smalltalk globals at: , obviously don't do that and gives you any object bound to given symbol, if it there. Any control? at:ifAbsent: at:ifPresent: at:ifAbsent:ifPresent: are already there and if you want to ensure the global is a class you could have: classNamed:ifAbsent:ifPresent: > > > > > On 26 August 2013 12:31, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 26 aoÃ»t 2013, at 10:56, Esteban Lorenzano wrote: > > > > > On Aug 25, 2013, at 9:40 AM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > > >> > >> On 24 aoÃ»t 2013, at 19:20, Camillo Bruni wrote: > >> > >>> We have now: > >>> > >>> String >> #asClass > >>> String >> #asClassIfAbsent: > >>> String >> #asClassIfPresent: > >> > >> I don't understand why we need this new way. > >> Is it just to avoid calling 'Smalltalk globals at: #MyClass'? > > > > exactly > > > >> Because these names are confusing, and the 'as' prefix suggests a conversion while it's an access (with indirection but still a mere access). > >> And #asClass has no sender. > >> If you think 'Smalltalk globals at: #MyClass' is really too long to type, lets just create a new global ThisEnvironment := Smalltalk globals. > > > > this was already discussed. With #asClass and relatives what you have is a better abstraction jut because you are decoupled of "Smalltalk globals", it is not a big win now, but it open doors to better designs with environments, etc. > > At least, that was my understanding when the issue arise at the beginning. > > It's not a better abstraction, it's a worse one. > Sending #asClass to a symbol will ever execute the same method that anyway as to rely on a global: Smalltalk. > And this global is solved in only one environment: the one of the class Symbol where #asClass and co. are implemented. > So if you want separated environments you know what kind of thing you'll end up writing? > > '#Foo asClassInEnvitonment: self class environment' > > or implementing: > > Symbol>>#asClass > ^ self asClassInEnvironment: thisContext sender receiver class environment > > However, as soon as the compiler use the environment of the compiled method's class to solves the globals it contains, Smalltalk can refer to anything. > So the only problem with: 'Smalltalk globals at:' is that you send a message #globals to the global Smalltalk to fetch the environment while we could just have a global ThisEnvironment pointing to itself. > > Writting 'ThisEnvironment at: #Foo' is much more natural. > > If we want separated environments, each environment just have to define a binding ThisEnvironment pointing to itself and everything works well. > What I don't like with #asClass and co. is the style: you talk to a symbol instead of an environment. > It's like saying: '#key valueIn: aDict' instead of: 'aDict at: #key', 'letter beSentBy: postman to: receiver' instead of: 'postman send: letter to: receiver', etc... > > In Smalltalk we already have self to refer to the current receiver and thisContext to refer to the current stack frame. If we want different environments, is it that weird to have a ThisEnvironment to refer to the current environment? > > > > > Esteban > > > >> > >> > >>> > >>> On 2013-08-24, at 17:55, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > >>>> I prefer to evaluate > >>>> > >>>> Smalltalk globals classNamed: #MyClass > >>>> > >>>> Fernando > >>>> > >>>> On Sat, Aug 24, 2013 at 11:57 AM, StÃ©phane Ducasse > >>>> <stephane.ducasse(a)inria.fr> wrote: > >>>>> > >>>>> Is it > >>>>> > >>>>> asClass? > >>>>> > >>>>> Stef > >>>>> > >>>> > >>> > >>> > >> > >> > > > > > > > > > > -- > Best regards, > Igor Stasenko.

Aug. 26, 2013

Re: [Pharo-dev] [update 3.0] #30343

by Camillo Bruni

thanks :) On 2013-08-26, at 13:42, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 30343 > ----- > > 11447 Improve Chronology > https://pharo.fogbugz.com/f/cases/11447 > > 11456 RBLiteralValueNode does not Understand shortPrintOn: > https://pharo.fogbugz.com/f/cases/11456 > > > Diff information: > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1219.diff > http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.9… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Network-Mail-MarcusDenker.21.… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.76.… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-MarcusDenker.552.… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1574.diff >

Aug. 26, 2013

[update 3.0] #30343

by Marcus Denker

30343 ----- 11447 Improve Chronology https://pharo.fogbugz.com/f/cases/11447 11456 RBLiteralValueNode does not Understand shortPrintOn: https://pharo.fogbugz.com/f/cases/11456 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1219.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.9… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Network-Mail-MarcusDenker.21.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.76.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-MarcusDenker.552.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1574.diff

Aug. 26, 2013

Re: [Pharo-dev] what is the new way to do Smalltalk at: #MyClass?

by Igor Stasenko

the intent was to replace Smalltalk at: Smalltalk globals at: idioms with shorter one, and get rid of referencing Smalltalk global. The are not for solving future problems with introduction of environments. And even if you introduce them, i still think you need a way to refer to globals (they are likely to stay). Whatever we will use for binding symbols in local environment, this is orthogonal. Now you proposing introduce ThisEnvironment at: which getting back where we started from. Unless , in your vision ThisEnvironment handled by compiler (like thisContext).. so there will be no new global, but ThisEnvironment bound at compile time. anyways, it will be semantically different from what we have now, it will lookup for symbol in local environment, instead of global one. And this is not going to happen (you cannot replace Smalltalk globals at: with ThisEnvironment at: without overlooking all the places where it used)... while replacing it with #asClass is fine (because semantics stays same). Also, #asClass means 'give me the class or throw error', while Smalltalk globals at: , obviously don't do that and gives you any object bound to given symbol, if it there. On 26 August 2013 12:31, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 26 aoÃ»t 2013, at 10:56, Esteban Lorenzano wrote: > > > > > On Aug 25, 2013, at 9:40 AM, Camille Teruel <camille.teruel(a)gmail.com> > wrote: > > > >> > >> On 24 aoÃ»t 2013, at 19:20, Camillo Bruni wrote: > >> > >>> We have now: > >>> > >>> String >> #asClass > >>> String >> #asClassIfAbsent: > >>> String >> #asClassIfPresent: > >> > >> I don't understand why we need this new way. > >> Is it just to avoid calling 'Smalltalk globals at: #MyClass'? > > > > exactly > > > >> Because these names are confusing, and the 'as' prefix suggests a > conversion while it's an access (with indirection but still a mere access). > >> And #asClass has no sender. > >> If you think 'Smalltalk globals at: #MyClass' is really too long to > type, lets just create a new global ThisEnvironment := Smalltalk globals. > > > > this was already discussed. With #asClass and relatives what you have is > a better abstraction jut because you are decoupled of "Smalltalk globals", > it is not a big win now, but it open doors to better designs with > environments, etc. > > At least, that was my understanding when the issue arise at the > beginning. > > It's not a better abstraction, it's a worse one. > Sending #asClass to a symbol will ever execute the same method that anyway > as to rely on a global: Smalltalk. > And this global is solved in only one environment: the one of the class > Symbol where #asClass and co. are implemented. > So if you want separated environments you know what kind of thing you'll > end up writing? > > '#Foo asClassInEnvitonment: self class environment' > > or implementing: > > Symbol>>#asClass > ^ self asClassInEnvironment: thisContext sender receiver class > environment > > However, as soon as the compiler use the environment of the compiled > method's class to solves the globals it contains, Smalltalk can refer to > anything. > So the only problem with: 'Smalltalk globals at:' is that you send a > message #globals to the global Smalltalk to fetch the environment while we > could just have a global ThisEnvironment pointing to itself. > > Writting 'ThisEnvironment at: #Foo' is much more natural. > > If we want separated environments, each environment just have to define a > binding ThisEnvironment pointing to itself and everything works well. > What I don't like with #asClass and co. is the style: you talk to a symbol > instead of an environment. > It's like saying: '#key valueIn: aDict' instead of: 'aDict at: #key', > 'letter beSentBy: postman to: receiver' instead of: 'postman send: letter > to: receiver', etc... > > In Smalltalk we already have self to refer to the current receiver and > thisContext to refer to the current stack frame. If we want different > environments, is it that weird to have a ThisEnvironment to refer to the > current environment? > > > > > Esteban > > > >> > >> > >>> > >>> On 2013-08-24, at 17:55, Fernando Olivero <fernando.olivero(a)usi.ch> > wrote: > >>>> I prefer to evaluate > >>>> > >>>> Smalltalk globals classNamed: #MyClass > >>>> > >>>> Fernando > >>>> > >>>> On Sat, Aug 24, 2013 at 11:57 AM, StÃ©phane Ducasse > >>>> <stephane.ducasse(a)inria.fr> wrote: > >>>>> > >>>>> Is it > >>>>> > >>>>> asClass? > >>>>> > >>>>> Stef > >>>>> > >>>> > >>> > >>> > >> > >> > > > > > > > -- Best regards, Igor Stasenko.

Aug. 26, 2013

Re: [Pharo-dev] what is the new way to do Smalltalk at: #MyClass?

by Camille Teruel

On 26 aoÃ»t 2013, at 10:56, Esteban Lorenzano wrote: > > On Aug 25, 2013, at 9:40 AM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > >> >> On 24 aoÃ»t 2013, at 19:20, Camillo Bruni wrote: >> >>> We have now: >>> >>> String >> #asClass >>> String >> #asClassIfAbsent: >>> String >> #asClassIfPresent: >> >> I don't understand why we need this new way. >> Is it just to avoid calling 'Smalltalk globals at: #MyClass'? > > exactly > >> Because these names are confusing, and the 'as' prefix suggests a conversion while it's an access (with indirection but still a mere access). >> And #asClass has no sender. >> If you think 'Smalltalk globals at: #MyClass' is really too long to type, lets just create a new global ThisEnvironment := Smalltalk globals. > > this was already discussed. With #asClass and relatives what you have is a better abstraction jut because you are decoupled of "Smalltalk globals", it is not a big win now, but it open doors to better designs with environments, etc. > At least, that was my understanding when the issue arise at the beginning. It's not a better abstraction, it's a worse one. Sending #asClass to a symbol will ever execute the same method that anyway as to rely on a global: Smalltalk. And this global is solved in only one environment: the one of the class Symbol where #asClass and co. are implemented. So if you want separated environments you know what kind of thing you'll end up writing? '#Foo asClassInEnvitonment: self class environment' or implementing: Symbol>>#asClass ^ self asClassInEnvironment: thisContext sender receiver class environment However, as soon as the compiler use the environment of the compiled method's class to solves the globals it contains, Smalltalk can refer to anything. So the only problem with: 'Smalltalk globals at:' is that you send a message #globals to the global Smalltalk to fetch the environment while we could just have a global ThisEnvironment pointing to itself. Writting 'ThisEnvironment at: #Foo' is much more natural. If we want separated environments, each environment just have to define a binding ThisEnvironment pointing to itself and everything works well. What I don't like with #asClass and co. is the style: you talk to a symbol instead of an environment. It's like saying: '#key valueIn: aDict' instead of: 'aDict at: #key', 'letter beSentBy: postman to: receiver' instead of: 'postman send: letter to: receiver', etc... In Smalltalk we already have self to refer to the current receiver and thisContext to refer to the current stack frame. If we want different environments, is it that weird to have a ThisEnvironment to refer to the current environment? > > Esteban > >> >> >>> >>> On 2013-08-24, at 17:55, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >>>> I prefer to evaluate >>>> >>>> Smalltalk globals classNamed: #MyClass >>>> >>>> Fernando >>>> >>>> On Sat, Aug 24, 2013 at 11:57 AM, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>> Is it >>>>> >>>>> asClass? >>>>> >>>>> Stef >>>>> >>>> >>> >>> >> >> > >

Aug. 26, 2013

Re: [Pharo-dev] what is the new way to do Smalltalk at: #MyClass?

by StÃ©phane Ducasse

> > > It works the same way as the dictionary protocol with #at: > `#adsfasdf asClass` will signal an error, hence for compatibility you have the *IfAbsent: protocols. Otherwise you simply cannot replace all the users of `Smalltalk at:` and `Smalltalk globals at:` which is the long term goal. Cool mid term goal. I should not start with it but I really would like :)

Aug. 26, 2013

Re: [Pharo-dev] what is the new way to do Smalltalk at: #MyClass?

by Camillo Bruni

On 2013-08-26, at 11:46, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 26.08.2013 um 10:56 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > >> >> On Aug 25, 2013, at 9:40 AM, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> >>> >>> On 24 aoÃ»t 2013, at 19:20, Camillo Bruni wrote: >>> >>>> We have now: >>>> >>>> String >> #asClass >>>> String >> #asClassIfAbsent: >>>> String >> #asClassIfPresent: >>> >>> I don't understand why we need this new way. >>> Is it just to avoid calling 'Smalltalk globals at: #MyClass'? >> >> exactly >> >>> Because these names are confusing, and the 'as' prefix suggests a conversion while it's an access (with indirection but still a mere access). >>> And #asClass has no sender. >>> If you think 'Smalltalk globals at: #MyClass' is really too long to type, lets just create a new global ThisEnvironment := Smalltalk globals. >> >> this was already discussed. With #asClass and relatives what you have is a better abstraction jut because you are decoupled of "Smalltalk globals", it is not a big win now, but it open doors to better designs with environments, etc. >> At least, that was my understanding when the issue arise at the beginning. >> > I just find it strange that an as* selector might _not_ return anything needing a #asClassIfAbsent: selector. While I'm understanding the intention it does not fit in my had. To me it worsens the understanding of as* conversion selectors. It works the same way as the dictionary protocol with #at: `#adsfasdf asClass` will signal an error, hence for compatibility you have the *IfAbsent: protocols. Otherwise you simply cannot replace all the users of `Smalltalk at:` and `Smalltalk globals at:` which is the long term goal.

Aug. 26, 2013