January 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Using AlienOpenGL

by Ricardo Jacas

hi, im trying to work with the AlienOpenGL library, in ubuntu, but i cant get even the test to run. it keeps saying i dont have a basic library but i dont have a clue how to get it. i have been all day ready post about it and i simply cant make it. anyone can do a stupid proof guide? Ricardo -- lets reign all together

Jan. 20, 2011

Re: [Pharo-project] Hapao for Test coverage!

by Alexandre Bergel

Hi Lukas! You made good points. We will fix them. Thanks for these feedback. Cheers, Alexandre On 20 Jan 2011, at 15:14, Lukas Renggli wrote: > Very cool. > > I encountered two problems when trying the ready-made image on the > packages 'PetitParser' and 'PetitTest': > > 1. In Profiler>>#runningUnitTests:atEachTestEvaluate: the message > #selector is not understood by TestSuite. It worked after I commented > "Transcript show: t selector; cr." and "(self testMethodsToIgnore > includes: t selector)". > > 2. There is a bug with package extensions: Hapao considers extension > methods that are not part of the selected packages as not covered and > also displays them in the visualization. This is misleading and gives > wrong results for '% coverage'. > > Lukas > > On 20 January 2011 09:41, Vanessa PeÃ±a <vane.c.pena(a)gmail.com> wrote: >> Hello all, >> >> We are happy to introduce you Hapao, an innovative test coverage tool which >> gives you an intuitive graphical representation to visually assess the >> quality of the coverage. >> >> For more information and download you can visit us at: >> http://hapao.dcc.uchile.cl/ >> Of course, all feedback is always welcome :) >> >> Have fun! >> The Hapao Team. >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 20, 2011

Re: [Pharo-project] Hapao for Test coverage!

by Lukas Renggli

Very cool. I encountered two problems when trying the ready-made image on the packages 'PetitParser' and 'PetitTest': 1. In Profiler>>#runningUnitTests:atEachTestEvaluate: the message #selector is not understood by TestSuite. It worked after I commented "Transcript show: t selector; cr." and "(self testMethodsToIgnore includes: t selector)". 2. There is a bug with package extensions: Hapao considers extension methods that are not part of the selected packages as not covered and also displays them in the visualization. This is misleading and gives wrong results for '% coverage'. Lukas On 20 January 2011 09:41, Vanessa PeÃ±a <vane.c.pena(a)gmail.com> wrote: > Hello all, > > We are happy to introduce you Hapao, an innovative test coverage tool which > gives you an intuitive graphical representation to visually assess the > quality of the coverage. > > For more information and download you can visit us at: > http://hapao.dcc.uchile.cl/ > Of course, all feedback is always welcome :) > > Have fun! > The Hapao Team. > > -- Lukas Renggli www.lukas-renggli.ch

Jan. 20, 2011

Re: [Pharo-project] About XML Support in the 1.2

by Dale Henrichs

