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

Re: [Pharo-project] [Pharo-users] TestSprinter

by StÃ©phane Ducasse

icons to see which tests failed since last run and a summary previous run: current: 150 green 149 green 2 failure 2 failutres 1 errors could be presented differently On Sep 3, 2010, at 12:31 AM, Benjamin Van Ryseghem wrote: > Hello everybody > > I'm now working on a new Test Runner tool and I wonder which behaviours do you want me to implement. > > For now, I want the Test Sprinter to be able to : > - search through packages and classes thanks to search fields. > - browse the hierarchy from packages to test methods (with icons). > - create groups of tests easily re-runnable. > > If you have any ideas, I'm waiting for them ;) > > > Thank you > > > Ben _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

Sept. 3, 2010

Re: [Pharo-project] Single instance executables

by StÃ©phane Ducasse

;) Stef On Sep 2, 2010, at 11:59 PM, Henrik Sperre Johansen wrote: > On 02.09.2010 21:45, Schwab,Wilhelm K wrote: >> Hello all, >> >> I realize that I hold an unpopular position on this, but it *will* come back to haunt us: we need to have a way to warn the user if a second copy of Pharo is launched. Random meltdowns and lost work will result from the current behavior. Let me be more bold: lost work and random corrrupted images *are resulting* from the current behavior; they are either unrecognized, or simply ignored, but it is happening. >> >> Is there a way to fix it? On Windows, I recall creating an OS semaphore with a given name and if that exists, bail out before the session even gets going. We would need a cross-platform way to do that (or at least a Linux/Mac way to do it - Windows has a mechanism), and then a place to abort startup early enough to prevent problems. Any ideas? >> >> Bill > On Windows, it will give you an error that it was unable to open the changes file when you open the second image. > > Cheers, > Henry > > PS. I think Steph agrees, given his experience with updates that mysteriously contain seemingly random bits of other methods' source code :) > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 3, 2010

Re: [Pharo-project] Fwd: [squeak-dev] The Trunk: System-eem.366.mcz

by Tudor Girba

