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

[Pharo-project] [update 1.1] #11217

by StÃ©phane Ducasse

[update 1.1] #11217 11217 ----- - Issue 1990: Improving Tools (browser sender,implementor) - Issue 2000: remove #at:ifPresentAndInMemory: - Issue 1999: small cleanup related to Object>>#isWebBrowser - Issue 1997: clean up doit special casing - Issue 1998: small dead code cleanup floatarray - Issue 1983: ANSI Integer>>bitAt:put: is missing

Feb. 19, 2010

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

by Mariano Martinez Peck

On Fri, Feb 19, 2010 at 1:40 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Mariano, > > >I think I asked the same some time ago. > > No, you asked on how to manipulate the size of the > surrounding native window directly from your code. > > Thats easy on Windows using SetWindowPos() API [1] with FFI, > but there is no generalized platform independent solution > in all VM's yet. Maybe you should suggest it on vm-dev or > do it with FFI by calling OS API's for resizing. > > > I asked how one can REACT when the user changes the size of the > surrounding native window. (React within morphic when user resizes, > so hook into an external resize event) > Ok....now I understand the difference. Thanks Torsten. I will then ask in VM list. Cheers Mariano > > For instance on Win32 you get a WM_SIZE notification [2] and > there are similar notifications on other UI frameworks, so > it could be dispatched from an (event driven) VM into a morphic > event. > > However this is also not there as of today. > > >Do we have a solution now? > > As Bert suggested for my question in [3] - one can hook into the > Morphic mainloop. > > Bye > T. > > [1] http://msdn.microsoft.com/en-us/library/ms633545(VS.85).aspx<http://msdn.microsoft.com/en-us/library/ms633545%28VS.85%29.aspx> > [2] http://msdn.microsoft.com/en-us/library/ms632646(VS.85).aspx<http://msdn.microsoft.com/en-us/library/ms632646%28VS.85%29.aspx> > [3] > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-February/144668… > > > > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > 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] cull: protocol

by Levente Uzonyi

On Fri, 19 Feb 2010, Henrik Johansen wrote: > > > Den 19.02.2010 14:03, skrev Levente Uzonyi: >> On Fri, 19 Feb 2010, Henrik Johansen wrote: >> >> >>> Well, ugly was a strong word. >>> Reusing less, aka. shorter is a better choice, I guess. >>> >> I think the difference is 3 lines for the 4 methods. >> >> >>> Cheers, >>> Henry >>> >>> PS. In VisualWorks, the two perform equally. *Wishing for a Cog VM to >>> test on* :) >>> >> There's no inlining VM available ATM (besides SqueakJ, but that can't >> run current images) and noone knows when one will be. And even though I >> didn't try it, I expect that "inlining by hand" saves time and memory. >> > No objections here, it's definately faster. >>> PPS. For those interested, the alternative, faster version Levente made >>> can be found at http://paste.lisp.org/display/93130 >>> >> Here is a working example (the linked version has a bug): >> BlockClosure >> cull: argument1 cull: argument2 >> >> numArgs = 2 ifTrue: [ ^self value: argument1 value: argument2 ]. >> numArgs = 1 ifTrue: [ ^self value: argument1 ]. >> ^self value >> > Ah yes, had forgotten about that. > How about: > > numArgs > 1 ifTrue: [ ^self value: argument1 value: argument2 ]. > numArgs = 1 ifTrue: [ ^self value: argument1 ]. > ^self value > > That way, you get "This block accepts 3 arguments, but was called with 2 arguments" instead of "... was called with 0 arguments" error messages if the block has too many args. Nice. > >> (For #cull:cull:cull: the difference is ~1.7x if the block has 0 or 1 >> argument, and ~1.3x if it has 2 arguments) >> > Then also consider the scale > "overhead of 120 ms rather than 320ms for 1 million cull:cull:cull: > sends where the block has one arg, compared to a raw value: send > (130ms)". ;) > Now imagine that you have a lot slower machine. ;) 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] cull: protocol

by Henrik Johansen