On 01/19/2011 11:37 PM, Norbert Hartl wrote: > > On 19.01.2011, at 19:01, Dale Henrichs wrote: > >> I think that the a good working model is to store the >> ConfigurationOfXXX in the project repository along with the >> project mcz files. >> >> When a new version is released the configuration should be copied >> to MetacelloRepository for the Pharo and Squeak community. I have >> a GemSource MetacelloRepository where I put copies of >> configurations that have been ported to GemStone .... when a new >> version for GemStone is available. >> >> I would not recommend that configurations be removed from >> MetacelloRepository as that could break existing configurations >> that expect to find the configuration there. So if it is found >> that there are out-of-date configurations in MetacelloRepository, a >> new version of the configuration should be copied into >> MetacelloRepository. >> >> Now that Metacello is more established, I don't think that it is >> critical to require that all configurations be copied to >> MetacelloRepository. >> >> It still is useful to have a sort of clearinghouse for >> configurations and until a better solution comes along it serves >> that purpose. BTW, I think Stef has plans to provide better >> solutions for Pharo... >> > I understand what you are saying and I partially agree. But it just > doesn't feel right and this is easy to show. In this example of > ConfigurationOfXMLSupport there was not one caring person like you > are that does everything and has on overview. There is a > Configuration in MetacelloRepository than it was decided to keep the > main Configuration file in XMLSupport repository. Development took > place in the XMLSupport repository. In the meantime someone changed > the Configuration in MetacelloRepsository probably for integration > purposes. Now the Configuration has been copied from XMLSupport and > has overwritten the changes that have been made to the existing > Configuration. That is what you get if you branch off things. > > I don't know how to solve this properly because I didn't have time > to follow the metacello discussions. But if there is a possibility > to specify the stable for pharo 1.1.1 that doesn't change even if > the packages evolves I can't see much reason to have a writable > version of the Configuration in MetacelloRepository. > > Norbert I understand that there are potential problems using distributed version control, but one of the reasons that I chose to use code for specifying Metacello configurations is thatit made it possible to use Monticello merge facilities to reconcile changes mad in different branches ... This was a breakdown in procedure ... the intent of MetacelloRepository is not to create branches of configurations...if I recall, there was a change in the developers that coincided with the creation of metacello configurations ... I would hope that this case be classed as a learning experience rather than a condemnation of process. I agree that there could be a better way, but I think that the better way involves tools support and until we get the tools we must resort to process ... Dale >> >> >> On 01/19/2011 06:12 AM, laurent laffont wrote: >>> On Wed, Jan 19, 2011 at 2:49 PM, Norbert Hartl<norbert(a)hartl.name >>> <mailto:norbert@hartl.name>> wrote: >>> >>> >>> On 19.01.2011, at 14:30, laurent laffont wrote: >>> >>>> On Wed, Jan 19, 2011 at 1:37 PM, Norbert >>>> Hartl<norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >>>> >>>> It depends where you look at. ConfigurationOfXMLSupport exists >>>> in MetacelloRepository as well as in XMLSupport. The latter >>>> one being the official one, the former one being very outdated. >>>> My sugesstion would be to remove ConfigurationOfXMLSupport >>>> from MetacelloRepository to lower the confusion. >>>> >>>> >>>> Personnally I always look in MetacelloRepository, this should >>>> be the reference IMHO. >>>> >>> Laurent, >>> >>> I think it is up to the maintainers where to put those files. >>> And in the XMLSupport case the decision was made deliberately not >>> to put it in MetacelloRepository but in XMLSupport. The only >>> thing I want to avoid is having multiple different files floating >>> around that are edited in an inconsistent way. >>> >>> >>> I thought that all ConfigurationOfXXX working for Pharo should >>> be put in MetacelloRepository so we have a central place to look >>> at. >>> >>> But I may be wrong. Mariano ? Dale ? >>> >>> Laurent >>> >>> >>> Norbert >>> >>>> >>>> Norbert >>>> >>>> On 19.01.2011, at 13:18, Tudor Girba wrote: >>>> >>>>> The last version 1.1.6 is marked as #release. >>>>> >>>>> Cheers, Doru >>>>> >>>>> >>>>> On 19 Jan 2011, at 12:26, laurent laffont wrote: >>>>> >>>>>> I put ConfigurationOfXMLSupport version 1.0 because >>>> blessing was #release. But I agree to change. >>>>>> >>>>>> Laurent >>>>>> >>>>>> On Wed, Jan 19, 2011 at 12:15 PM, Marcus Denker >>>> <marcus.denker(a)inria.fr<mailto:marcus.denker@inria.fr>> wrote: >>>>>> >>>>>> On Jan 19, 2011, at 11:43 AM, Tudor Girba wrote: >>>>>> >>>>>>> Indeed, this is a problem for Moose in general. We >>>>>>> depend >>>> on XMLSupport, but now we cannot update it in PharoDev. I >>>> would also strongly support the idea of removing XMLSupport >>>> from PharoDev. >>>>>>> >>>>>> >>>>>> What would be important: we need the latest version in >>>> Pharo 1.2... else how can we ever have a version where the >>>> tests are green? >>>>>> (not of XML, but in general) >>>>>> >>>>>> Marcus >>>>>> >>>>>>> Cheers, Doru >>>>>>> >>>>>>> >>>>>>> On 19 Jan 2011, at 11:32, Fabrizio Perin wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have a problem with the XMLSupport version from >>>>>>>> Pharo 1.2. >>>>>>>> >>>>>>>> The problem is that I need to work with one of the >>>>>>>> last >>>> version of XMLSupport but in the pharo image 1.2 is loaded an >>>> old version of XMLSupport (I mean a version from Jan 2010). I >>>> did try to load a newer version of XMLSupport using >>>> ConfigurationOfXMLSupport but some errors make this operation >>>> impossible. >>>>>>>> So either Pharo-dev 1.2 load a newer (possibly the >>>>>>>> last) >>>> version of XMLSupport by default or Pharo-dev 1.2 should not >>>> load XMLSupport at all. >>>>>>>> >>>>>>>> I think that doesn't make sense to use by default such >>>>>>>> an >>>> old version, also considering that the last XMLSupport has >>>> nice and useful features like the XMLPluggableElementFactory. >>>>>>>> >>>>>>>> By avoiding to load XMLSupport in Pharo-dev 1.2 by >>>> default you let people free to use the version that they like. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Fabrizio >>>>>>>> >>>>>>> >>>>>>> -- www.tudorgirba.com<http://www.tudorgirba.com/> >>>>>>> >>>>>>> "We cannot reach the flow of things unless we let go." >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- Marcus Denker -- http://www.marcusdenker.de >>>> <http://www.marcusdenker.de/> >>>>>> INRIA Lille -- Nord Europe. Team RMoD. >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- www.tudorgirba.com<http://www.tudorgirba.com/> >>>>> >>>>> "If you interrupt the barber while he is cutting your hair, >>>>> you will end up with a messy haircut." >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> > >

