[Pharo-project] About long tests.
Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] change of + the DateAndTime breaks the tests
Hi simonwhen I read testDateTimeDenotation1 it seems correct to me.Now do you remember why you changedDateAndTime+ operand "operand conforms to protocol Duration" | ticks | ticks := self ticks + (operand asDuration ticks) . ^ self class basicNew ticks: ticks offset: self offset; yourselfto beDateAndTime+ operand "operand conforms to protocol Duration" | ticks | ticks := OrderedCollection new. self ticks with: (operand asDuration ticks) do: [:ticks1 :dticks | ticks addLast: (ticks1 + dticks) ]. ^ self class basicNew ticks: ticks asArray offset: self offset; yourself. ThanksStef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] A challenge for us
Hi I would like to initiative a task (monthly) for us. I would like to get really good tests coverage for some of the core classes. For example Date, Time, Duration, DateAndTime. This is really important in the long term to get sure that we identify bugs as soon as they appear. It would be really good if we could get team up and fix that together. Does anybody want to help? I started to fix some bugs there and write more tests in the process of fixing tests. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Virtual Desktops in Polymorph
Hi, one thing I really miss in the Pharo UI comparing to Squeak is an equivalent to Projects. Hey - not that I want the Projects and related code back but I would like to see something along the lines of virtual desktops allowing you to switch between different desktops/Worlds in Polymorph using a simple keystroke. Dont know if others miss that too or hard that would be. Any comments? Thx Torsten -- GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.! http://portal.gmx.net/de/go/dsl02 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
Btw, I am running the Pharo tests in my builds now too: http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ Click on duration twice to see the tests sorted by run-time. I feel a bit bad that the slowest test case is one that I wrote. I'll see if I can speed that up some more. Lukas On 15 March 2010 20:56, stephane ducasse stephane.duca...@free.fr wrote: Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Virtual Desktops in Polymorph
On 16 March 2010 10:01, Torsten Bergmann asta...@gmx.de wrote: Hi, one thing I really miss in the Pharo UI comparing to Squeak is an equivalent to Projects. Hey - not that I want the Projects and related code back but I would like to see something along the lines of virtual desktops allowing you to switch between different desktops/Worlds in Polymorph using a simple keystroke. Dont know if others miss that too or hard that would be. Any comments? Run second image? (joking) :) Thx Torsten -- GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.! http://portal.gmx.net/de/go/dsl02 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
Yes, it would be very good to have faster tests. In my experience, if tests take too long to run, you don't use them. During the sprint in Lille, Jorge started to sort out long running tests from the rest and make them subclass from SlowTestCase (or something similar). Cheers, Adrian On Mar 16, 2010, at 09:13 , Lukas Renggli wrote: Btw, I am running the Pharo tests in my builds now too: http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ Click on duration twice to see the tests sorted by run-time. I feel a bit bad that the slowest test case is one that I wrote. I'll see if I can speed that up some more. Lukas On 15 March 2010 20:56, stephane ducasse stephane.duca...@free.fr wrote: Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
Hi, No, I have to finish that. Is still in my todo list. I'll try to make some time today to look into that. Cheers, Jorge On Tue, Mar 16, 2010 at 9:32 AM, Adrian Lienhard a...@netstyle.ch wrote: Yes, it would be very good to have faster tests. In my experience, if tests take too long to run, you don't use them. During the sprint in Lille, Jorge started to sort out long running tests from the rest and make them subclass from SlowTestCase (or something similar). Cheers, Adrian On Mar 16, 2010, at 09:13 , Lukas Renggli wrote: Btw, I am running the Pharo tests in my builds now too: http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ Click on duration twice to see the tests sorted by run-time. I feel a bit bad that the slowest test case is one that I wrote. I'll see if I can speed that up some more. Lukas On 15 March 2010 20:56, stephane ducasse stephane.duca...@free.fr wrote: Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Virtual Desktops in Polymorph
Run RFBServer on a shared image and everybody connects with a VNC client ?? On Tue, Mar 16, 2010 at 9:31 AM, Igor Stasenko siguc...@gmail.com wrote: On 16 March 2010 10:01, Torsten Bergmann asta...@gmx.de wrote: Hi, one thing I really miss in the Pharo UI comparing to Squeak is an equivalent to Projects. Hey - not that I want the Projects and related code back but I would like to see something along the lines of virtual desktops allowing you to switch between different desktops/Worlds in Polymorph using a simple keystroke. Dont know if others miss that too or hard that would be. Any comments? Run second image? (joking) :) Thx Torsten -- GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.! http://portal.gmx.net/de/go/dsl02 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
Name: Gofer-Tests-lr.117 Author: lr Time: 16 March 2010, 10:12:10 am UUID: 884f7d2b-6035-4f66-9ec3-28371a77beac Ancestors: Gofer-Tests-lr.116 - made tests run faster in the Pharo inbox is about 30% faster. Lukas On 16 March 2010 09:13, Lukas Renggli reng...@gmail.com wrote: Btw, I am running the Pharo tests in my builds now too: http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ Click on duration twice to see the tests sorted by run-time. I feel a bit bad that the slowest test case is one that I wrote. I'll see if I can speed that up some more. Lukas On 15 March 2010 20:56, stephane ducasse stephane.duca...@free.fr wrote: Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Code Freeze 1.1?
Hi, Now with 1.0 done, I think we should think about freezing 1.1. The main reason of course is that 1.1 is *far more pleasent* to use than 1.0. The other thing is that 1.1 did change quite some things that have impact on external code (Preferences, as an example). So I think we should - start slowing down on 1.1 (Stef suggested that already) - start polishing (tests...) - start to look at the Dev image. - Official code freeze end of March. - Release if possible end of April (this of course depends on the state of things). Any reasons against? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Code Freeze 1.1?
Hi, Is 1.0 already released? Cheers, Doru On 16 Mar 2010, at 10:19, Marcus Denker wrote: Hi, Now with 1.0 done, I think we should think about freezing 1.1. The main reason of course is that 1.1 is *far more pleasent* to use than 1.0. The other thing is that 1.1 did change quite some things that have impact on external code (Preferences, as an example). So I think we should - start slowing down on 1.1 (Stef suggested that already) - start polishing (tests...) - start to look at the Dev image. - Official code freeze end of March. - Release if possible end of April (this of course depends on the state of things). Any reasons against? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Some battles are better lost than fought. -- www.tudorgirba.com From an abstract enough point of view, any two things are similar. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Code Freeze 1.1?
On Mar 16, 2010, at 10:40 AM, Tudor Girba wrote: Hi, Is 1.0 already released? Not yet, but we hope that RC3 is the last... Marcus Cheers, Doru On 16 Mar 2010, at 10:19, Marcus Denker wrote: Hi, Now with 1.0 done, I think we should think about freezing 1.1. The main reason of course is that 1.1 is *far more pleasent* to use than 1.0. The other thing is that 1.1 did change quite some things that have impact on external code (Preferences, as an example). So I think we should - start slowing down on 1.1 (Stef suggested that already) - start polishing (tests...) - start to look at the Dev image. - Official code freeze end of March. - Release if possible end of April (this of course depends on the state of things). Any reasons against? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Some battles are better lost than fought. -- www.tudorgirba.com From an abstract enough point of view, any two things are similar. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Virtual Desktops in Polymorph
Hi Torsten, as part of my phd i'm building a new IDE for Pharo, somehow related to CodeBubbles and SELF. It is still in development, but i included the idea of workspaces, which you called desktops, and in this initial experience, they are useful for organizing and persisting developers tasks. As soon as i have results and a working prototype i'll release it for the community, and hope to get feedback! Fernando. On Mar 16, 2010, at 9:01 AM, Torsten Bergmann wrote: Hi, one thing I really miss in the Pharo UI comparing to Squeak is an equivalent to Projects. Hey - not that I want the Projects and related code back but I would like to see something along the lines of virtual desktops allowing you to switch between different desktops/Worlds in Polymorph using a simple keystroke. Dont know if others miss that too or hard that would be. Any comments? Thx Torsten -- GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.! http://portal.gmx.net/de/go/dsl02 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Code Freeze 1.1?
I do not see it from the website. Where can I get it from? Cheers, Doru On 16 Mar 2010, at 10:42, Marcus Denker wrote: On Mar 16, 2010, at 10:40 AM, Tudor Girba wrote: Hi, Is 1.0 already released? Not yet, but we hope that RC3 is the last... Marcus Cheers, Doru On 16 Mar 2010, at 10:19, Marcus Denker wrote: Hi, Now with 1.0 done, I think we should think about freezing 1.1. The main reason of course is that 1.1 is *far more pleasent* to use than 1.0. The other thing is that 1.1 did change quite some things that have impact on external code (Preferences, as an example). So I think we should - start slowing down on 1.1 (Stef suggested that already) - start polishing (tests...) - start to look at the Dev image. - Official code freeze end of March. - Release if possible end of April (this of course depends on the state of things). Any reasons against? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Some battles are better lost than fought. -- www.tudorgirba.com From an abstract enough point of view, any two things are similar. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com The coherence of a trip is given by the clearness of the goal. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Code Freeze 1.1?
https://gforge.inria.fr/frs/download.php/26668/PharoCore-1.0-10515rc3.zip On 16 March 2010 11:53, Tudor Girba tudor.gi...@gmail.com wrote: I do not see it from the website. Where can I get it from? Cheers, Doru On 16 Mar 2010, at 10:42, Marcus Denker wrote: On Mar 16, 2010, at 10:40 AM, Tudor Girba wrote: Hi, Is 1.0 already released? Not yet, but we hope that RC3 is the last... Marcus Cheers, Doru On 16 Mar 2010, at 10:19, Marcus Denker wrote: Hi, Now with 1.0 done, I think we should think about freezing 1.1. The main reason of course is that 1.1 is *far more pleasent* to use than 1.0. The other thing is that 1.1 did change quite some things that have impact on external code (Preferences, as an example). So I think we should - start slowing down on 1.1 (Stef suggested that already) - start polishing (tests...) - start to look at the Dev image. - Official code freeze end of March. - Release if possible end of April (this of course depends on the state of things). Any reasons against? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Some battles are better lost than fought. -- www.tudorgirba.com From an abstract enough point of view, any two things are similar. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com The coherence of a trip is given by the clearness of the goal. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Code Freeze 1.1?
https://gforge.inria.fr/frs/download.php/26668/PharoCore-1.0-10515rc3.zip Alexandre On 16 Mar 2010, at 06:53, Tudor Girba wrote: I do not see it from the website. Where can I get it from? Cheers, Doru On 16 Mar 2010, at 10:42, Marcus Denker wrote: On Mar 16, 2010, at 10:40 AM, Tudor Girba wrote: Hi, Is 1.0 already released? Not yet, but we hope that RC3 is the last... Marcus Cheers, Doru On 16 Mar 2010, at 10:19, Marcus Denker wrote: Hi, Now with 1.0 done, I think we should think about freezing 1.1. The main reason of course is that 1.1 is *far more pleasent* to use than 1.0. The other thing is that 1.1 did change quite some things that have impact on external code (Preferences, as an example). So I think we should - start slowing down on 1.1 (Stef suggested that already) - start polishing (tests...) - start to look at the Dev image. - Official code freeze end of March. - Release if possible end of April (this of course depends on the state of things). Any reasons against? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Some battles are better lost than fought. -- www.tudorgirba.com From an abstract enough point of view, any two things are similar. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com The coherence of a trip is given by the clearness of the goal. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Virtual Desktops in Polymorph
Run second image? (joking) :) Run RFBServer on a shared image and everybody connects with a VNC client ?? That's like: You can print out a copy of you screen and have the printed paper beside your laptop ;) Hey - maybe I was not clear enough: When I currently work with Pharo I switch to full screen it is like an OS to me with it's own window manager (here Morphic/Polymorph). Unfortunately there is only one World/Desktop/Screen with windows - but I want more than one and an easy way to switch between them. So instead of Pharo image - World with many windows Pharo image - #(World with many windows, World with many windows, ...) i'm building a new IDE for Pharo It is still in development, but i included the idea of workspaces The idea is not new - Eclipse has a workspace concept - but this is running within one window (which is clonable in Eclipse by the way). VisualWorks Refactoring Browser has something similar - with switchable views within one browser. And yes, Bubbles is not bound to a single window. But I'm talking about switchable screens (switchable arrangements of windows and morphs) and not bound to the IDE. Better said I would like to see something similar to Linux virtual desktops or win32 utilities like http://techblissonline.com/virtual-desktop-for-windows-dexpot/ Bye T. -- 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Virtual Desktops in Polymorph
A solution is SeasideXUL http://code.google.com/p/seasidexul/ as the windows are handled by your window manager. See http://www.youtube.com/watch?v=pkfSh4pAbdM But you lose a lot of tools and interactivity. Cheers, Laurent Laffont On Tue, Mar 16, 2010 at 12:38 PM, Torsten Bergmann asta...@gmx.de wrote: Run second image? (joking) :) Run RFBServer on a shared image and everybody connects with a VNC client ?? That's like: You can print out a copy of you screen and have the printed paper beside your laptop ;) Hey - maybe I was not clear enough: When I currently work with Pharo I switch to full screen it is like an OS to me with it's own window manager (here Morphic/Polymorph). Unfortunately there is only one World/Desktop/Screen with windows - but I want more than one and an easy way to switch between them. So instead of Pharo image - World with many windows Pharo image - #(World with many windows, World with many windows, ...) i'm building a new IDE for Pharo It is still in development, but i included the idea of workspaces The idea is not new - Eclipse has a workspace concept - but this is running within one window (which is clonable in Eclipse by the way). VisualWorks Refactoring Browser has something similar - with switchable views within one browser. And yes, Bubbles is not bound to a single window. But I'm talking about switchable screens (switchable arrangements of windows and morphs) and not bound to the IDE. Better said I would like to see something similar to Linux virtual desktops or win32 utilities like http://techblissonline.com/virtual-desktop-for-windows-dexpot/ Bye T. -- 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Virtual Desktops in Polymorph
2010/3/16 Torsten Bergmann asta...@gmx.de: But I'm talking about switchable screens (switchable arrangements of windows and morphs) and not bound to the IDE. Yes. That would be cool. I think it even could be implemented as different native windows, each with it's own World, but all tied to the same environment. I guess it would be great to use with multiple displays. George ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Seaside XUL [was: Virtual Desktops in Polymorph]
You should have had that idea one week before ;) (GSoC) 2010/3/16 laurent laffont laurent.laff...@gmail.com Just thinking. Maybe stupid. With SeasideXUL: - we have a native portable UI - several people can work on a same image at the same time - work on a distant image easily - reuse a lot of existing XUL components - have these sort of things: http://www.youtube.com/watch?v=wIvxXebd77Efeature=related Laurent Laffont On Tue, Mar 16, 2010 at 12:45 PM, laurent laffont laurent.laff...@gmail.com wrote: A solution is SeasideXUL http://code.google.com/p/seasidexul/ as the windows are handled by your window manager. See http://www.youtube.com/watch?v=pkfSh4pAbdM But you lose a lot of tools and interactivity. Cheers, Laurent Laffont On Tue, Mar 16, 2010 at 12:38 PM, Torsten Bergmann asta...@gmx.dewrote: Run second image? (joking) :) Run RFBServer on a shared image and everybody connects with a VNC client ?? That's like: You can print out a copy of you screen and have the printed paper beside your laptop ;) Hey - maybe I was not clear enough: When I currently work with Pharo I switch to full screen it is like an OS to me with it's own window manager (here Morphic/Polymorph). Unfortunately there is only one World/Desktop/Screen with windows - but I want more than one and an easy way to switch between them. So instead of Pharo image - World with many windows Pharo image - #(World with many windows, World with many windows, ...) i'm building a new IDE for Pharo It is still in development, but i included the idea of workspaces The idea is not new - Eclipse has a workspace concept - but this is running within one window (which is clonable in Eclipse by the way). VisualWorks Refactoring Browser has something similar - with switchable views within one browser. And yes, Bubbles is not bound to a single window. But I'm talking about switchable screens (switchable arrangements of windows and morphs) and not bound to the IDE. Better said I would like to see something similar to Linux virtual desktops or win32 utilities like http://techblissonline.com/virtual-desktop-for-windows-dexpot/ Bye T. -- 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Code Freeze 1.1?
Moose, including Mondrian and Spy load well in Pharo 1.1. No big effort were needed for this. I haven't seen that many problems in porting applications to 1.1. The only thing I bumped into so far, are initialExtent (but apparently this was fixed) and tool registration. Alexandre On 16 Mar 2010, at 07:50, Stéphane Ducasse wrote: + 1 end of march for a code freeze would be great. Stef On Mar 16, 2010, at 10:19 AM, Marcus Denker wrote: Hi, Now with 1.0 done, I think we should think about freezing 1.1. The main reason of course is that 1.1 is *far more pleasent* to use than 1.0. The other thing is that 1.1 did change quite some things that have impact on external code (Preferences, as an example). So I think we should - start slowing down on 1.1 (Stef suggested that already) - start polishing (tests...) - start to look at the Dev image. - Official code freeze end of March. - Release if possible end of April (this of course depends on the state of things). Any reasons against? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [ANN 1.0] RC3! #10515 pre-built core image
On Mar 15, 2010, at 12:15 PM, Pavel Krivanek wrote: Why there are two empty ChangeSets Unnamed and Unnamed1? I should have run the cleanupForRelease two times... (or removed one). It's already better than in rc2 where there was one Unnamed changeset with *lots* of changes... I think we will just run cleanupForRelease again after harvesting the improvements related to tests that where posted. Marcus -- Pavel On Mon, Mar 15, 2010 at 10:37 AM, Marcus Denker marcus.den...@inria.fr wrote: https://gforge.inria.fr/frs/download.php/26668/PharoCore-1.0-10515rc3.zip This should be tested a lot... -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Code Freeze 1.1?
Trying to load Magma after the announcement yesterday, I ran into issues with 4 causes: - Flaps removal - MethodProperties removal - Underscore assignement - Network :P Obviously, the tests were hard to run without a network, some of the Collection tests seemed to run excessively long as well (in that I alt-. before they finished). There's also the Preferences deprecation, which is bound to cause some work. Cheers, Henry On Mar 16, 2010, at 2:10 39PM, Alexandre Bergel wrote: Moose, including Mondrian and Spy load well in Pharo 1.1. No big effort were needed for this. I haven't seen that many problems in porting applications to 1.1. The only thing I bumped into so far, are initialExtent (but apparently this was fixed) and tool registration. Alexandre On 16 Mar 2010, at 07:50, Stéphane Ducasse wrote: + 1 end of march for a code freeze would be great. Stef On Mar 16, 2010, at 10:19 AM, Marcus Denker wrote: Hi, Now with 1.0 done, I think we should think about freezing 1.1. The main reason of course is that 1.1 is *far more pleasent* to use than 1.0. The other thing is that 1.1 did change quite some things that have impact on external code (Preferences, as an example). So I think we should - start slowing down on 1.1 (Stef suggested that already) - start polishing (tests...) - start to look at the Dev image. - Official code freeze end of March. - Release if possible end of April (this of course depends on the state of things). Any reasons against? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
On Mar 16, 2010, at 9:13 AM, Lukas Renggli wrote: Btw, I am running the Pharo tests in my builds now too: http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ Click on duration twice to see the tests sorted by run-time. I feel a bit bad that the slowest test case is one that I wrote. I'll see if I can speed that up some more. lol :) It is on my todo to read the mail of yanni on hudson. Stef Lukas On 15 March 2010 20:56, stephane ducasse stephane.duca...@free.fr wrote: Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
cool! On Mar 16, 2010, at 10:16 AM, Lukas Renggli wrote: Name: Gofer-Tests-lr.117 Author: lr Time: 16 March 2010, 10:12:10 am UUID: 884f7d2b-6035-4f66-9ec3-28371a77beac Ancestors: Gofer-Tests-lr.116 - made tests run faster in the Pharo inbox is about 30% faster. Lukas On 16 March 2010 09:13, Lukas Renggli reng...@gmail.com wrote: Btw, I am running the Pharo tests in my builds now too: http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ Click on duration twice to see the tests sorted by run-time. I feel a bit bad that the slowest test case is one that I wrote. I'll see if I can speed that up some more. Lukas On 15 March 2010 20:56, stephane ducasse stephane.duca...@free.fr wrote: Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
focus on the paper jorge coding only for the fun :) We have time. Stef On Mar 16, 2010, at 9:35 AM, Jorge Ressia wrote: Hi, No, I have to finish that. Is still in my todo list. I'll try to make some time today to look into that. Cheers, Jorge On Tue, Mar 16, 2010 at 9:32 AM, Adrian Lienhard a...@netstyle.ch wrote: Yes, it would be very good to have faster tests. In my experience, if tests take too long to run, you don't use them. During the sprint in Lille, Jorge started to sort out long running tests from the rest and make them subclass from SlowTestCase (or something similar). Cheers, Adrian On Mar 16, 2010, at 09:13 , Lukas Renggli wrote: Btw, I am running the Pharo tests in my builds now too: http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ Click on duration twice to see the tests sorted by run-time. I feel a bit bad that the slowest test case is one that I wrote. I'll see if I can speed that up some more. Lukas On 15 March 2010 20:56, stephane ducasse stephane.duca...@free.fr wrote: Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] CompiledMethod#asString
open an issue. :) stef On Mar 15, 2010, at 10:36 AM, Fernando olivero wrote: (Object#name) asString class = Text Maybe we should named it 'asText' and use Lukas amazing rewriting rules to use that one instead. Fernando ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] NewTextMorph status
On Mar 15, 2010, at 11:21 AM, Fernando olivero wrote: Now we have in Pharo the following: Morph | Editor -- EntryFieldMorph | SimpleEditor NewTextMorph | TextEditor MethodMorph | SmalltalkEditor ClassDefinitionMorph | SmalltalkEditor NewTextMorph is a cleanup version based on TextMorph, that is still missing some functionality. MethodMorph and ClassDefinitonMorph are NewTextMorph for specifically viewing and editing methods and classes. I did a couple of tests also, and examples. TODO: menu support (easily done), OB and Glamour integration( high complexity?), OCompletion(fairly easy, i will work with romain on this). Stef, should i use the lastest 1.1 image as the base for preparing the SLICE? please Now Fernando when you are talking about MethodMorph and ClassDefinitionMorph this is for your ide? So may be you should keep that for you? Or/and are you saying that we should have a new SmalltalkCodeMorph that has a SmalltalkEditor? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What is the best way to...
Damien did a package to print latex but I do not know its status. I'm still dreaming about a Visitor over package, class that would produce fileout html tex Stef On Mar 15, 2010, at 12:54 PM, Hernan Wilkinson wrote: generate a document with the source code of a package? We will use pharo at the university and I want to find an easy way for the students to print out the source code of their work. Thanks. Hernan. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] A pause... for tests and orthogonal concerns
On Mar 15, 2010, at 2:09 PM, Schwab,Wilhelm K wrote: Stef, There is a part of me that wants 1.1 tomorrowg to get Alien and full freedom to use underscores, among other things. Briefly on $_, it came back up on squeak-dev, with the usual polarity and screams of doom due to poor aesthetics. It is and IMHO always will be a consideration of external interfacing and avoiding name collisions. I scanned but did not read. I think that Squeak should decide what is good for them. For us _ is banned as := _ can be in selector (not for readibility purposes :)) but for connection to stuff in C outside there :). Back on topic, tests are good thing. As far as how I can help, a good starting point will be to clean up my image build process. It appears to do a good job of identifying work that I have failed to package and saving the packages I have flagged as mine. I wonder about possible problems with dependencies among packages, but can't say that I have had problems with that; for whatever reason, cyclic dependencies magage to terrorize every new Dolphin user at some point :) I am unclear on whether Dolphin is too pedantic, Pharo is too relaxed (and somehow manages to clean up the messes later), or whether I am not pushing Pharo hard enough to have problems. Yes we should improve also on the process (not integration) but development process. Regardless of the details above, I need to revise the load step of my build, and I have been hoping that Loader will appear so I can rewrite it once rather than twice. I noticed mention today that SqueakSource was down (appears ok now). Not meaning to complain about a free service, it hit me once before and I had to add complexity to my builds to work around it; I had thought about taking that out, but a local-only option appears important. I am unclear on how to do that with Metacello - any ideas? Since Gofer supports local and distant loading. It should not be a problem. Ask in metacello ml. Dale is cool and responsive. I was going to ask about Citezen and Metacello, but the SqueakSource wiki page shows instructions for it. I will try to test it soon. Bill -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, March 14, 2010 6:06 PM To: Pharo Development Subject: [Pharo-project] A pause... for tests and orthogonal concerns hi guys I was discussing with pavel and I like his point. I would like to do a kind of pause and fix the tests. Improve a bit the fact that we get more tests incrementally to avoid regression. Tell what you think and think how you could help. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What is the best way to...
On Tue, Mar 16, 2010 at 3:25 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Damien did a package to print latex but I do not know its status. I'm still dreaming about a Visitor over package, class that would produce fileout html tex SmallAutoDoc produces html or latex. It's quite old however and I don't know it's current status: http://www.squeaksource.com/SmallAutoDoc/ -- Damien Cassou http://damiencassou.seasidehosting.st Lambdas are relegated to relative obscurity until Java makes them popular by not having them. James Iry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What is the best way to...
Also Pier-Document converts Packages, Classes and Methods to Pier pages that can then be displayed on the web or converted to LaTeX or a book or ... Lukas On 16 March 2010 15:43, Damien Cassou damien.cas...@gmail.com wrote: On Tue, Mar 16, 2010 at 3:25 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Damien did a package to print latex but I do not know its status. I'm still dreaming about a Visitor over package, class that would produce fileout html tex SmallAutoDoc produces html or latex. It's quite old however and I don't know it's current status: http://www.squeaksource.com/SmallAutoDoc/ -- Damien Cassou http://damiencassou.seasidehosting.st Lambdas are relegated to relative obscurity until Java makes them popular by not having them. James Iry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Virtual Pharo sprints
We can organize that :) Stef On Mar 15, 2010, at 7:21 PM, Germán Arduino wrote: I also Very good idea! 2010/3/15 csra...@bol.com.br: I vote strongly for this! Em 15/03/2010 11:36, Torsten Bergmann asta...@gmx.de escreveu: Since it is hard to be on two places of the world at the same time (and to save the climate) I could imagine a virtual sprint where people who are close can meet in person (in Buenos Aires, others in London, others in Berne) but work together online. One should be able to just tune in using collaborative tools (webcam, skype, IRC, Nebraska, Cobalt, ...). Ideally the tools are written in Pharo (In my archive is some working webcam code) ... Bye T. -- GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.! http://portal.gmx.net/de/go/dsl02 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Case statement and lazy comparison in Pharo
+ 1 On Mar 15, 2010, at 11:26 PM, Michael Roberts wrote: I would try and reduce the number of branches first. you can use guard conditions to exit early. This is not necessarily exact below, but you hopefully get the idea... (self currentRow == sortedRows last and: [self currentCell isNil]) ifTrue: [^self navigationKey: event] self currentRow ifNil: [^self]. self currentCell ifNil: [^self setCurrentRowToNext] self setCurrentCellToNext. self currentCell ifNil: [^self]. self currentCell performKeyFocus: event inCellBounds: (self pvtGetCellBounds: self currentCell) A different approach entirely is to have an object(s) that represents the nil state for the row and cell. That way you are not checking constantly for it being nil, and perhaps you can dispatch some behaviour to it. cheers, Mike On Mon, Mar 15, 2010 at 9:49 PM, nullPointer epic...@gmail.com wrote: Well, perhaps is a theme worked in another times but... is possible for Pharo have a basic Case or elseIf statement? I know is easy create you own structure control, but not is more useful have a standard for everybody? I´m tired of write code like that... (self currentRow == sortedRows last and: [ self currentCell isNil ]) ifTrue: [ self navigationKey: event ] ifFalse: [ (self currentRow notNil and: [ self currentCell isNil ]) ifTrue: [ self setCurrentRowToNext. ] ifFalse: [ (self currentRow notNil and: [ self currentCell notNil ]) ifTrue: [ self setCurrentCellToNext. self currentCell notNil ifTrue: [ self currentCell performKeyFocus: event inCellBounds: (self pvtGetCellBounds: self currentCell). ]. ]. ]. ]. Write code with that format is pathetical :( Is valid too have a and and or lazy? Exists a not lazy with # and #| , but could exists an # and #|| . Is more easy... value1 == value2 and:[ condition ] and: [condition] .. or value1 == value2 condition condition . ??? Well, perhaps is a stupid question but I miss a more complete way for write code. If in Smalltalk is possible do easy that and include it in core why not do it? Is a reasonable desire :) Regards -- View this message in context: http://n4.nabble.com/Case-statement-and-lazy-comparison-in-Pharo-tp1594080p1594080.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Code Freeze 1.1?
Thanks for the feedback Trying to load Magma after the announcement yesterday, I ran into issues with 4 causes: - Flaps removal we got Flaps in 1.0 :) - MethodProperties removal - Underscore assignement - Network :P Obviously, the tests were hard to run without a network, some of the Collection tests seemed to run excessively long as well (in that I alt-. before they finished). There's also the Preferences deprecation, which is bound to cause some work. Cheers, Henry On Mar 16, 2010, at 2:10 39PM, Alexandre Bergel wrote: Moose, including Mondrian and Spy load well in Pharo 1.1. No big effort were needed for this. I haven't seen that many problems in porting applications to 1.1. The only thing I bumped into so far, are initialExtent (but apparently this was fixed) and tool registration. Alexandre On 16 Mar 2010, at 07:50, Stéphane Ducasse wrote: + 1 end of march for a code freeze would be great. Stef On Mar 16, 2010, at 10:19 AM, Marcus Denker wrote: Hi, Now with 1.0 done, I think we should think about freezing 1.1. The main reason of course is that 1.1 is *far more pleasent* to use than 1.0. The other thing is that 1.1 did change quite some things that have impact on external code (Preferences, as an example). So I think we should - start slowing down on 1.1 (Stef suggested that already) - start polishing (tests...) - start to look at the Dev image. - Official code freeze end of March. - Release if possible end of April (this of course depends on the state of things). Any reasons against? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Code Freeze 1.1?
for code 1.1 I would like to be able to remove Preferences. Stef On Mar 16, 2010, at 10:19 AM, Marcus Denker wrote: Hi, Now with 1.0 done, I think we should think about freezing 1.1. The main reason of course is that 1.1 is *far more pleasent* to use than 1.0. The other thing is that 1.1 did change quite some things that have impact on external code (Preferences, as an example). So I think we should - start slowing down on 1.1 (Stef suggested that already) - start polishing (tests...) - start to look at the Dev image. - Official code freeze end of March. - Release if possible end of April (this of course depends on the state of things). Any reasons against? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [ANN 1.0] RC3! #10515 pre-built core image
thanks chris! Stef On Mar 15, 2010, at 9:13 PM, Chris Muller wrote: I am happy to report the Magma test suite ran through to completion on this version. On behalf of Pharo + Magma users, thank you. - Chris On Mon, Mar 15, 2010 at 4:49 AM, Adrian Lienhard a...@netstyle.ch wrote: Hi all, This is PharoCore RC3 and we need your help! The plan is the following: 1. Please test PharoCore RC3 (see link below) and let us know if you find any problems 2. If all is fine Mariano builds a new Pharo RC3 image in a few days 3. Then please test the Pharo RC3 image and its additional tools and report any problems 4. If all is fine we declare RC3 as the final 1.0 release Cheers, Adrian On Mar 15, 2010, at 10:37 , Marcus Denker wrote: https://gforge.inria.fr/frs/download.php/26668/PharoCore-1.0-10515rc3.zip This should be tested a lot... -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Pharo-users] Pharo party near Annecy, France
I'm sure that ESUG is ready to support the coke and other beverages. Just ask the board. Stef On Mar 15, 2010, at 4:56 PM, laurent laffont wrote: Hi Reminding. We try to know how many people will be at the event. Cheers, Laurent Laffont On Thu, Feb 25, 2010 at 6:46 PM, laurent laffont laurent.laff...@gmail.com wrote: Hi, We (a developper group) organize a Pharo Smalltalk meeting near Annecy, France. Saturday, March 20th. 2:00 pm - 6:00pm. Location. Félix Création. 4 bis, avenue du Pont de Tasset | 74960 Cran-Gevrier / ANNECY | France Welcome to all curious developpers who wants to learn. Welcome to all experienced developpers who wants to share their knowledge. We will have wireless access, big screen ... and coffee :) Send me a mail if you want to participate. Cheers, Laurent Laffont ___ Pharo-users mailing list pharo-us...@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [enh] Cleaning of and test for MessageTally
thanks On Mar 16, 2010, at 2:15 AM, Alexandre Bergel wrote: Waiting in PharoInbox. This fix has been developed in a 11271. SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1 This slices comprises an update for two packages, Tools and ToolsTest. The new version of Tools clean MessageTally. A user of MessageTally may now decide whether he wants to close the tally. Although it is convenient to close it (in order to not keep a reference of the compiled method and the class), this behavior is not always wished. Especially when test have to be written! The user has now the option to not open the result window. ToolsTest contains few and simple tests. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11272
11272 - Preparing lukas changes integration - second try ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Code Freeze 1.1?
On Mar 16, 2010, at 4:01 51PM, Stéphane Ducasse wrote: for code 1.1 I would like to be able to remove Preferences. Stef Personally, I think it's rather important to have a stable release where both are in, but where the Preferences adding raises deprecations, and the browser removed. Then, in the future, when someone tries to port an old project with Preferences, we can say Load it into a 1.1 image and fix it there. Without the availability of such a middle step, it'd be somewhat of a leap getting the code up to date. (unless you do it offline, but that's not really the smalltalk way, is it?) Cheers, Henry On Mar 16, 2010, at 10:19 AM, Marcus Denker wrote: Hi, Now with 1.0 done, I think we should think about freezing 1.1. The main reason of course is that 1.1 is *far more pleasent* to use than 1.0. The other thing is that 1.1 did change quite some things that have impact on external code (Preferences, as an example). So I think we should - start slowing down on 1.1 (Stef suggested that already) - start polishing (tests...) - start to look at the Dev image. - Official code freeze end of March. - Release if possible end of April (this of course depends on the state of things). Any reasons against? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo party near Annecy, France
Beautiful area ... and so close to Les Trois Vallées :) -- View this message in context: http://n4.nabble.com/Pharo-party-near-Annecy-France-tp1569407p1595092.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Code Freeze 1.1?
On Mar 16, 2010, at 4:52 PM, Henrik Johansen wrote: On Mar 16, 2010, at 4:01 51PM, Stéphane Ducasse wrote: for code 1.1 I would like to be able to remove Preferences. Stef Personally, I think it's rather important to have a stable release where both are in, but where the Preferences adding raises deprecations, and the browser removed. Sure this is why I did not say removed :) But nobody in the image should refer to it. Then, in the future, when someone tries to port an old project with Preferences, we can say Load it into a 1.1 image and fix it there. Without the availability of such a middle step, it'd be somewhat of a leap getting the code up to date. (unless you do it offline, but that's not really the smalltalk way, is it?) Cheers, Henry On Mar 16, 2010, at 10:19 AM, Marcus Denker wrote: Hi, Now with 1.0 done, I think we should think about freezing 1.1. The main reason of course is that 1.1 is *far more pleasent* to use than 1.0. The other thing is that 1.1 did change quite some things that have impact on external code (Preferences, as an example). So I think we should - start slowing down on 1.1 (Stef suggested that already) - start polishing (tests...) - start to look at the Dev image. - Official code freeze end of March. - Release if possible end of April (this of course depends on the state of things). Any reasons against? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Code Freeze 1.1?
On Mar 16, 2010, at 4:59 27PM, Stéphane Ducasse wrote: On Mar 16, 2010, at 4:52 PM, Henrik Johansen wrote: On Mar 16, 2010, at 4:01 51PM, Stéphane Ducasse wrote: for code 1.1 I would like to be able to remove Preferences. Stef Personally, I think it's rather important to have a stable release where both are in, but where the Preferences adding raises deprecations, and the browser removed. Sure this is why I did not say removed :) But nobody in the image should refer to it. Ah, to me it read like you wanted to remove it completely :) I thought Alain already recreated all uses in the core image as settings? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Code Freeze 1.1?
for code 1.1 I would like to be able to remove Preferences. Stef Personally, I think it's rather important to have a stable release where both are in, but where the Preferences adding raises deprecations, and the browser removed. Sure this is why I did not say removed :) But nobody in the image should refer to it. Ah, to me it read like you wanted to remove it completely :) No I will as the first action in 1.2 :) I thought Alain already recreated all uses in the core image as settings? Not all we still have Preferences used in the image and some fixes reintroduced references. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11273
11273 - - Issue 2136: Smalltalk and SmalltalkImage Rewrite Smalltalk to SmalltalkGlobals for some API. Pay attention this may take some times. 103 packages impacted. Stef And yes this was a bad idea to do this integration with the wifi in an hotel... There is no bug in the scriptLoader, just network time out at the wrong moment. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] packages :)
Hi I started to reimplement the package class is did because the previous one was a bit messy. I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. I started to build a stupid browser to check my api. Doru started to code a Glamour browser to see if this was ok. Now I would really like if - somebody could have a look at the code - develop a simple package browser showing class extensions (it would help me to define a good api to walk though a package). I started to use Momo and this is why I reimplemented the class but so far I get nearly the same interface and I think that I can do better. Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able to release a first version. So far - integration with MC - migrating from packageInfo - event notification are missing. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] packages :)
Can you provide a Gofer expression to load it? Lukas On 16 March 2010 17:21, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi I started to reimplement the package class is did because the previous one was a bit messy. I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. I started to build a stupid browser to check my api. Doru started to code a Glamour browser to see if this was ok. Now I would really like if - somebody could have a look at the code - develop a simple package browser showing class extensions (it would help me to define a good api to walk though a package). I started to use Momo and this is why I reimplemented the class but so far I get nearly the same interface and I think that I can do better. Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able to release a first version. So far - integration with MC - migrating from packageInfo - event notification are missing. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] SqNumberParserTests green
PharoInbox/KernelTests-nice.217 Ancestors: KernelTests-StephaneDucasse.216 Accepting lower case 16rff broke float reading in base 16. Let NumberParser test auto-detect whether lowercase digit letters are allowed or not, and then disbale non-10-based floating point tests. This makes the tests green again. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] packages :)
Hi, To get it: Gofer new squeaksource: 'PharoTaskForces'; package: 'RPackageAll'; load. To get a super-simple browser that shows extensions in italics: Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. To execute it on a super simple package structure: RMockFilledPackageOrganizer fillUp. (Smalltalk at: #GTCoder) openOn: RMockFilledPackageOrganizer default Cheers, Doru On 16 Mar 2010, at 17:23, Lukas Renggli wrote: Can you provide a Gofer expression to load it? Lukas On 16 March 2010 17:21, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi I started to reimplement the package class is did because the previous one was a bit messy. I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. I started to build a stupid browser to check my api. Doru started to code a Glamour browser to see if this was ok. Now I would really like if - somebody could have a look at the code - develop a simple package browser showing class extensions (it would help me to define a good api to walk though a package). I started to use Momo and this is why I reimplemented the class but so far I get nearly the same interface and I think that I can do better. Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able to release a first version. So far - integration with MC - migrating from packageInfo - event notification are missing. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Reasonable is what we are accustomed with. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] NewTextMorph status
On Mar 16, 2010, at 3:24 PM, Stéphane Ducasse wrote: Stef, should i use the lastest 1.1 image as the base for preparing the SLICE? please I''l prepare the SLICE tonight. Now Fernando when you are talking about MethodMorph and ClassDefinitionMorph this is for your ide? So may be you should keep that for you? Or/and are you saying that we should have a new SmalltalkCodeMorph that has a SmalltalkEditor? Stef I noticed that spreading the behavior to each editor, makes the code much cleaner and provides better support for maintenance and extensions. Also i'm using announcements, for announcing acceptedContents and escape pressed. This would allow us to unify the TextMorph and PluggableTextMorph, that currently (in my opinion) is mess of shared behavior and subclasification. pd: Examples of usage: t := NewTextMorph new. t text:'hola que tal como andas?. Tenemos dos lineas ahora.Y que tal tres?' asText . t onAcceptSend: #delete to: t. m := MethodMorph new. m class: Object selector:#name. m font: ( LogicalFont familyName: 'DejaVu Serif' pointSize: 15 ) copy. m := ClassDefinitionMorph new. m class: Object. e := EntryFieldMorph example1. e onAcceptSend: #hello to: e. e onEscapeSend: #delete to: e. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Congratulations Norberto Manzanos! - Re: [Pkg] Installer: Installer-Core-nm.357.mcz
Big CONGRATULATIONS to Norberto Manzanos for maintaining Installer in the proper squeaksource repository, rather than local to some fork or other. This is a breakthrough! Here's a great opportunity for developers to work out some procedures around maintaining packages external to the trunk repository, in the interest of improved modularity. Ken G. Brown At 4:15 PM +0100 3/16/10, squeak-dev-nore...@lists.squeakfoundation.org apparently wrote: A new version of Installer-Core was added to project Installer: http://www.squeaksource.com/Installer/Installer-Core-nm.357.mcz Summary Name: Installer-Core-nm.357 Author: nm Time: 16 March 2010, 12:15:30 pm UUID: 7e6635ca-259c-3549-8034-d3bbfcbd0f14 Ancestors: Installer-Core-nm.357 - still a bug on detecting version number, due to this monticello bad design. Package with names like 'Seaside2.8a1-xx.1.mcz' will be sorted wrongly. Fixed, I think === Diff against Installer-Core-nm.357 === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] packages :)
Thank you, I will give it a try (fed up writing). Lukas On 16 March 2010 18:00, Tudor Girba tudor.gi...@gmail.com wrote: Hi, To get it: Gofer new squeaksource: 'PharoTaskForces'; package: 'RPackageAll'; load. To get a super-simple browser that shows extensions in italics: Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. To execute it on a super simple package structure: RMockFilledPackageOrganizer fillUp. (Smalltalk at: #GTCoder) openOn: RMockFilledPackageOrganizer default Cheers, Doru On 16 Mar 2010, at 17:23, Lukas Renggli wrote: Can you provide a Gofer expression to load it? Lukas On 16 March 2010 17:21, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi I started to reimplement the package class is did because the previous one was a bit messy. I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. I started to build a stupid browser to check my api. Doru started to code a Glamour browser to see if this was ok. Now I would really like if - somebody could have a look at the code - develop a simple package browser showing class extensions (it would help me to define a good api to walk though a package). I started to use Momo and this is why I reimplemented the class but so far I get nearly the same interface and I think that I can do better. Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able to release a first version. So far - integration with MC - migrating from packageInfo - event notification are missing. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Reasonable is what we are accustomed with. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [enh] Cleaning of and test for MessageTally
alex I saw that you remove contentsChanged from CodeHolder. Is it on purpose? contentsChanged super contentsChanged. self changed: #annotation Stef On Mar 16, 2010, at 2:15 AM, Alexandre Bergel wrote: Waiting in PharoInbox. This fix has been developed in a 11271. SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1 This slices comprises an update for two packages, Tools and ToolsTest. The new version of Tools clean MessageTally. A user of MessageTally may now decide whether he wants to close the tally. Although it is convenient to close it (in order to not keep a reference of the compiled method and the class), this behavior is not always wished. Especially when test have to be written! The user has now the option to not open the result window. ToolsTest contains few and simple tests. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What is the best way to...
hi Lukas, I'm not a Pier expert, but how would you convert them to latex, etc? On Tue, Mar 16, 2010 at 11:54 AM, Lukas Renggli reng...@gmail.com wrote: Also Pier-Document converts Packages, Classes and Methods to Pier pages that can then be displayed on the web or converted to LaTeX or a book or ... Lukas On 16 March 2010 15:43, Damien Cassou damien.cas...@gmail.com wrote: On Tue, Mar 16, 2010 at 3:25 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Damien did a package to print latex but I do not know its status. I'm still dreaming about a Visitor over package, class that would produce fileout html tex SmallAutoDoc produces html or latex. It's quite old however and I don't know it's current status: http://www.squeaksource.com/SmallAutoDoc/ -- Damien Cassou http://damiencassou.seasidehosting.st Lambdas are relegated to relative obscurity until Java makes them popular by not having them. James Iry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [enh] Cleaning of and test for MessageTally
You have some duplicated code spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber openResultWindow: openResultWindow | node result | node := self new. node reportOtherProcesses: aBoolean. result := node spyEvery: self defaultPollPeriod on: aBlock. openResultWindow ifTrue: [ (CodeHolder new contents: (String streamContents: [:s | node report: s cutoff: aNumber; close])) openLabel: 'Spy Results' wrap: false ]. ^ node ^ result spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber openResultWindow: openResultWindow closeAfter: closeAfter | node result | node := self new. node reportOtherProcesses: aBoolean. result := node spyEvery: self defaultPollPeriod on: aBlock. openResultWindow ifTrue: [ (CodeHolder new contents: (String streamContents: [:s | node report: s cutoff: aNumber])) openLabel: 'Spy Results' wrap: false ]. closeAfter ifTrue: [ node close ]. ^ node ^ result It is a good idea to have some tests. Now maybe you should not rely on float printString but one a mock class else if we change float printing these tests will break. Stef On Mar 16, 2010, at 2:15 AM, Alexandre Bergel wrote: Waiting in PharoInbox. This fix has been developed in a 11271. SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1 This slices comprises an update for two packages, Tools and ToolsTest. The new version of Tools clean MessageTally. A user of MessageTally may now decide whether he wants to close the tally. Although it is convenient to close it (in order to not keep a reference of the compiled method and the class), this behavior is not always wished. Especially when test have to be written! The user has now the option to not open the result window. ToolsTest contains few and simple tests. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What is the best way to...
Hi Damien, I just tried it in the last pharo version and works fine. I'd like to add an option to print the methods source code. Do you mind if I do it? If so, can you add me as developer in SqueakSource for this package so I can commit the change? My user is HAW Thanks! Hernan. On Tue, Mar 16, 2010 at 11:43 AM, Damien Cassou damien.cas...@gmail.comwrote: On Tue, Mar 16, 2010 at 3:25 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Damien did a package to print latex but I do not know its status. I'm still dreaming about a Visitor over package, class that would produce fileout html tex SmallAutoDoc produces html or latex. It's quite old however and I don't know it's current status: http://www.squeaksource.com/SmallAutoDoc/ -- Damien Cassou http://damiencassou.seasidehosting.st Lambdas are relegated to relative obscurity until Java makes them popular by not having them. James Iry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about long tests
I read a few Pharo posts lately about long tests. In this regard allow me to describe briefly some code I am now writing. I will eventually release this code to SqueakSource and, if the Pharo group is interested, I will port it to run on Pharo as well. I use long tests a lot in development. These tests are not really suitable as SUnit tests because they are too slow and some of them are parameterizable. These tests are meant for finding bugs during development; less so for verifying code still works before a release. However, I decided to use the SUnit idea and code to enhance running these tests. First, I refactored TestCase by giving is a superclass and moving all the TestCase code into its superclass. I then created a class RunnCase which has the same parent class as TestCase. The reason for refactoring TestCase this way is so that if TestRunner is run the classes under RunnCase DO NOT SHOW UP. I now put my long tests into RunnCase subclasses. Note that I believe that TestCase should be so refactored even if you are not interested in using the tools I am building because it allows others to build their own tools just as I am doing. I then subclassed TestRunner with subclass TestPlusRunner. TestPlusRunner allows running the same tests as TestRunner. TestPlusRunner is like TestRunner with a few minor changes including: 1) an extra window that displays individual test case methods when only one class is selected. Subsets of test cases from an single class can be selected and run. 2) (Ignore this paragraph is you like) it has as some additional buttons. Currently the buttons are there but not the functionality. The intent of the buttons is to be able distribute the running of a set of tests over a number of computers and return to one computer only the tests that failed so they can be debugged. Specifically, the intent is to be able to file out a set of tests, send them to another user/computer, have that user/computer run those tests and send back a file containing all the tests that fail, and then be able to load the failed test and debug them. I then subclassed TestPlusRunner with subclass RunnRunner. RunnRunner runs tests of subclasses of RunnTest. RunnRunner is like TestPlusRunner with the ability to set parameters that can affect the running of tests. Currently the only parameter that can be set are a list of size values. For example, if this parameter is set to '3-5,7,9-12' then the tests that are run will be given this parameter and then use this parameter however they want but presumably either ignore it or run the test once with each of the size values: 3,4,5,7,9,10,11,12. Several other parameters are also planned: 1) seed. The seed is a value with which to initialize a random number generator that the tests can optionally use in the generation of test data for the tests. 2) number of subtests. A test may have the ability to generate and run a number of subtests (probably using 1)). This parameters indicates how many subtests to run. 3) subtest start. If a test runs 1000 subtests and then detects a failure then the user may not want to rerun the first 999 subtests before running subtest 1000 again. This parameter allow the subtests to be run starting at subtest #1000. Feedback on this work is most welcome either positive or negative (but constructive). Regardless of opinions, it would be great if the refactoring of TestCase described above were done. It is the way it should have been written in the first place. Note that some additional minor refactoring of TestCase and TestRunner is required. Email me if you want details. Regards, Ralph Boland ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] packages :)
I forgot to mention You should load RPackage-All from PharoTaskForces Stef On Mar 16, 2010, at 5:21 PM, Stéphane Ducasse wrote: Hi I started to reimplement the package class is did because the previous one was a bit messy. I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. I started to build a stupid browser to check my api. Doru started to code a Glamour browser to see if this was ok. Now I would really like if - somebody could have a look at the code - develop a simple package browser showing class extensions (it would help me to define a good api to walk though a package). I started to use Momo and this is why I reimplemented the class but so far I get nearly the same interface and I think that I can do better. Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able to release a first version. So far - integration with MC - migrating from packageInfo - event notification are missing. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] packages :)
Thank you, I will give it a try (fed up writing). this is a good sign :) Stef Lukas On 16 March 2010 18:00, Tudor Girba tudor.gi...@gmail.com wrote: Hi, To get it: Gofer new squeaksource: 'PharoTaskForces'; package: 'RPackageAll'; load. To get a super-simple browser that shows extensions in italics: Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. To execute it on a super simple package structure: RMockFilledPackageOrganizer fillUp. (Smalltalk at: #GTCoder) openOn: RMockFilledPackageOrganizer default Cheers, Doru On 16 Mar 2010, at 17:23, Lukas Renggli wrote: Can you provide a Gofer expression to load it? Lukas On 16 March 2010 17:21, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi I started to reimplement the package class is did because the previous one was a bit messy. I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. I started to build a stupid browser to check my api. Doru started to code a Glamour browser to see if this was ok. Now I would really like if - somebody could have a look at the code - develop a simple package browser showing class extensions (it would help me to define a good api to walk though a package). I started to use Momo and this is why I reimplemented the class but so far I get nearly the same interface and I think that I can do better. Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able to release a first version. So far - integration with MC - migrating from packageInfo - event notification are missing. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Reasonable is what we are accustomed with. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] SqNumberParserTests green
TX! On Mar 16, 2010, at 5:35 PM, Nicolas Cellier wrote: PharoInbox/KernelTests-nice.217 Ancestors: KernelTests-StephaneDucasse.216 Accepting lower case 16rff broke float reading in base 16. Let NumberParser test auto-detect whether lowercase digit letters are allowed or not, and then disbale non-10-based floating point tests. This makes the tests green again. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11274
11274 - - Issue 2155: Gofer test 30% faster - Issue 2153: Fixed compiler exceptions - Issue 2152: fixing Closure compiler Tests - Issue 2150: nextInto:startingAt:count: returning false count - Issue 2132: ExceptionAboutToReturn is not used - Issue 2149: MultiByteFileStreamTest forget to remove a file Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about long tests
On Mar 16, 2010, at 6:28 PM, Ralph Boland wrote: I read a few Pharo posts lately about long tests. In this regard allow me to describe briefly some code I am now writing. I will eventually release this code to SqueakSource and, if the Pharo group is interested, I will port it to run on Pharo as well. did you check the work of adrian kuhn on Sunit? I'm interested in your work but I have to get into it. What I would like is also a better way to which class I want to compute the coverage I use long tests a lot in development. These tests are not really suitable as SUnit tests because they are too slow and some of them are parameterizable. These tests are meant for finding bugs during development; less so for verifying code still works before a release. However, I decided to use the SUnit idea and code to enhance running these tests. First, I refactored TestCase by giving is a superclass and moving all the TestCase code into its superclass. I then created a class RunnCase which has the same parent class as TestCase. The reason for refactoring TestCase this way is so that if TestRunner is run the classes under RunnCase DO NOT SHOW UP. I now put my long tests into RunnCase subclasses. Note that I believe that TestCase should be so refactored even if you are not interested in using the tools I am building because it allows others to build their own tools just as I am doing. I then subclassed TestRunner with subclass TestPlusRunner. TestPlusRunner allows running the same tests as TestRunner. TestPlusRunner is like TestRunner with a few minor changes including: 1) an extra window that displays individual test case methods when only one class is selected. Subsets of test cases from an single class can be selected and run. 2) (Ignore this paragraph is you like) it has as some additional buttons. Currently the buttons are there but not the functionality. The intent of the buttons is to be able distribute the running of a set of tests over a number of computers and return to one computer only the tests that failed so they can be debugged. Specifically, the intent is to be able to file out a set of tests, send them to another user/computer, have that user/computer run those tests and send back a file containing all the tests that fail, and then be able to load the failed test and debug them. I then subclassed TestPlusRunner with subclass RunnRunner. RunnRunner runs tests of subclasses of RunnTest. RunnRunner is like TestPlusRunner with the ability to set parameters that can affect the running of tests. Currently the only parameter that can be set are a list of size values. For example, if this parameter is set to '3-5,7,9-12' then the tests that are run will be given this parameter and then use this parameter however they want but presumably either ignore it or run the test once with each of the size values: 3,4,5,7,9,10,11,12. Several other parameters are also planned: 1) seed. The seed is a value with which to initialize a random number generator that the tests can optionally use in the generation of test data for the tests. 2) number of subtests. A test may have the ability to generate and run a number of subtests (probably using 1)). This parameters indicates how many subtests to run. 3) subtest start. If a test runs 1000 subtests and then detects a failure then the user may not want to rerun the first 999 subtests before running subtest 1000 again. This parameter allow the subtests to be run starting at subtest #1000. Feedback on this work is most welcome either positive or negative (but constructive). Regardless of opinions, it would be great if the refactoring of TestCase described above were done. It is the way it should have been written in the first place. Note that some additional minor refactoring of TestCase and TestRunner is required. Email me if you want details. Regards, Ralph Boland ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11275
11275 - - Issue 2156: Accepting lower case 16rff broke float reading in base 16. Let NumberParser test auto-detect whether lowercase digit letters are allowed or not, and then disbale non-10-based floating point tests. This makes the tests green again. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What is the best way to...
hi Lukas, I'm not a Pier expert, but how would you convert them to latex, etc? It is a visitor that walks over the document tree and emits LaTeX instead of HTML. I used it to create the documentation in the appendix of my master thesis (http://scg.unibe.ch/archive/masters/Reng06a.pdf). Similar the PDF version of the Seaside Book (http://book.seaside.st) is created with a similar visitor (in this case the pages are not automatically created from comments in the system though). Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [enh] Cleaning of and test for MessageTally
I saw that you remove contentsChanged from CodeHolder. Is it on purpose? contentsChanged super contentsChanged. self changed: #annotation No, apparently some problem with the merge. It should not be removed. I update the Slice. Alexandre On Mar 16, 2010, at 2:15 AM, Alexandre Bergel wrote: Waiting in PharoInbox. This fix has been developed in a 11271. SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1 This slices comprises an update for two packages, Tools and ToolsTest. The new version of Tools clean MessageTally. A user of MessageTally may now decide whether he wants to close the tally. Although it is convenient to close it (in order to not keep a reference of the compiled method and the class), this behavior is not always wished. Especially when test have to be written! The user has now the option to not open the result window. ToolsTest contains few and simple tests. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] BTree packaging
Hi Lukas, are there plans to include BTree standard in the Pharo image? I was just wondering whether that was why the package is named Collections-BTree, or if you would renaming it to simply BTree. It's mostly intangible that I have a dirty Collections package in many image (because I often use BTree). Except that, I do find myself sometimes checking in Monticello, did I change something in Collections? Oh, no, it's just BTree.. Or is it? Let me scroll this list to be sure. :) Kind of inconvenient, kind of inconsistent for an external package. What do you think? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [enh] Cleaning of and test for MessageTally
I removed the duplicated code in SLICE-MessageTallyCleaningAndTest- Alexandre_Bergel.2 MessageTally is a nice piece of code, but a bit messy on some part. And some further cleaning is needed (e.g., the way the time is computed). I did this to fully understand how MessageTally works. This will be helpful for Pharo By Example. Cheers, Alexandre On 16 Mar 2010, at 13:24, Stéphane Ducasse wrote: You have some duplicated code spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber openResultWindow: openResultWindow | node result | node := self new. node reportOtherProcesses: aBoolean. result := node spyEvery: self defaultPollPeriod on: aBlock. openResultWindow ifTrue: [ (CodeHolder new contents: (String streamContents: [:s | node report: s cutoff: aNumber; close])) openLabel: 'Spy Results' wrap: false ]. ^ node ^ result spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber openResultWindow: openResultWindow closeAfter: closeAfter | node result | node := self new. node reportOtherProcesses: aBoolean. result := node spyEvery: self defaultPollPeriod on: aBlock. openResultWindow ifTrue: [ (CodeHolder new contents: (String streamContents: [:s | node report: s cutoff: aNumber])) openLabel: 'Spy Results' wrap: false ]. closeAfter ifTrue: [ node close ]. ^ node ^ result It is a good idea to have some tests. Now maybe you should not rely on float printString but one a mock class else if we change float printing these tests will break. Stef On Mar 16, 2010, at 2:15 AM, Alexandre Bergel wrote: Waiting in PharoInbox. This fix has been developed in a 11271. SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1 This slices comprises an update for two packages, Tools and ToolsTest. The new version of Tools clean MessageTally. A user of MessageTally may now decide whether he wants to close the tally. Although it is convenient to close it (in order to not keep a reference of the compiled method and the class), this behavior is not always wished. Especially when test have to be written! The user has now the option to not open the result window. ToolsTest contains few and simple tests. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fixed strange coloring in TestRunner
Name: SUnitGUI-LukasRenggli.61 Author: lr Time: 16 March 2010, 7:42:35 pm UUID: afa7782a-a37f-4607-8d44-6d03d0f847d6 Ancestors: SUnitGUI-StephaneDucasse.60 - fixed priority of coloring test result: if there are errors then red else if there are failures then yellow else - green -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
Sorry Stef, couldn't resist :) Now there is a distinction between unit tests and the rest of them. Unit tests are depicted as fast and model oriented tests. Later we will have to introduce more kinds of test for enriching our build and development process, tests like functional, architectural, lint, etc. 6942 unit tests run in 34 secs instead than 2:25 min running all tests. I think this will encourage developers to run the tests a little more often. I implemented a fix in the next slice. Name: SLICE-FastAndSlowTestDisociation-JorgeRessia.1 Author: JorgeRessia Time: 16 March 2010, 8:50:41 pm UUID: 9c44289b-bccb-4198-9a98-6dd9979e9bdd Ancestors: Dependencies: Gofer-Tests-JorgeRessia.117, KernelTests-JorgeRessia.164, SUnit-JorgeRessia.86, SUnitGUI-JorgeRessia.45, Tests-JorgeRessia.48 Test cases now answer the message isUnitTest in order to differentiate the unit test from the rest of the tests. - The tests that take too long are no more considered unit tests. - Some test were functional test so there are not considered unit tests. - The TestRunner was modified. A new menu entry can be found in the class pane for selecting all unit tests. Some more fixes here: Name: SLICE-FastAndSlowTestDisociation-JorgeRessia.2 Author: JorgeRessia Time: 16 March 2010, 8:58:11 pm UUID: 86461af2-534b-4091-8f2e-973b650db098 Ancestors: SLICE-FastAndSlowTestDisociation-JorgeRessia.1 Dependencies: Gofer-Tests-JorgeRessia.117, KernelTests-JorgeRessia.164, SUnit-JorgeRessia.87, SUnitGUI-JorgeRessia.45, Tests-JorgeRessia.48 - test fixed Cheers, Jorge On Tue, Mar 16, 2010 at 3:18 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: focus on the paper jorge coding only for the fun :) We have time. Stef On Mar 16, 2010, at 9:35 AM, Jorge Ressia wrote: Hi, No, I have to finish that. Is still in my todo list. I'll try to make some time today to look into that. Cheers, Jorge On Tue, Mar 16, 2010 at 9:32 AM, Adrian Lienhard a...@netstyle.ch wrote: Yes, it would be very good to have faster tests. In my experience, if tests take too long to run, you don't use them. During the sprint in Lille, Jorge started to sort out long running tests from the rest and make them subclass from SlowTestCase (or something similar). Cheers, Adrian On Mar 16, 2010, at 09:13 , Lukas Renggli wrote: Btw, I am running the Pharo tests in my builds now too: http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ Click on duration twice to see the tests sorted by run-time. I feel a bit bad that the slowest test case is one that I wrote. I'll see if I can speed that up some more. Lukas On 15 March 2010 20:56, stephane ducasse stephane.duca...@free.fr wrote: Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] BTree packaging
On Mar 16, 2010, at 7:16 PM, Chris Muller wrote: Hi Lukas, are there plans to include BTree standard in the Pharo image? I was just wondering whether that was why the package is named Collections-BTree, or if you would renaming it to simply BTree. It's mostly intangible that I have a dirty Collections package in many image (because I often use BTree). Except that, I do find myself sometimes checking in Monticello, did I change something in Collections? Oh, no, it's just BTree.. Or is it? Let me scroll this list to be sure. :) Kind of inconvenient, kind of inconsistent for an external package. What do you think? MC is from time to time marking dirty packages are not. But in your case is it that? Or is there some methods compiled? For the inclusion into pharo here is my take: - if this is important for some internal applications we can the idea is that we copy but lukas keeps control and we merge from time to time as we do with gofer. - Now our goal is to make Pharo-Core smaller and smaller (but slowly) so probably BTree should not be in the core but it could be a package to load into the pharo (core + maintained by us package) or Pharo-dev (core+ maintainedby us + external). Now once we get a nice map of published packages for a release (aka universe browser) it should be easier for people to find/load packages. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [enh] Cleaning of and test for MessageTally
Cool thanks alex. If you understand it well then may be you can write a better comment than mine about the implementation. :) Stef On Mar 16, 2010, at 8:30 PM, Alexandre Bergel wrote: I removed the duplicated code in SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.2 MessageTally is a nice piece of code, but a bit messy on some part. And some further cleaning is needed (e.g., the way the time is computed). I did this to fully understand how MessageTally works. This will be helpful for Pharo By Example. Cheers, Alexandre On 16 Mar 2010, at 13:24, Stéphane Ducasse wrote: You have some duplicated code spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber openResultWindow: openResultWindow | node result | node := self new. node reportOtherProcesses: aBoolean. result := node spyEvery: self defaultPollPeriod on: aBlock. openResultWindow ifTrue: [ (CodeHolder new contents: (String streamContents: [:s | node report: s cutoff: aNumber; close])) openLabel: 'Spy Results' wrap: false ]. ^ node ^ result spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber openResultWindow: openResultWindow closeAfter: closeAfter | node result | node := self new. node reportOtherProcesses: aBoolean. result := node spyEvery: self defaultPollPeriod on: aBlock. openResultWindow ifTrue: [ (CodeHolder new contents: (String streamContents: [:s | node report: s cutoff: aNumber])) openLabel: 'Spy Results' wrap: false ]. closeAfter ifTrue: [ node close ]. ^ node ^ result It is a good idea to have some tests. Now maybe you should not rely on float printString but one a mock class else if we change float printing these tests will break. Stef On Mar 16, 2010, at 2:15 AM, Alexandre Bergel wrote: Waiting in PharoInbox. This fix has been developed in a 11271. SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1 This slices comprises an update for two packages, Tools and ToolsTest. The new version of Tools clean MessageTally. A user of MessageTally may now decide whether he wants to close the tally. Although it is convenient to close it (in order to not keep a reference of the compiled method and the class), this behavior is not always wished. Especially when test have to be written! The user has now the option to not open the result window. ToolsTest contains few and simple tests. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fixed strange coloring in TestRunner
Thanks On Mar 16, 2010, at 7:42 PM, Lukas Renggli wrote: Name: SUnitGUI-LukasRenggli.61 Author: lr Time: 16 March 2010, 7:42:35 pm UUID: afa7782a-a37f-4607-8d44-6d03d0f847d6 Ancestors: SUnitGUI-StephaneDucasse.60 - fixed priority of coloring test result: if there are errors then red else if there are failures then yellow else - green -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
On Mar 16, 2010, at 9:06 PM, Jorge Ressia wrote: Sorry Stef, couldn't resist :) I know the syndrom (noooI do not want to open latex to write . ..) I saw the picture on your board :) Ok once your oopsla paper is done, I would do discuss with you how we integrate - adrian kuhn changes - have a look at SUnit Extension made by Keith I will start to look at that (once I'm with some other papers to write :) Stef Now there is a distinction between unit tests and the rest of them. Unit tests are depicted as fast and model oriented tests. Later we will have to introduce more kinds of test for enriching our build and development process, tests like functional, architectural, lint, etc. 6942 unit tests run in 34 secs instead than 2:25 min running all tests. I think this will encourage developers to run the tests a little more often. I implemented a fix in the next slice. Name: SLICE-FastAndSlowTestDisociation-JorgeRessia.1 Author: JorgeRessia Time: 16 March 2010, 8:50:41 pm UUID: 9c44289b-bccb-4198-9a98-6dd9979e9bdd Ancestors: Dependencies: Gofer-Tests-JorgeRessia.117, KernelTests-JorgeRessia.164, SUnit-JorgeRessia.86, SUnitGUI-JorgeRessia.45, Tests-JorgeRessia.48 Test cases now answer the message isUnitTest in order to differentiate the unit test from the rest of the tests. - The tests that take too long are no more considered unit tests. - Some test were functional test so there are not considered unit tests. - The TestRunner was modified. A new menu entry can be found in the class pane for selecting all unit tests. Some more fixes here: Name: SLICE-FastAndSlowTestDisociation-JorgeRessia.2 Author: JorgeRessia Time: 16 March 2010, 8:58:11 pm UUID: 86461af2-534b-4091-8f2e-973b650db098 Ancestors: SLICE-FastAndSlowTestDisociation-JorgeRessia.1 Dependencies: Gofer-Tests-JorgeRessia.117, KernelTests-JorgeRessia.164, SUnit-JorgeRessia.87, SUnitGUI-JorgeRessia.45, Tests-JorgeRessia.48 - test fixed Cheers, Jorge On Tue, Mar 16, 2010 at 3:18 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: focus on the paper jorge coding only for the fun :) We have time. Stef On Mar 16, 2010, at 9:35 AM, Jorge Ressia wrote: Hi, No, I have to finish that. Is still in my todo list. I'll try to make some time today to look into that. Cheers, Jorge On Tue, Mar 16, 2010 at 9:32 AM, Adrian Lienhard a...@netstyle.ch wrote: Yes, it would be very good to have faster tests. In my experience, if tests take too long to run, you don't use them. During the sprint in Lille, Jorge started to sort out long running tests from the rest and make them subclass from SlowTestCase (or something similar). Cheers, Adrian On Mar 16, 2010, at 09:13 , Lukas Renggli wrote: Btw, I am running the Pharo tests in my builds now too: http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ Click on duration twice to see the tests sorted by run-time. I feel a bit bad that the slowest test case is one that I wrote. I'll see if I can speed that up some more. Lukas On 15 March 2010 20:56, stephane ducasse stephane.duca...@free.fr wrote: Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [enh] Cleaning of and test for MessageTally
If you understand it well then may be you can write a better comment than mine about the implementation. :) Writing is like coding: it is an incremental engineering process. I will have a good description because you provided a good foundation. :-) Alexandre On Mar 16, 2010, at 8:30 PM, Alexandre Bergel wrote: I removed the duplicated code in SLICE-MessageTallyCleaningAndTest- Alexandre_Bergel.2 MessageTally is a nice piece of code, but a bit messy on some part. And some further cleaning is needed (e.g., the way the time is computed). I did this to fully understand how MessageTally works. This will be helpful for Pharo By Example. Cheers, Alexandre On 16 Mar 2010, at 13:24, Stéphane Ducasse wrote: You have some duplicated code spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber openResultWindow: openResultWindow | node result | node := self new. node reportOtherProcesses: aBoolean. result := node spyEvery: self defaultPollPeriod on: aBlock. openResultWindow ifTrue: [ (CodeHolder new contents: (String streamContents: [:s | node report: s cutoff: aNumber; close])) openLabel: 'Spy Results' wrap: false ]. ^ node ^ result spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber openResultWindow: openResultWindow closeAfter: closeAfter | node result | node := self new. node reportOtherProcesses: aBoolean. result := node spyEvery: self defaultPollPeriod on: aBlock. openResultWindow ifTrue: [ (CodeHolder new contents: (String streamContents: [:s | node report: s cutoff: aNumber])) openLabel: 'Spy Results' wrap: false ]. closeAfter ifTrue: [ node close ]. ^ node ^ result It is a good idea to have some tests. Now maybe you should not rely on float printString but one a mock class else if we change float printing these tests will break. Stef On Mar 16, 2010, at 2:15 AM, Alexandre Bergel wrote: Waiting in PharoInbox. This fix has been developed in a 11271. SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1 This slices comprises an update for two packages, Tools and ToolsTest. The new version of Tools clean MessageTally. A user of MessageTally may now decide whether he wants to close the tally. Although it is convenient to close it (in order to not keep a reference of the compiled method and the class), this behavior is not always wished. Especially when test have to be written! The user has now the option to not open the result window. ToolsTest contains few and simple tests. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] packages :)
I have some comments, to both the package implementation and the Glamour browser. The other browser didn't work, I guess I miss some extra package. - I used the code below to import the existing packages into the new model. Maybe something like this should be included on the class side of RPackageOrganizer to have a realistic model? | package | PackageOrganizer default packages do: [ :info | package := RPackage2 named: info packageName. info classes do: [ :each | package addClassDefinition: each ]. info coreMethods do: [ :each | each isValid ifTrue: [ package addMethod: each compiledMethod isExtension: false ] ]. info extensionMethods do: [ :each | each isValid ifTrue: [ package addMethod: each compiledMethod isExtension: true ] ] ] displayingProgress: 'Importing' Then I opened the glamour browser using: GTCoder openOn: RPackageOrganizer default - I find it quite strange that I have to declare if a method is an extension or not. Isn't a that obvious when looking at the defined classes? Having two dictionaries for methods makes it extremely difficult to move stuff around because always 4 separate cases need to be handled. - The fact that compiled methods are stored in the model is very dangerous. You might hold onto compiled methods that have long been replaced with other ones. Just by playing a bit with the model I run into that situation (I don't know how). I think just keeping the selector internally would be much safer and solve all kinds of troubles (exactly like this is done for the classes). You'll have to check anyway if the method is still present when you iterate over the methods. A single use of #doSilently: (and there are lots of them in the image) can completely screw up the complete package model. - The browser displays nicely the extended classes, but for the methods I don't see the protocols and the complete set of selectors implemented. I think these things should be part of the browser, otherwise we don't see if the package model can answer these queries quick enough. - The browser displays extension methods on both instance and class-side. When browsing an extended class, the extensions are not displayed. That's it for the moment. I see a cool model emerging :-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] classNameCache/classNames problem
Hi, I tried to run tests in Pharo 1.1 #11275 and then I got an error when trying to open Message Names. The reason is that if you evaluate Smalltalk classNames includes: #C1 you got true so Smalltalk classNames includes it however it is not present in Smalltalk globals. After Smalltalk flushClassNameCache the problem disapeared. If I tried to create a class named SomeClass, the result was: Smalltalk classNames includes: #SomeClass - false Smalltalk globals at: #SomeClass - SomeClass I had to remove Object#initialExtent because of neverending deperecation warning (a methods tries respondsTo: #initialExtent on a model. I don't know which one because Recent Submissions doesn't work because of method reference AutoGeneratedClassForTestingSystemChanges#Comment anwered nil on actualClass message) -- Pavel ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] packages :)
Hi Lukas, On 16 Mar 2010, at 21:50, Lukas Renggli wrote: I have some comments, to both the package implementation and the Glamour browser. The other browser didn't work, I guess I miss some extra package. - I used the code below to import the existing packages into the new model. Maybe something like this should be included on the class side of RPackageOrganizer to have a realistic model? | package | PackageOrganizer default packages do: [ :info | package := RPackage2 named: info packageName. info classes do: [ :each | package addClassDefinition: each ]. info coreMethods do: [ :each | each isValid ifTrue: [ package addMethod: each compiledMethod isExtension: false ] ]. info extensionMethods do: [ :each | each isValid ifTrue: [ package addMethod: each compiledMethod isExtension: true ] ] ] displayingProgress: 'Importing' Then I opened the glamour browser using: GTCoder openOn: RPackageOrganizer default - I find it quite strange that I have to declare if a method is an extension or not. Isn't a that obvious when looking at the defined classes? Stef said that this was a reminiscent from before deciding he wants to declare the class explicitly, but we agreed that specifying the extension explicitly is not necessary. Having two dictionaries for methods makes it extremely difficult to move stuff around because always 4 separate cases need to be handled. I also do not like this part either. - The fact that compiled methods are stored in the model is very dangerous. You might hold onto compiled methods that have long been replaced with other ones. Just by playing a bit with the model I run into that situation (I don't know how). I think just keeping the selector internally would be much safer and solve all kinds of troubles (exactly like this is done for the classes). You'll have to check anyway if the method is still present when you iterate over the methods. A single use of #doSilently: (and there are lots of them in the image) can completely screw up the complete package model. The model does not store compiled methods, or classes. It only stores symbols. - The browser displays nicely the extended classes, but for the methods I don't see the protocols and the complete set of selectors implemented. I think these things should be part of the browser, otherwise we don't see if the package model can answer these queries quick enough. I agree, but this was just a quick thing to see what kind of navigation methods are needed to get the classes and methods. Categories are still to be added. - The browser displays extension methods on both instance and class-side. When browsing an extended class, the extensions are not displayed. Yes, these were bugs :). I tried to fix these, but I think I bumped into other problems, so I will stop for now. Cheers, Doru That's it for the moment. I see a cool model emerging :-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Sometimes the best solution is not the best solution. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] packages :)
- The fact that compiled methods are stored in the model is very dangerous. You might hold onto compiled methods that have long been replaced with other ones. Just by playing a bit with the model I run into that situation (I don't know how). I think just keeping the selector internally would be much safer and solve all kinds of troubles (exactly like this is done for the classes). You'll have to check anyway if the method is still present when you iterate over the methods. A single use of #doSilently: (and there are lots of them in the image) can completely screw up the complete package model. The model does not store compiled methods, or classes. It only stores symbols. True, sorry about that. I did not open the inspector wide enough and I somehow made that conclusion from the public API :-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Case statement and lazy comparison in Pharo
cool :D On Tue, Mar 16, 2010 at 3:58 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: + 1 On Mar 15, 2010, at 11:26 PM, Michael Roberts wrote: I would try and reduce the number of branches first. you can use guard conditions to exit early. This is not necessarily exact below, but you hopefully get the idea... (self currentRow == sortedRows last and: [self currentCell isNil]) ifTrue: [^self navigationKey: event] self currentRow ifNil: [^self]. self currentCell ifNil: [^self setCurrentRowToNext] self setCurrentCellToNext. self currentCell ifNil: [^self]. self currentCell performKeyFocus: event inCellBounds: (self pvtGetCellBounds: self currentCell) A different approach entirely is to have an object(s) that represents the nil state for the row and cell. That way you are not checking constantly for it being nil, and perhaps you can dispatch some behaviour to it. cheers, Mike On Mon, Mar 15, 2010 at 9:49 PM, nullPointer epic...@gmail.com wrote: Well, perhaps is a theme worked in another times but... is possible for Pharo have a basic Case or elseIf statement? I know is easy create you own structure control, but not is more useful have a standard for everybody? I´m tired of write code like that... (self currentRow == sortedRows last and: [ self currentCell isNil ]) ifTrue: [ self navigationKey: event ] ifFalse: [ (self currentRow notNil and: [ self currentCell isNil ]) ifTrue: [ self setCurrentRowToNext. ] ifFalse: [ (self currentRow notNil and: [ self currentCell notNil ]) ifTrue: [ self setCurrentCellToNext. self currentCell notNil ifTrue: [ self currentCell performKeyFocus: event inCellBounds: (self pvtGetCellBounds: self currentCell). ]. ]. ]. ]. Write code with that format is pathetical :( Is valid too have a and and or lazy? Exists a not lazy with # and #| , but could exists an # and #|| . Is more easy... value1 == value2 and:[ condition ] and: [condition] .. or value1 == value2 condition condition . ??? Well, perhaps is a stupid question but I miss a more complete way for write code. If in Smalltalk is possible do easy that and include it in core why not do it? Is a reasonable desire :) Regards -- View this message in context: http://n4.nabble.com/Case-statement-and-lazy-comparison-in-Pharo-tp1594080p1594080.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] BTree packaging
El mar, 16-03-2010 a las 13:16 -0500, Chris Muller escribió: Hi Lukas, are there plans to include BTree standard in the Pharo image? I was just wondering whether that was why the package is named Collections-BTree, or if you would renaming it to simply BTree. It's mostly intangible that I have a dirty Collections package in many image (because I often use BTree). Except that, I do find myself sometimes checking in Monticello, did I change something in Collections? Oh, no, it's just BTree.. Or is it? Let me scroll this list to be sure. :) Kind of inconvenient, kind of inconsistent for an external package. What do you think? -1 to add it to PharoCore. The aim is to reduce package and load them when necessary, as stand-alone package or as a dependency for another package. The reasons are the same to the integration of Lukas' generator code to squeak. It is a one more thing to watch for updates in maintaining the core image. If it is external and have a ConfigurationOfXXX then it can be loaded when needed. Maybe can be added if enough quorum, to the ConfigurationOfPharo package in order to be loaded in a development, end user oriented Pharo image. There we can have all the packages we want. http://code.google.com/p/pharo/wiki/Packages Cheers ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] A challenge for us
If I understand correctly, i.e., committing to one task per month I'm more than willing to help. What would be the protocol to cooperate on this? -- Cesar Rabak Em 16/03/2010 04:21, Stéphane Ducasse stephane.duca...@inria.fr escreveu: Hi I would like to initiative a task (monthly) for us. I would like to get really good tests coverage for some of the core classes. For example Date, Time, Duration, DateAndTime. This is really important in the long term to get sure that we identify bugs as soon as they appear. It would be really good if we could get team up and fix that together. Does anybody want to help? I started to fix some bugs there and write more tests in the process of fixing tests. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] BTree packaging
-1 from me too about including it in Pharo or any other image. I don't want to include BTree in any image. I was just asking about the naming. Since Squeak has a package called Collections, loading BTree in Squeak makes that package dirty. Now, I agree there is a nostalgic element about that, and is the original name that Avi gave it. However, I suspect the Collections category of Squeak was there long before BTree came about. There seems to be consensus that no one thinks BTree belongs in a base image, and so it seems inappropriate to for an external package to invade the namespace of such a general category, Collections. Perhaps, Avi wouldn't mind if the package were renamed to simply BTree instead of Collections-BTree. I really think there are rewards to be harvested by our practicing considerate collaboration and synergy between the communities. - Chris On Tue, Mar 16, 2010 at 3:27 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: On Mar 16, 2010, at 7:16 PM, Chris Muller wrote: Hi Lukas, are there plans to include BTree standard in the Pharo image? I was just wondering whether that was why the package is named Collections-BTree, or if you would renaming it to simply BTree. It's mostly intangible that I have a dirty Collections package in many image (because I often use BTree). Except that, I do find myself sometimes checking in Monticello, did I change something in Collections? Oh, no, it's just BTree.. Or is it? Let me scroll this list to be sure. :) Kind of inconvenient, kind of inconsistent for an external package. What do you think? MC is from time to time marking dirty packages are not. But in your case is it that? Or is there some methods compiled? For the inclusion into pharo here is my take: - if this is important for some internal applications we can the idea is that we copy but lukas keeps control and we merge from time to time as we do with gofer. - Now our goal is to make Pharo-Core smaller and smaller (but slowly) so probably BTree should not be in the core but it could be a package to load into the pharo (core + maintained by us package) or Pharo-dev (core+ maintainedby us + external). Now once we get a nice map of published packages for a release (aka universe browser) it should be easier for people to find/load packages. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] A challenge for us
Same here. Sounds nice to start cooperating. How can I help? On Tue, Mar 16, 2010 at 10:28 PM, csra...@bol.com.br wrote: If I understand correctly, i.e., committing to one task per month I'm more than willing to help. What would be the protocol to cooperate on this? -- Cesar Rabak Em 16/03/2010 04:21, Stéphane Ducasse stephane.duca...@inria.fr escreveu: Hi I would like to initiative a task (monthly) for us. I would like to get really good tests coverage for some of the core classes. For example Date, Time, Duration, DateAndTime. This is really important in the long term to get sure that we identify bugs as soon as they appear. It would be really good if we could get team up and fix that together. Does anybody want to help? I started to fix some bugs there and write more tests in the process of fixing tests. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] BTree packaging
Ok, I just saw that Pharo has Collections-This and Collectoins-That. So I can understand why you said Collections-BTree fits right in nicely. So maybe if Squeak renamed Collections similarly to what Pharo did, MC allows a dash in a package name and treats it as one unique name? On Tue, Mar 16, 2010 at 8:03 PM, Chris Muller asquea...@gmail.com wrote: -1 from me too about including it in Pharo or any other image. I don't want to include BTree in any image. I was just asking about the naming. Since Squeak has a package called Collections, loading BTree in Squeak makes that package dirty. Now, I agree there is a nostalgic element about that, and is the original name that Avi gave it. However, I suspect the Collections category of Squeak was there long before BTree came about. There seems to be consensus that no one thinks BTree belongs in a base image, and so it seems inappropriate to for an external package to invade the namespace of such a general category, Collections. Perhaps, Avi wouldn't mind if the package were renamed to simply BTree instead of Collections-BTree. I really think there are rewards to be harvested by our practicing considerate collaboration and synergy between the communities. - Chris On Tue, Mar 16, 2010 at 3:27 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: On Mar 16, 2010, at 7:16 PM, Chris Muller wrote: Hi Lukas, are there plans to include BTree standard in the Pharo image? I was just wondering whether that was why the package is named Collections-BTree, or if you would renaming it to simply BTree. It's mostly intangible that I have a dirty Collections package in many image (because I often use BTree). Except that, I do find myself sometimes checking in Monticello, did I change something in Collections? Oh, no, it's just BTree.. Or is it? Let me scroll this list to be sure. :) Kind of inconvenient, kind of inconsistent for an external package. What do you think? MC is from time to time marking dirty packages are not. But in your case is it that? Or is there some methods compiled? For the inclusion into pharo here is my take: - if this is important for some internal applications we can the idea is that we copy but lukas keeps control and we merge from time to time as we do with gofer. - Now our goal is to make Pharo-Core smaller and smaller (but slowly) so probably BTree should not be in the core but it could be a package to load into the pharo (core + maintained by us package) or Pharo-dev (core+ maintainedby us + external). Now once we get a nice map of published packages for a release (aka universe browser) it should be easier for people to find/load packages. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] squeaksource is down....
I see on https://gforge.inria.fr/ : Pharo is the 5th most downloaded project ! On Tue, Mar 16, 2010 at 9:20 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: I asked to see if we can have a support for a webdav server for pharo core packages here but they are flooded ... Because I imagine that the pharo folder is getting to explode one of these days. Stef On Mar 15, 2010, at 8:51 AM, Geert Claes wrote: on another note ... SqueakSource probably needs an overhaul doesn't it ... whatever happened to SourceTalk? -- View this message in context: http://n4.nabble.com/squeaksource-is-down-tp1592562p1593040.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/ ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