Hi, Indeed, it would be great to get this restarted. I do not have enough capacity to drive, but I can help. Doru On 2 Sep 2010, at 09:27, StÃ©phane Ducasse wrote: > What we started to do and got stalled (for RPackage) is to implement > SystemAnnouncement > a hierarchy that wrap event and should be ready to replace > SystemChangeNotifier. > Alain told me that he wants to help for RPackage so we should get > some speed on that. > Alain if you load ConfigurationOfRPackage in PharoTaskForces you > will see what I mean. > Stef > > > On Sep 1, 2010, at 10:48 PM, Henrik Sperre Johansen wrote: > >> Just remember to add corresponding deregistration in shutdown if >> SystemChangeNotifier is reimplemented using Announcements :) >> >> (hint: Announcers do not care if objects register multiple times to >> the same Announcement) >> >> Cheers, >> Henry >> >> On 01.09.2010 22:41, StÃ©phane Ducasse wrote: >>> muchas gratias. >>> >>> >>> Stef >>> >>> On Sep 1, 2010, at 9:08 PM, Adrian Lienhard wrote: >>> >>>> I created a changeset and attached it to the appropriate ticket: http://code.google.com/p/pharo/issues/detail?id=2896 >>>> >>>> Adrian >>>> >>>> On Sep 1, 2010, at 09:52 , StÃ©phane Ducasse wrote: >>>> >>>>> seems like we should do something :) >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: John M McIntosh<johnmci(a)smalltalkconsulting.com> >>>>>> Date: September 1, 2010 1:12:28 AM GMT+02:00 >>>>>> To: StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> >>>>>> Subject: Fwd: [squeak-dev] The Trunk: System-eem.366.mcz >>>>>> Reply-To: johnmci(a)smalltalkconsulting.com >>>>>> >>>>>> In case this gets overlooked being hidden in a update for The >>>>>> Trunk: System-eem. >>>>>> >>>>>> The EndianCache does need to be cleared at shutdown versus in >>>>>> startup. >>>>>> I can't speak for the SystemChangeNotifier since I'm not sure >>>>>> what the bug is.. >>>>>> >>>>>> Of course I'm not quite sure if anyone in the Pharo group looks >>>>>> and the trunk updates and moves things across? >>>>>> >>>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>>> From: commits(a)source.squeak.org >>>>>>> Date: August 31, 2010 5:47:35 PM PDT >>>>>>> To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org >>>>>>> Subject: [squeak-dev] The Trunk: System-eem.366.mcz >>>>>>> Reply-To: squeak-dev(a)lists.squeakfoundation.org >>>>>>> >>>>>>> Eliot Miranda uploaded a new version of System to project The >>>>>>> Trunk: >>>>>>> http://source.squeak.org/trunk/System-eem.366.mcz >>>>>>> >>>>>>> ==================== Summary ==================== >>>>>>> >>>>>>> Name: System-eem.366 >>>>>>> Author: eem >>>>>>> Time: 31 August 2010, 10:47:17.97 am >>>>>>> UUID: 2126e5d9-4d47-4cc1-921f-daefd935aedd >>>>>>> Ancestors: System-nice.365 >>>>>>> >>>>>>> Make sure system notifications for Smalltalk are up-to-date >>>>>>> on start-up. >>>>>>> Fix voiding of Smalltalk's endian cache which needs to be done >>>>>>> in a timely manner. >>>>>>> >>>>>>> =============== Diff against System-nice.365 =============== >>>>>>> >>>>>>> Item was changed: >>>>>>> ----- Method: SmalltalkImage class>>startUp (in category >>>>>>> 'class initialization') ----- >>>>>>> startUp >>>>>>> + SystemChangeNotifier uniqueInstance notify: Smalltalk >>>>>>> ofAllSystemChangesUsing: #event:! >>>>>>> - "XXXX: This is broken. SmalltalkImage startUp happens quite >>>>>>> late in the startup sequence; earlier startups may very well >>>>>>> need the information about the endianness of the platform." >>>>>>> - EndianCache := nil. >>>>>>> - ! >>>>>>> >>>>>>> Item was changed: >>>>>>> ----- Method: SmalltalkImage>>processShutDownList: (in >>>>>>> category 'snapshot and quit') ----- >>>>>>> processShutDownList: quitting >>>>>>> + "Send #shutDown to each class that needs to wrap up before >>>>>>> a snapshot. >>>>>>> + Also void the endianness chace; this can't safely be done >>>>>>> on start-up because >>>>>>> + Smalltalk is too late in the start-up sequence." >>>>>>> - "Send #shutDown to each class that needs to wrap up before >>>>>>> a snapshot." >>>>>>> >>>>>>> + EndianCache := nil. >>>>>>> + self send: #shutDown: toClassesNamedIn: ShutDownList with: >>>>>>> quitting! >>>>>>> - self send: #shutDown: toClassesNamedIn: ShutDownList with: >>>>>>> quitting. >>>>>>> - ! >>>>>>> >>>>>>> >>>>>> -- >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> ================================================================= >>>>>> John M. McIntosh<johnmci(a)smalltalkconsulting.com> Twitter: >>>>>> squeaker68882 >>>>>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> ================================================================= >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Be rather willing to give than demanding to get."

Sept. 3, 2010

[Pharo-project] Native (OS-level) windows

by Evgeniy Philippov

Hello folks and Todd Blanchard, I have three questions. First question is---what is the current status of Ffenestri, and where can I download some version of Pharo with the most up-to-date Ffenestri support? The second question is---what are the other Pharo OS-level windowing interfaces, and what is their status? And the last question is---what is more complete: Squeak's Ffenestri support, or Pharo's Ffenestri support? My intents. I plan to use some version of Squeak or Pharo system for my project (which is a hobby project), and I am mainly interested in OS-level windowing for Linux (Ubuntu) and to a lesser extent for Win32 too. I studied wxSqueak a bit, and concluded that Ffenestri is overall simpler to develop than wxSqueak, and guessed that Ffenestri moves/will move faster when considering the completeness of it, than wxSqueak. -- Evgeniy

Sept. 3, 2010

Re: [Pharo-project] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b7

by Tudor Girba

Hi John, I tried the VM on Mac OS X 10.5.8 and it just crashes on an image that works perfectly with 5.8.b4. I will soon upgrade to Snow Leopard (finally :)), but I can still play around today if you want me to test further. Cheers, Doru On 3 Sep 2010, at 03:25, John M McIntosh wrote: > I've stuck a version (5.8b7) of the cocoa based os-x squeak cog JIT > based VM in my experimental folder. > Please ensure drawing looks sane, and how it interacts with the > mouse and keyboard seems viable. > > http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b7.app.zip > > I finished the open/GL tuning and based on benchmarking I simplified > the explicit flush required when a > Smalltalk Morphic draw cycle fails to do a flush. Lastly I cross > check the source code to ensure it compiles > correctly for the iOS platform. > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Reasonable is what we are accustomed with."

Sept. 3, 2010

Re: [Pharo-project] Package comments

by Schwab,Wilhelm K