Jan. 20, 2011

Re: [Pharo-project] Issue 3527 in pharo: Please add the following Generator code to Pharo. I need it to port a package I am writing from Squeak to Pharo

by pharo＠googlecode.com

Comment #2 on issue 3527 by rpbol...(a)gmail.com: Please add the following Generator code to Pharo. I need it to port a package I am writing from Squeak to Pharo http://code.google.com/p/pharo/issues/detail?id=3527 I thought I had attached two files. Be that as it may I have attached the generator file again below Attachments: Generator.st 3.7 KB

Jan. 20, 2011

[Pharo-project] Hapao for Test coverage!

by Vanessa PeÃ±a

<pharo-project(a)lists.gforge.inria.fr>Hello all, We are happy to introduce you Hapao, an innovative test coverage tool which gives you an intuitive graphical representation to visually assess the quality of the coverage. For more information and download you can visit us at: http://hapao.dcc.uchile.cl/ Of course, all feedback is always welcome :) Have fun! The Hapao Team.

Jan. 20, 2011

[Pharo-project] Issue 3562 in pharo: Deferred UI messages executed slowly

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3562 by richi.mo...(a)gmail.com: Deferred UI messages executed slowly http://code.google.com/p/pharo/issues/detail?id=3562 Pharo1.2rc1 Latest update: #12313 Processing deferred ui messages seems to be really slow. You can test it by executing this: | rnd | rnd := Random new. 100 timesRepeat: [ WorldState addDeferredUIMessage: [ Morph new openInWorld; center: rnd next @ rnd next * Display extent. ] ]. You'll notice it takes a couple of seconds to finish opening all the morphs, but if you remove the #addDeferredUIMessage: send, it is instantaneous. In Squeak and Etoys both versions are equally fast. I think the bug is in WorldState>>#runStepsMethodsIn:. It seems it only executes one deferred ui message per step. With the implementation below the problem is fixed. WorldState>>#runStepMethodsIn: aWorld "Perform periodic activity inbetween event cycles" | queue nextInQueue| "If available dispatch some deferred UI Message" queue := self class deferredUIMessages. [(nextInQueue := queue nextOrNil) isNil] whileFalse: [ nextInQueue value]. self runLocalStepMethodsIn: aWorld.

Jan. 20, 2011

Re: [Pharo-project] [squeak-dev] Re: Kinect and Etoys

by Ricardo Moran

