February 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] Window resize

by Mariano Martinez Peck

I think I asked the same some time ago. I tried what Adrian said but without success :( http://n4.nabble.com/How-can-I-change-the-size-of-the-World-td1310740.html#… Do we have a solution now? Cheers Mariano On Thu, Feb 18, 2010 at 12:39 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Is there an event when the Squeak window is resized, > so one can react and resize morphs accordingly? > > Thx > T. > -- > NEU: Mit GMX DSL Ã¼ber 1000,- Â¿ sparen! > http://portal.gmx.net/de/go/dsl02 > >

Feb. 19, 2010

Re: [Pharo-project] cull: protocol

by Levente Uzonyi

On Fri, 19 Feb 2010, Henrik Johansen wrote: > Den 18.02.2010 21:55, skrev StÃ©phane Ducasse: >> henrik >> >> I'm trying to get the pros and cons of cull: >> So am'I correct that this is useful only for situation where we have a block and we do not know >> upfront its number of argument: = places where valueWithPossibleArgs: >> Now what cull: offers is that the client does not have to create the array. >> >> I did not check your implementation. >> >> Stef >> > It's useful where you may or may not be interested in all the arguments > passed to a block. > Announcement and Exception handling are good examples. It covers the > same bases as valueWithPossibleArgs:, with the exception it does not > expand with nil args if block has more args than the corresponding > message sent. > > Pros: > - Maps well with to the value:, value:value, etc. protocol > - Your code looks cleaner (imo), since you don't have to put the args in > an array, and it's clear in a heart beat how many args you can choose to > use in your block. > - It's faster than valueWithPossibleArgs, since you don't have to put > your args in an array (Also you avoid a max of 2 extra array creations > as part of the method) > > Cons: > - Functionality is already provided by valueWithPossibleArgs: (That's a > superset though, if you need the exact functionality of cull, your code > will end up even hairier since you need an arg size check before calling > valueWithPossibleArgs:) > - Portability. VW and GNU ST has them, Squeak does not, not sure about > other implementations. Even though I'm just a lurker here, I think you should add this feature to Pharo. Of course I'd add the "uglier" implementation (as we discussed it with Henry in January), since I think it's not "uglier" and gives better performance (~1.3x faster for #cull:cull: if the block has less than 2 arguments while same performance if the block has 2 arguments). Levente > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 19, 2010

Re: [Pharo-project] Object >> toFinalizeSend:to:with:

by StÃ©phane Ducasse

On Feb 19, 2010, at 10:33 AM, Henrik Johansen wrote: > The two uses I've seen of this method > (RequiredSelectors>>registerLifelongInterestOf:inAll: in Core, and > AXWeakSubscription in AXAnnouncements on SqueakSource) have used this as > a poor mans replacement for ephemerons. > The problem is it does not work the way these senders expect (ie: > registering an action for each resource to be taken when the receiver is > finalized), but only executes the last action registered for an object. > > Would it be an idea to change the implementation to conform to the > expectations of the senders, rather than considering the uses as bugs, > seeing as how that seems to be the common usage? (And a quite more > useful one in the absence of real ephemerons, if you ask me) Changing for better :) BTW we should remove the old and not used algorithm left from the browser supporting traits required methods. I hope that when adrian is settle down he will give that code a kick. :) Stef

Feb. 19, 2010

Re: [Pharo-project] cull: protocol

by StÃ©phane Ducasse

Your arguments are convincing to me ;) Stef On Feb 19, 2010, at 10:22 AM, Henrik Johansen wrote: > Den 18.02.2010 21:55, skrev StÃ©phane Ducasse: >> henrik >> >> I'm trying to get the pros and cons of cull: >> So am'I correct that this is useful only for situation where we have a block and we do not know >> upfront its number of argument: = places where valueWithPossibleArgs: >> Now what cull: offers is that the client does not have to create the array. >> >> I did not check your implementation. >> >> Stef >> > It's useful where you may or may not be interested in all the arguments > passed to a block. > Announcement and Exception handling are good examples. It covers the > same bases as valueWithPossibleArgs:, with the exception it does not > expand with nil args if block has more args than the corresponding > message sent. > > Pros: > - Maps well with to the value:, value:value, etc. protocol > - Your code looks cleaner (imo), since you don't have to put the args in > an array, and it's clear in a heart beat how many args you can choose to > use in your block. > - It's faster than valueWithPossibleArgs, since you don't have to put > your args in an array (Also you avoid a max of 2 extra array creations > as part of the method) > > Cons: > - Functionality is already provided by valueWithPossibleArgs: (That's a > superset though, if you need the exact functionality of cull, your code > will end up even hairier since you need an arg size check before calling > valueWithPossibleArgs:) > - Portability. VW and GNU ST has them, Squeak does not, not sure about > other implementations. > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 19, 2010

Re: [Pharo-project] Class Browser

by Mariano Martinez Peck