+10 ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean(a)clipperadams.com] Sent: Thursday, September 02, 2010 11:01 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Package comments I yearn for package comments, especially when hunting for a starting point in a new package. What say you? Sean p.s. For reference, I started a Squeak issue with links to previous discussions here - http://bugs.squeak.org/view.php?id=7558. -- View this message in context: http://forum.world.st/Package-comments-tp2525056p2525056.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 3, 2010

[Pharo-project] Package comments

by Sean P. DeNigris

I yearn for package comments, especially when hunting for a starting point in a new package. What say you? Sean p.s. For reference, I started a Squeak issue with links to previous discussions here - http://bugs.squeak.org/view.php?id=7558. -- View this message in context: http://forum.world.st/Package-comments-tp2525056p2525056.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 3, 2010

[Pharo-project] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b7

by John M McIntosh

I've stuck a version (5.8b7) of the cocoa based os-x squeak cog JIT based VM in my experimental folder. Please ensure drawing looks sane, and how it interacts with the mouse and keyboard seems viable. http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b7.app.zip I finished the open/GL tuning and based on benchmarking I simplified the explicit flush required when a Smalltalk Morphic draw cycle fails to do a flush. Lastly I cross check the source code to ensure it compiles correctly for the iOS platform. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Sept. 3, 2010

Re: [Pharo-project] TestSprinter

by Schwab,Wilhelm K

You might want to look at the SUnit browser in Dolphin. Its appearance is great. The way it works is pretty much like every other test runner I have seen: it's nice for verifying the all is well; it stinks for working with failing tests. For the latter, I find there is no competition (yet anyway) for a TesCase class side method called #prod: which runs a single test method and either does nothing (good news) or raises a walkback. That goes straight to the problem and there is no worrying about what the tool is going to "think of next" in terms of losing context. At times I have gone so far as to create methods that run tests referencing a class or selector, etc., but I tend to lose track of them. #prod: is perennial. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Benjamin Van Ryseghem [benjamin.vanryseghem(a)gmail.com] Sent: Thursday, September 02, 2010 6:30 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] TestSprinter Hello everybody I'm now working on a new Test Runner tool and I wonder which behaviours do you want me to implement. For now, I want the Test Sprinter to be able to : - search through packages and classes thanks to search fields. - browse the hierarchy from packages to test methods (with icons). - create groups of tests easily re-runnable. If you have any ideas, I'm waiting for them ;) Thank you Ben

Sept. 3, 2010

Re: [Pharo-project] [squeak-dev] Re: Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.

by Henrik Sperre Johansen

On 03.09.2010 00:48, Alexandre Bergel wrote: >>> This is partially the case in Mondrian. Objects located outside the window are not rendered. >> Ehm, my memory was a bit hazy. > No problem :-) > >> In the version I used, MONode>displayOn: did do culling, no such luck for MOEdge though. > MOEdge does not do the culling since an edge can be visible without having its two extremity visible. Edges are indeed a problem. Having very non-embedded and very long edges costs a lot. Unless edges can be curved, a simple rect-rect intersection would be quite sufficient for eliminating lots of edges, at least in the zoomed in scenario. >> Since MOGraphElement>>elementsToDisplay created a cache of ALL the subnodes and subedges of an element (as part of MONode>displayOn:), well, when the top element was told to displayOn:, it saw itself as visible, then displayOn:'ed all the objects and edges in the model (from the z-order sorted elementsToDisplayCache), leading to culling of offscreen objects, but drawing all edges in the entire model. > yes, edges are drawn. Eh, that was maybe a bit cryptic. What I meant was, even if you do culling at the object level, you're still iterating over the entire model deciding what should be rendered every displayOn: call (if only just to perform an isVisible: check). What you really need (in _addition_ to the current graph-model, which works great for reporting damage rects etc when manipulating the model), is f.ex. a quad-tree structure based on the physical location of the objects, which can be used for culling during the rendering phase. > One way to improve the rendering speed up, is to first display the nodes visible, then continuing the layout in 2 threads, one vertically and another one horizontally (to follow the two scrollbar of the window, since those are likely to be used first when the window appear). But this would imply a major change in the way layout are computed. > > Alexandre The simple way to get better performance is by profiling, and doing less. Doing culling properly is a good and (relatively to what you describe) simple first step. That, and, I just realized, drawing each visible object once. ;) If I'm not wrong (haven't tested it) the elementsToDisplay is created using allSubNodes/EdgesDo: , so what happens in the cases where displayOn: is called to one of the visible subnodes, which also has visible subnodes? Cheers, Henry

Sept. 2, 2010