Ok, no problem. On Thu, Jan 20, 2011 at 1:49 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > can you add an entry to > http://code.google.com/p/pharo/issues/list > > ? > > thanks, > > Marcus > > On Jan 20, 2011, at 4:55 PM, Ricardo Moran wrote: > > I think I found the cause of the problem: I'm updating the position of each > morph inside a WorldState>>#addDeferredUIMessage:. In Pharo, this seems to > be really slow. You can test it by executing this: > > | rnd | > rnd := Random new. > 100 timesRepeat: [ > WorldState addDeferredUIMessage: [ > Morph new openInWorld; center: rnd next @ rnd next * Display extent. > ] > ]. > > You'll notice it takes a couple of seconds to finish opening all the > morphs, but if you remove the #addDeferredUIMessage: send, it is > instantaneous. In Squeak and Etoys both versions are equally fast. > > I looked at it a little, and I think Pharo has a bug in > WorldState>>#runStepsMethodsIn:. It seems it only executes one deferred ui > message per step. With the implementation below the problem is fixed. > > WorldState>>#runStepMethodsIn: aWorld > "Perform periodic activity inbetween event cycles" > | queue nextInQueue| > > "If available dispatch some deferred UI Message" > queue := self class deferredUIMessages. > [(nextInQueue := queue nextOrNil) isNil] > whileFalse: [ nextInQueue value]. > > self runLocalStepMethodsIn: aWorld. > > Best regards, > Richo > > On Wed, Jan 19, 2011 at 6:40 PM, Ricardo Moran <richi.moran(a)gmail.com>wrote: > >> The latest stable 1.1.1. I will look at it tomorrow and try to find out >> more. >> >> On Wed, Jan 19, 2011 at 6:38 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> hi ricardo, >>> >>> which version are you using? >>> >>> Stef >>> >>> On Jan 19, 2011, at 10:32 PM, Ricardo Moran wrote: >>> >>> > I forgot to say it works in Squeak and Pharo (although in Pharo it's >>> *painfully* slow, I don't know why yet...) >>> > >>> > Cheers >>> > Richo >>> > >>> > On Wed, Jan 19, 2011 at 6:04 PM, Ricardo Moran <richi.moran(a)gmail.com> >>> wrote: >>> > Hi guys! >>> > I want to tell you some exciting news. Thanks to the ESUG Innovation >>> Technology Awards we've been able to buy ourselves a Microsoft Kinect. We >>> don't have a Xbox 360 yet, but that doesn't mean we can't have a little fun >>> with it. Who needs and Xbox if you can use Kinect with Etoys? :) >>> > >>> > After seeing Stephen Howell's great work using Kinect with Scratch, we >>> followed his steps and made it available for Etoys as well. >>> > See it for yourselves: http://www.youtube.com/watch?v=YnqqaHvbeqg >>> > >>> > You can find installation steps in our blog: >>> http://tecnodacta.com.ar/gira >>> > >>> > Cheers! >>> > Richo >>> > >>> > >>> >>> >> > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

Jan. 20, 2011

Re: [Pharo-project] RPackage

by Alexandre Bergel

Excellent project to work on. Include PackageInfo in your scope :-) Alexandre On 20 Jan 2011, at 11:40, Cyrille Delaunay wrote: > By looking a bit more at Monticello, this is how I think it works (if not tell me): > > => WorkingCopy is the first kind of objects we have. A workingCopy has informations about version, ancestors, ... (surely a lot of other things) of a package and has a reference to a MCPackage > => a MCPackage does not know about the elements composing itself before calling the method MCPackage >> snapshot. This method will return a fresh MCSnapshot object. It is at this moment (I think), that monticello will use PackageInfo to retrieve all necessary informations. > => a MCSnapshot contains a kind of 'modelisation' of the system, which basically is a collection composed by: > => MCOrganizationDefinition, specifying what are the subcategories of the package > => MCMethodDefinition(s), one for each method included in the package (both defined and extension methods). > => MCClassDefinition(s), one for each class included in the package. > > So I think the point to focus on is, MCPackage >> snapshot, using the RPackage interface instead of PackageInfo interface to build the snapshot. I'm looking to do that. > > > > 2011/1/19 Cyrille Delaunay <cy.delaunay(a)gmail.com> > Hello, > Currently I am working on integrate RPackage in pharo, and having it working in parallel of PackageInfo. > What RPackage is already able to do (or at least until you find something wrong;)) is: > - synchronize and initialize with the current MCPackages in the system > - update itself when changes are made in the system (new category, new class, new method, ... ). > > Now I was wondering if there would be something to pay attention to with Monticello. Maybe when saving or importing packages to/from a repository? I don't know how monticello work, but after looking quickly, that's some thoughts I had: > > > > > > 1) => Saving from the image to a repository: How monticello know if the package we want to saved is extended by other classes? is there currently a link between Monticello and Package Info to do that? > 2) => import from a repository into the image: How do we manage to install the extension in the right package ? > > For the point 1) : > > MCPackageManager seems to directly listen to the system events (see MCPackageManager class >> reregisterForNotificationsWith:), in a parallel direction than RPackage (with its announcements system). So I guess Monticello update itself all its packages and check itself when a protocol is added to know if it's an extension. Therefore there would be nothing to worry when replacing PackageInfo by RPackage > > For the point 2) : > > When monticello will import the code, it will create classes, create methods in some protocols (that can be extensions or not), using the system interface. Then, Normally each modification will raise the corresponding event, for which RPackage is listening to (throught the announcement system). Therefore RPackage will update itself and there would be still nothing to worry. > > > For now the only link to make I see, is when creating or deleting a MCPackage: we have to do the same with the RPackages. This is currently done in RPackage, by listening to MC changes (look at RPackageOrganizer >> update:). PackageInfo is directly updated in the MC code instead of listening to changes. > > So I wonder if there is some big parts I totally forgot ? and In general if you have something in mind that should be done for RPackage? > > 2010/12/6 <csrabak(a)bol.com.br> > > I think this small thread is an excellent example of the need we have to implement simpler practice: > > When we announce a package or project, it would nice if the first paragraph[s] could be a short description of what it's all about! > > We could even open another thread and agree upon a format for it, and look, we could even have the same text in some specific attribute in the package which could be collected, selected, etc.!! > > -- > Cesar Rabak > > > Em 06/12/2010 07:08, Tudor Girba < tudor.girba(a)gmail.com > escreveu: > Good work, Cyrille! > > For people that might not know what RPackage is, this project aims to replace PackageInfo with a faster and cleaner implementation. At the moment, all categories are mapped one-to-one and in the end, we would like to remove class categories altogether. > > This infrastructure is also targeted to code browsers. > > Doru > > > On 6 Dec 2010, at 09:58, Cyrille Delaunay wrote: > > > Hello, > > > > Recently I made some improvements about RPackage. What I mainly did, is to implement the 'SystemAnnounncements listening', to update the organizer when the system change. With that I implemented a set of tests that should all be green now (in RPackageMCSynchronisationTest (I should change the name)). > > > > You can load RPackage by evaluating: > > > > Gofer new > > squeaksource: 'PharoInbox'; > > package: 'ConfigurationOfRPackage'; > > load. > > (Smalltalk at: #ConfigurationOfRPackage) perform: #loadDefault. > > > > (I think it should work, but squeaksource is down for now, so I was not able to test it). > > > > In those tests I started to write some about traits, but after few, I realized that the events emitted when a trait change are the same that the one used for classes ? > > Then if you have some ideas about what is still missing in RPackage, tell me, I can add it to my task list :) > > -- > www.tudorgirba.com > > "The coherence of a trip is given by the clearness of the goal." > > > > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 20, 2011

