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

[Pharo-project] Problem with window cycling (cmd + narrow)

by Mariano Martinez Peck

I think there is a bug in the windows cycling. Or maybe I don't understand it anymore. I remembered I used to press cmd + narrow and the popup raised and then I could choose slowly which windows I wanted. But now, after pressing cmd + left arrow for example, the popup raise, but very quickly disappear. Giving me now time even to look at the current opened windows. I guess this is a bug. What do you think ? I tested in Pharo1.0 rc3 and Pharo 11309. I think this bug is different but related to issue 2289. Cheers Mariano

April 13, 2010

Re: [Pharo-project] new windows (e.g. workspaces) appear wherever they feel like

by Mariano Martinez Peck

Hi. Yes, this is not a bug but the expected behavior. I am new in Squeak, but since I know it, it is like this, and I guess it is like this since several years. Maybe even from the beginning. However, I think the same as you. At the beginning it was very difficult for me to understand why that happens. I have no idea the impact of this change neither how to do it. But I would REALLY like to experiment with that. But be aware that this is a BIG change in the way Pharo behaves. So...we need to carefully think about it and discuss. For example, with your approach, it is difficult then to open different windows spread in the world. As is it is now, you can always click anywhere in the World and it will open a windows in a place you don't know. But with your case, you need to go with the mouse to where you want to open it. You have to think where you want to open it and go there. Maybe it is better. I don't know. As I say, I would really like to test such possibility. Does anyone know how to change this ? Cheers Mariano On Fri, Apr 9, 2010 at 9:27 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > It seems to flow better if they appeared where the user is already looking > i.e. where the active hand is. > > Issue 2290 : http://code.google.com/p/pharo/issues/detail?id=2290. > > Sean > -- > View this message in context: > http://n4.nabble.com/new-windows-e-g-workspaces-appear-wherever-they-feel-l… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 13, 2010

Re: [Pharo-project] about sorted

by Levente Uzonyi