It would be cool to put this information somewhere and accessible from the OB. On Fri, Feb 19, 2010 at 9:03 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > > Where is there documentation to be found describing the meaning of > > list entry icons (on left side of lists) in the Class Browser? > > Classes have icons depending on their type. The exception are tests > which have a bullet with the SUnit result color of the last run, or > gray if there is no data is available. > > Methods have a green arrow pointing upwards if there is a super > implementation, and a green arrow pointing downwards if there are sub > implementations. You can click on these icons to see the hierarchy and > navigate to the actual implementations of these methods. If the method > is flagged a blue flag is displayed instead. If there is a breakpoint > a red flag is displayed instead. Finally, if this is a test method, > then a bullet with the SUnit result color is displayed. > > Depending on what you have loaded in your image you might see > different icons. Packages can override #browserIcon and > #browserIcon:selector: to add custom icons for classes and methods. > Seaside for example does that. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 19, 2010

[Pharo-project] Object >> toFinalizeSend:to:with:

by Henrik Johansen

The two uses I've seen of this method (RequiredSelectors>>registerLifelongInterestOf:inAll: in Core, and AXWeakSubscription in AXAnnouncements on SqueakSource) have used this as a poor mans replacement for ephemerons. The problem is it does not work the way these senders expect (ie: registering an action for each resource to be taken when the receiver is finalized), but only executes the last action registered for an object. Would it be an idea to change the implementation to conform to the expectations of the senders, rather than considering the uses as bugs, seeing as how that seems to be the common usage? (And a quite more useful one in the absence of real ephemerons, if you ask me) Cheers, Henry

Feb. 19, 2010

Re: [Pharo-project] cull: protocol

by Henrik Johansen

Den 18.02.2010 21:55, skrev StÃ©phane Ducasse: > henrik > > I'm trying to get the pros and cons of cull: > So am'I correct that this is useful only for situation where we have a block and we do not know > upfront its number of argument: = places where valueWithPossibleArgs: > Now what cull: offers is that the client does not have to create the array. > > I did not check your implementation. > > Stef > It's useful where you may or may not be interested in all the arguments passed to a block. Announcement and Exception handling are good examples. It covers the same bases as valueWithPossibleArgs:, with the exception it does not expand with nil args if block has more args than the corresponding message sent. Pros: - Maps well with to the value:, value:value, etc. protocol - Your code looks cleaner (imo), since you don't have to put the args in an array, and it's clear in a heart beat how many args you can choose to use in your block. - It's faster than valueWithPossibleArgs, since you don't have to put your args in an array (Also you avoid a max of 2 extra array creations as part of the method) Cons: - Functionality is already provided by valueWithPossibleArgs: (That's a superset though, if you need the exact functionality of cull, your code will end up even hairier since you need an arg size check before calling valueWithPossibleArgs:) - Portability. VW and GNU ST has them, Squeak does not, not sure about other implementations. Cheers, Henry

Feb. 19, 2010

Re: [Pharo-project] {Spam?} Re: "Real" packages.

by Geert Claes

Dale Henrichs wrote: > > Gemstone uses an order list of dictionaries for global lookup. Each user > can change the order of the list or insert their own dictionaries into the > list ... makes for quite a bit of flexibility.... you can load code into a > particular dictionary...and the global resolution is at compile time (you > can do lookup at runtime if you wish). > The order list of dictionaries reminds me a bit of PowerBuilder's list of "pbl" libraries. Is that GemStone Programming Guide pdf you linked to still the latest, it says April 2007? -- View this message in context: http://n4.nabble.com/Re-Spam-Re-Real-packages-tp1310658p1561328.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 19, 2010

Re: [Pharo-project] self halt :)

by StÃ©phane Ducasse

I see now it would be good to go over the 49 that are in the image and categorize them - self error: -> broken code - can be removed Stef On Feb 19, 2010, at 2:11 AM, John M McIntosh wrote: > Hah, this reminds me of a time where I put like 58 halts in some group shared code I was auditing. > The next day the manager had a fit, because I screwed up coding that night. > > Well I repled each halt was there because the code was broken and if the programmers were > thinking they were making progress, I assure you they weren't... because when the code was fixed > then all the callers would be broken. > > Beside why did you load the developer code out of Envy anyway? Oh because it's broken and you > were hoping to get the latest fixes? > > On 2010-02-18, at 12:46 PM, StÃ©phane Ducasse wrote: > >> Hi guys >> >> I do not know anything about BalloonBezierSimulation but it contains too many self halt. >> >> Do you have an idea if this is something that can be fixed? >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 19, 2010

Re: [Pharo-project] Namespaces

by Marcus Denker

On Feb 18, 2010, at 11:02 PM, James Foster wrote: >> Why not, if it has been proved for a long time in Gemstone, shouldn't be >> sensible to create something similar for Pharo? Or it uses some kind of >> proprietary technology from Gemstone? > > You've heard the phrase, "Imitation is the sincerest form of flattery"? It's true! We would be delighted to see Pharo use a similar scheme for namespaces. Not only is it is an elegant approach, but its adoption by Pharo would ease the upgrade path to GemStone should the opportunity arise. > > For an overview of GemStone namespaces, see http://www.youtube.com/watch?v=z84n3O8YUsI. For more information see the Chapter 3 of the Programming Guide (http://seaside.gemstone.com/docs/GS64-ProgGuide-2.2.pdf) > thanks! We will definitly have a look. (We want to have a *real* good abstractions for structuring large projects better...) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 19, 2010