Re: [Pharo-project] [squeak-dev] Re: Kinect and Etoys

by Marcus Denker

can you add an entry to http://code.google.com/p/pharo/issues/list ? thanks, Marcus On Jan 20, 2011, at 4:55 PM, Ricardo Moran wrote: > I think I found the cause of the problem: I'm updating the position of each morph inside a WorldState>>#addDeferredUIMessage:. In Pharo, this seems to be really slow. You can test it by executing this: > > | rnd | > rnd := Random new. > 100 timesRepeat: [ > WorldState addDeferredUIMessage: [ > Morph new openInWorld; center: rnd next @ rnd next * Display extent. > ] > ]. > > You'll notice it takes a couple of seconds to finish opening all the morphs, but if you remove the #addDeferredUIMessage: send, it is instantaneous. In Squeak and Etoys both versions are equally fast. > > I looked at it a little, and I think Pharo has a bug in WorldState>>#runStepsMethodsIn:. It seems it only executes one deferred ui message per step. With the implementation below the problem is fixed. > > WorldState>>#runStepMethodsIn: aWorld > "Perform periodic activity inbetween event cycles" > | queue nextInQueue| > > "If available dispatch some deferred UI Message" > queue := self class deferredUIMessages. > [(nextInQueue := queue nextOrNil) isNil] > whileFalse: [ nextInQueue value]. > > self runLocalStepMethodsIn: aWorld. > > Best regards, > Richo > > On Wed, Jan 19, 2011 at 6:40 PM, Ricardo Moran <richi.moran(a)gmail.com> wrote: > The latest stable 1.1.1. I will look at it tomorrow and try to find out more. > > On Wed, Jan 19, 2011 at 6:38 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > hi ricardo, > > which version are you using? > > Stef > > On Jan 19, 2011, at 10:32 PM, Ricardo Moran wrote: > > > I forgot to say it works in Squeak and Pharo (although in Pharo it's *painfully* slow, I don't know why yet...) > > > > Cheers > > Richo > > > > On Wed, Jan 19, 2011 at 6:04 PM, Ricardo Moran <richi.moran(a)gmail.com> wrote: > > Hi guys! > > I want to tell you some exciting news. Thanks to the ESUG Innovation Technology Awards we've been able to buy ourselves a Microsoft Kinect. We don't have a Xbox 360 yet, but that doesn't mean we can't have a little fun with it. Who needs and Xbox if you can use Kinect with Etoys? :) > > > > After seeing Stephen Howell's great work using Kinect with Scratch, we followed his steps and made it available for Etoys as well. > > See it for yourselves: http://www.youtube.com/watch?v=YnqqaHvbeqg > > > > You can find installation steps in our blog: http://tecnodacta.com.ar/gira > > > > Cheers! > > Richo > > > > > > > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 20, 2011