On Tue, 13 Apr 2010, StÃ©phane Ducasse wrote: >> Hi levente >>> >>> may be I did a mistake when I integrated some of your changes. I did not look at Squeak before posting (because I'm dead). >>> Now in latest 1.1 several tests for sorted failed because nil is valued while it should not. >>> >>> I read the code and I do not really like the aBlockOrNil. >> >> aBlockOrNil is a bit misleading, because it can be anything that understands #value:value: or it can be nil. This means that the following binary selectors can be used (if you integrated my changes) instead of blocks: #<= #>= #< #> (or whatever you define :)). >> Using nil is not my idea, I took it from SortedCollection. > > Ok > >>> I would prefer to have block all the time. >>> I was wondering if your original idea was to use nil and if this is the case why you thought it was >>> better than just passing a block. >> >> nil is only used for better performance. Since most of the time you only want to sort by <=. >> >> Here is a simple benchmark which do the same thing, but uses 3 different "sortBlocks": >> >> | array | >> array := (1 to: 100000) asArray shuffle. >> >> [ array sorted: nil ] bench "===> 4.782781984854524 per second.". >> >> [ array sorted: [ :a :b | a <= b ] ] bench "===> 1.496445940890385 per second.". >> >> [ array sorted: #<= ] bench "===> 2.740262282247015 per second." > The above benchmark is a bit unfair, because the vm has special bytecodes for integer comparisons, so here is the same with strings: | array | array := (1 to: 100000) asArray shuffle replace: #asString [ array sorted: nil ] bench "===> 1.506875117724618 per second.". [ array sorted: [ :a :b | a <= b ] ] bench "===> 0.718261806428443 per second.". [ array sorted: #<= ] bench "===> 1.237842617152962 per second.". > I have to look why because for me this is a sad news. The main cause is that block activation is not cheap. > I hate this nil passing around I prefer cool block. As soon as we have an inlining jit, the above benchmarks should give the same results. Levente > > Thanks for the information. > > Stef >> >> >> Levente >> >>> >>> >>> sorted >>> "Return a new sequenceable collection which contains the same elements as self but its >>> elements are sorted in ascending order using the #'<=' operator." >>> >>> ^self sorted: [:a :b| a <= b ] >>> >>> Stef >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 13, 2010

[Pharo-project] Cologne Smalltalk meetup May/June

by Norbert Hartl

The next smalltalk meetup in cologne will occur end of may / start of june. We are trying to find the best date for it to take place. If you like to join our small happening than please add yourself to the doodle date finding. http://www.doodle.com/6u7msewsgumvkkta This poll will close aprox. in two weeks. thanks, Norbert P.S.: Could someone forward this to squeak-dev as I'm not subscribed there

April 13, 2010

Re: [Pharo-project] about sorted

by StÃ©phane Ducasse

> Hi levente >> >> may be I did a mistake when I integrated some of your changes. I did not look at Squeak before posting (because I'm dead). >> Now in latest 1.1 several tests for sorted failed because nil is valued while it should not. >> >> I read the code and I do not really like the aBlockOrNil. > > aBlockOrNil is a bit misleading, because it can be anything that understands #value:value: or it can be nil. This means that the following binary selectors can be used (if you integrated my changes) instead of blocks: #<= #>= #< #> (or whatever you define :)). > Using nil is not my idea, I took it from SortedCollection. Ok >> I would prefer to have block all the time. >> I was wondering if your original idea was to use nil and if this is the case why you thought it was >> better than just passing a block. > > nil is only used for better performance. Since most of the time you only want to sort by <=. > > Here is a simple benchmark which do the same thing, but uses 3 different "sortBlocks": > > | array | > array := (1 to: 100000) asArray shuffle. > > [ array sorted: nil ] bench "===> 4.782781984854524 per second.". > > [ array sorted: [ :a :b | a <= b ] ] bench "===> 1.496445940890385 per second.". > > [ array sorted: #<= ] bench "===> 2.740262282247015 per second." I have to look why because for me this is a sad news. I hate this nil passing around I prefer cool block. Thanks for the information. Stef > > > Levente > >> >> >> sorted >> "Return a new sequenceable collection which contains the same elements as self but its >> elements are sorted in ascending order using the #'<=' operator." >> >> ^self sorted: [:a :b| a <= b ] >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 13, 2010

[Pharo-project] Fwd: Scamper

by laurent laffont

Thank you John ! Commit what you want :) I forward to pharo mailing list, people may be interested. http://www.squeaksource.com/LaurentLSandbox.html Cheers, Laurent Laffont ---------- Forwarded message ---------- From: John McKeon <p3anoman(a)gmail.com> Date: Tue, Apr 13, 2010 at 4:45 AM Subject: Scamper To: laurent.laffont(a)gmail.com Hello Laurent I hope you won't mind, I made a change to Scamper and posted it to your repository. I set the testWrap: method to return true. Its seems to give a big improvement to the readability of most pages that I have visited with it. Thanks for your work on it, it is working quite well Warm regards John McKeon -- http://jmck.seasidehosting.st

April 13, 2010

Re: [Pharo-project] about sorted

by Levente Uzonyi

On Mon, 12 Apr 2010, StÃ©phane Ducasse wrote: > Hi levente > > may be I did a mistake when I integrated some of your changes. I did not look at Squeak before posting (because I'm dead). > Now in latest 1.1 several tests for sorted failed because nil is valued while it should not. > > I read the code and I do not really like the aBlockOrNil. aBlockOrNil is a bit misleading, because it can be anything that understands #value:value: or it can be nil. This means that the following binary selectors can be used (if you integrated my changes) instead of blocks: #<= #>= #< #> (or whatever you define :)). Using nil is not my idea, I took it from SortedCollection. > I would prefer to have block all the time. > I was wondering if your original idea was to use nil and if this is the case why you thought it was > better than just passing a block. nil is only used for better performance. Since most of the time you only want to sort by <=. Here is a simple benchmark which do the same thing, but uses 3 different "sortBlocks": | array | array := (1 to: 100000) asArray shuffle. [ array sorted: nil ] bench "===> 4.782781984854524 per second.". [ array sorted: [ :a :b | a <= b ] ] bench "===> 1.496445940890385 per second.". [ array sorted: #<= ] bench "===> 2.740262282247015 per second." Levente > > > sorted > "Return a new sequenceable collection which contains the same elements as self but its > elements are sorted in ascending order using the #'<=' operator." > > ^self sorted: [:a :b| a <= b ] > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 12, 2010

Re: [Pharo-project] pharo on sparc solaris

by HernÃ¡n Morales Durand

Hi Tudor, It's been years since I've used them, but you may try a "free" Solaris shell account at http://www.polarhome.com/ or installing your own Solaris Appliance on a VMWare Server : http://wotho.ethz.ch/ESX_solaris/Install_Solaris_on_ESX.html http://blogs.sun.com/exoteric/entry/installing_solaris_10_5_08 Cheers, HernÃ¡n 2010/4/12 Tudor Girba <tudor.girba(a)gmail.com>: > Hi, > > I would need to run a Pharo RC4 image on a Sparc Solaris station. Looking on > the www.squeakvm.org/unix/, I see that there is no VM for such a station, > only for Intel Solaris. > > Unfortunately, I also do not have access to any compiling tools on this > machine (it's a server). Can anyone help me with this issue? > > The machine says it is: > $ uname -a > SunOS ejpdxa9017 5.10 Generic_142900-03 sun4v sparc > SUNW,SPARC-Enterprise-T5220 > > > Cheers, > Doru > > -- > www.tudorgirba.com > > "To lead is not to demand things, it is to make them happen." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 12, 2010

[Pharo-project] about sorted

by StÃ©phane Ducasse

Hi levente may be I did a mistake when I integrated some of your changes. I did not look at Squeak before posting (because I'm dead). Now in latest 1.1 several tests for sorted failed because nil is valued while it should not. I read the code and I do not really like the aBlockOrNil. I would prefer to have block all the time. I was wondering if your original idea was to use nil and if this is the case why you thought it was better than just passing a block. sorted "Return a new sequenceable collection which contains the same elements as self but its elements are sorted in ascending order using the #'<=' operator." ^self sorted: [:a :b| a <= b ] Stef

April 12, 2010

Re: [Pharo-project] Open Pharo debugger from a Seaside wallback

by Mariano Martinez Peck

As Stef said...do you have some anti-virus program like nod-32 or something like that ? in such case you should exclude the directory where you have your Pharo image. On Mon, Apr 12, 2010 at 5:52 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Apr 12, 2010, at 10:46 PM, Facundo Vozzi wrote: > > > It continues taking longer 15 seconds on 1.1 too, there isn't change. I > will try to compare with Squeak looking for the possible problem and its > solution. > > > > nobody has the same problem? > > No and this is strange because 1.1 got a lot of the stream changes that > made squeak faster. > > > > > Thank you, > > Facu > > > > On Mon, Apr 12, 2010 at 5:28 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > > > On Apr 12, 2010, at 10:18 PM, Facundo Vozzi wrote: > > > > > Stef, > > > I'm using Pharo 1.0 RC2 with Seaside 2.8.4 and all is fine but it took > over 15 seconds open a smalltalk debugger from a Seaside wallback. It was > the reason of my first mail. > > > I tried with Squeak 4.1 RC4, to discard a network configuration problem > at operative system level, and i don't have the problem. It takes 1 second > to open the debugger. > > > Then, Marcus ask to me if i had the same problem with > "PharoCore-1.1-11301-UNSTABLE", at that time I download it, installed > Seaside and try again. To Install Seaside took to me over 20 minutes but I > had been instaled it on Pharo 1.0 and was been fine. > > > > ok so with 1.1 this is working? > > There were a **lot** of changes in 1.1. We will release shortly after 1.0 > and much much faster :) > > > > > Is it more clear now ?. Please, sorry for my poor English. > > > > Don;t worry. write simple sentences and we will understand you. > > > > > > Facu > > > > > > > > > On Mon, Apr 12, 2010 at 5:03 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > > This is really strange. Can you describe your setup? Do you have an > antivirus? And with Squeak you do not have that behavior? > > > We are loading larger code than seaside in Pharo and we do not have > this problem. > > > So I would really like to understand. Could you post your image > somewhere? > > > > > > Stef > > > > > > On Apr 12, 2010, at 9:27 PM, Facundo Vozzi wrote: > > > > > > > Stef, > > > > It took to me over 20 minutes to complete the Seaside 2.8 > installation and when I interrupted it the debugger opened when the system > was writting the pharoXXX.changes always but I couldn't check what is > happening. > > > > > > > > I will check it again. > > > > > > > > Facu > > > > > > > > ps: I refered to pharoXXX.changes as "log" because of Visual > Smalltalk where the "changes" are called changes.log, excuse me. > > > > > > > > On Mon, Apr 12, 2010 at 3:05 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > > > > > > > On Apr 12, 2010, at 7:45 PM, Facundo Vozzi wrote: > > > > > > > > > Marcus, > > > > > I can't install Seaside on Pharo 1.1(*) but then i'll try again at > home. > > > > > > > > > > It isn't my point to compare Pharo to Squeak performance but I used > Squeak to test this particular situation. > > > > > > > > > > Thank you, > > > > > > > > > > Facu > > > > > > > > > > (*) it's very slow to write the log taking minutes to complete the > instalation > > > > > > > > which log? > > > > > > > > Stef > > > > > > > > > > > > > > On Mon, Apr 12, 2010 at 12:54 PM, Marcus Denker < > marcus.denker(a)inria.fr> wrote: > > > > > > > > > > On Apr 12, 2010, at 5:41 PM, Marcus Denker wrote: > > > > > > > > > > > > > > > > > On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: > > > > > > > > > > > >> Lukas, > > > > > >> It happens on my machine with Windows/(Firefox-Chrome-IE 8) and > Pharo. > > > > > >> > > > > > >> But I test it on the same machine with Squeak 4.1 RC4 and it go > very very fast > > > > > >> to open de smalltalk debugger. > > > > > >> Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did > you note that too or it's only my sensations? > > > > > >> > > > > > > > > > > > > Did you check with Pharo 1.1? > > > > > > > > > > > > > https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE… > > > > > > > > > > > > In general, Squeak 4.1 should not be compared to Pharo 1.0 > speed-wise, but Pharo 1.1 > > > > > > > > > > > > > > > > My theory for your bug is that it's this: > > > > > > > > > > http://code.google.com/p/pharo/issues/detail?id=860 > > > > > > > > > > We added it to 1.1 on Nov. 01, 2009. Not to 1.0, because 1.0 was > supposed to be released > > > > > "very soon". > > > > > > > > > > Marcus > > > > > > > > > > > > > > > > > > > > -- > > > > > Marcus Denker -- http://www.marcusdenker.de > > > > > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pharo-project mailing list > > > > > Pharo-project(a)lists.gforge.inria.fr > > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > > > > > > > > > > > > -- > > > > > Facundo Vozzi > > > > > InfOil S.A. > > > > > Project Leader > > > > > (+54-11) 4542-9999 x108 > > > > > fvozzi(a)infoil.com.ar > > > > > _______________________________________________ > > > > > Pharo-project mailing list > > > > > Pharo-project(a)lists.gforge.inria.fr > > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > Pharo-project(a)lists.gforge.inria.fr > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > > > > > > > > -- > > > > Facundo Vozzi > > > > InfOil S.A. > > > > Project Leader > > > > (+54-11) 4542-9999 x108 > > > > fvozzi(a)infoil.com.ar > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > Pharo-project(a)lists.gforge.inria.fr > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > > > > -- > > > Facundo Vozzi > > > InfOil S.A. > > > Project Leader > > > (+54-11) 4542-9999 x108 > > > fvozzi(a)infoil.com.ar > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > -- > > Facundo Vozzi > > InfOil S.A. > > Project Leader > > (+54-11) 4542-9999 x108 > > fvozzi(a)infoil.com.ar > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 12, 2010