Den 19.02.2010 14:03, skrev Levente Uzonyi: > On Fri, 19 Feb 2010, Henrik Johansen wrote: > > >> Well, ugly was a strong word. >> Reusing less, aka. shorter is a better choice, I guess. >> > I think the difference is 3 lines for the 4 methods. > > >> Cheers, >> Henry >> >> PS. In VisualWorks, the two perform equally. *Wishing for a Cog VM to >> test on* :) >> > There's no inlining VM available ATM (besides SqueakJ, but that can't > run current images) and noone knows when one will be. And even though I > didn't try it, I expect that "inlining by hand" saves time and memory. > No objections here, it's definately faster. >> PPS. For those interested, the alternative, faster version Levente made >> can be found at http://paste.lisp.org/display/93130 >> > Here is a working example (the linked version has a bug): > BlockClosure >> cull: argument1 cull: argument2 > > numArgs = 2 ifTrue: [ ^self value: argument1 value: argument2 ]. > numArgs = 1 ifTrue: [ ^self value: argument1 ]. > ^self value > Ah yes, had forgotten about that. How about: numArgs > 1 ifTrue: [ ^self value: argument1 value: argument2 ]. numArgs = 1 ifTrue: [ ^self value: argument1 ]. ^self value That way, you get "This block accepts 3 arguments, but was called with 2 arguments" instead of "... was called with 0 arguments" error messages if the block has too many args. > (For #cull:cull:cull: the difference is ~1.7x if the block has 0 or 1 > argument, and ~1.3x if it has 2 arguments) > Then also consider the scale "overhead of 120 ms rather than 320ms for 1 million cull:cull:cull: sends where the block has one arg, compared to a raw value: send (130ms)". ;) Cheers, Henry

Feb. 19, 2010

Re: [Pharo-project] cull: protocol

by merlyn＠stonehenge.com

>>>>> "Levente" == Levente Uzonyi <leves(a)elte.hu> writes: Levente> Here is a working example (the linked version has a bug): Levente> BlockClosure >> cull: argument1 cull: argument2 Levente> numArgs = 2 ifTrue: [ ^self value: argument1 value: argument2 ]. Levente> numArgs = 1 ifTrue: [ ^self value: argument1 ]. Levente> ^self value The error message here will be misleading if it's a 3 arg block, saying that it wants 3 args, but was given 0, when in fact you *offered* two args. Perhaps the tests could be done in the reverse order: numargs = 0 ifTrue: [^self value]. numargs = 1 ifTrue: [^self value: argument1]. ^self value: argument1 value: argument2. Then, you'll get a sensible message... "offered 2, wanted 3" -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Feb. 19, 2010

Re: [Pharo-project] cull: protocol

by Levente Uzonyi

On Fri, 19 Feb 2010, Henrik Johansen wrote: > Well, ugly was a strong word. > Reusing less, aka. shorter is a better choice, I guess. I think the difference is 3 lines for the 4 methods. > > Cheers, > Henry > > PS. In VisualWorks, the two perform equally. *Wishing for a Cog VM to > test on* :) There's no inlining VM available ATM (besides SqueakJ, but that can't run current images) and noone knows when one will be. And even though I didn't try it, I expect that "inlining by hand" saves time and memory. > PPS. For those interested, the alternative, faster version Levente made > can be found at http://paste.lisp.org/display/93130 Here is a working example (the linked version has a bug): BlockClosure >> cull: argument1 cull: argument2 numArgs = 2 ifTrue: [ ^self value: argument1 value: argument2 ]. numArgs = 1 ifTrue: [ ^self value: argument1 ]. ^self value (For #cull:cull:cull: the difference is ~1.7x if the block has 0 or 1 argument, and ~1.3x if it has 2 arguments) Levente > > _______________________________________________ > 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] [squeak-dev] Window resize

by Torsten Bergmann

Hi Mariano, >I think I asked the same some time ago. No, you asked on how to manipulate the size of the surrounding native window directly from your code. Thats easy on Windows using SetWindowPos() API [1] with FFI, but there is no generalized platform independent solution in all VM's yet. Maybe you should suggest it on vm-dev or do it with FFI by calling OS API's for resizing. I asked how one can REACT when the user changes the size of the surrounding native window. (React within morphic when user resizes, so hook into an external resize event) For instance on Win32 you get a WM_SIZE notification [2] and there are similar notifications on other UI frameworks, so it could be dispatched from an (event driven) VM into a morphic event. However this is also not there as of today. >Do we have a solution now? As Bert suggested for my question in [3] - one can hook into the Morphic mainloop. Bye T. [1] http://msdn.microsoft.com/en-us/library/ms633545(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/ms632646(VS.85).aspx [3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-February/144668… -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Feb. 19, 2010

Re: [Pharo-project] cull: protocol

by Henrik Johansen

Den 19.02.2010 12:40, skrev 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 Well, ugly was a strong word. Reusing less, aka. shorter is a better choice, I guess. Cheers, Henry PS. In VisualWorks, the two perform equally. *Wishing for a Cog VM to test on* :) PPS. For those interested, the alternative, faster version Levente made can be found at http://paste.lisp.org/display/93130

Feb. 19, 2010

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