- Pharo-dev - lists.pharo.org

Re: [Pharo-project] databases

by Stephan Eggermont

Levente wrote in response to my: >> 3. You have a legacy (relational) database, with extensive reporting >> written for it. Use an ORM. >Relational databases are not legacy, they have features >which "modern" key-value stores don't (and won't). >ORMs may ease the programmer's work, but they >tend to have bad runtime performance >and can't use (all) the features of todays RDBMSs. In creating the list of different scenarios, I tried to explain in a short text that different needs lead to different solution strategies. Legacy in this context refers to having an existing database you want to continue using. That is a situation where I would recommend starting with ORM unless it is shown that the run-time performance is going to be prohibitive. Please keep in mind that it is a text written for people new to Seaside (and possibly Smalltalk). If you have a suggestion for a better text, please mail me. Stephan Eggermont

Feb. 19, 2010

Re: [Pharo-project] So your working on a cool project and Pharo crashes

by Mariano Martinez Peck

We should document somewhere all the techniques and tricks to recover lost data. It would be cool if someone can write that. I don't have the knowledge :( Cheers Mariano On Fri, Feb 19, 2010 at 5:47 AM, Ramon Leon <ramon.leon(a)allresnet.com>wrote: > On 2/17/2010 11:25 PM, Alexandre Bergel wrote: > > The change file needs to have the same name than the image to have it > > listed when you do a recover lost changes. > > Not really, you can drag and drop any changes file onto any image and > it'll popup the same changes editor that recover lost changes does. If > you're after the latest changes just remove older versions, then remove > up to date versions, then remove any unnecessary do it's and what's left > will be the diffs, review and file them in. > > > Else, you can simply edit the .changes using any (robust) text editor. > > Cut and paste what you feel relevant into a new file that you name > > yourchanges.cs > > Unnecessary because of the above. > > -- > Ramon Leon > http://onsmalltalk.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] [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