[Pharo-project] looking for a job
Hello, I just finished my two years contract as engineer in the RMoD team with stephane and I am now looking for a job. I put below a short cv. If you are looking for a smalltalk developer, or know someone that is looking , feel free to contact me :) Experience = 2009--Present, Research Engineer, INRIA - RMoD team lead by Stephane Ducasse, Villeneuve d'Ascq, France. Development / Refactoring / Capitalization of the reengineering platform Moose (http://www.moosetechnology.org/) in the Pharo environment (Smalltalk, http://www.pharo-project.org/home). *User interface.* Improvement of the Moose user interface, implementation of a library for wizards generation, help for the integration of a new graphic library in Pharo. *Visualizations.* Implementation of several generic visualizations for code source analysis. *C analyzer.* Development and tests for C code import in Moose. Implementation of specific visualizations. *Java extractor.* Participation in the development of a new Java extractor based on eclipse JDT. *PHP extractor.* Implementation (in java) of a PHP extractor based on eclipse PDT . *Quality model.* Participation to the ANR project Squale (Software quality assessment). Integration/implementation of the ideas in Moose. *New Package system for Pharo.* Contribution (Implementation / System integration / Users update / Tests) to the development of a new Package system for Pharo. *Smalltalk-Java interaction.* Evaluation / Tests of libraries to manipulate Java objects from Smalltalk image (JNIPort, JavaConnect). *Meta-modeling. *Improvment and use of the meta-modeling infrastructure used in Moose (Fame). *Analysis reports.* Development of a library for analysis reports generation. *Web development.* Web interface for Moose (using Seaside). Conception of a dashboard (Like the one of Sonar). Skills summary *Visual Works*, 2 years. *Pharo*, 2 years. *Meta-modeling*, 2 years of experience as developer of the meta-described platform Moose. Use/Development of the meta-modeling infrastructure Fame ( http://scg.unibe.ch/wiki/projects/fame/). *Software Analysis*, 2 years of experience as developer/user of the software analysis platform Moose. Actif member of the community, good knowledge of scientific publications, books. Participation to numerous discussions around software analysis. *Software Quality*, Participation with the research team RMoD to the ANR project Squale (Software QUALity Enhancement). *Agile Developpement*, Strong knowledge gained during my studies and my 2,5 years of practice in the RMoD team. *Dynamic Web Development*, Experience in J2EE, .NET gained during my studies. Experience with Seaside (Smalltalk, http://www.seaside.st/) during my 2 years contract in the RMoD team. Education 2008-2009 Master professional IAGL (Engineering et Architecture of Large Softwares), University of Lille 1, Villeneuve d'Ascq, France. 2007-2008 Maitrise in computer sciences, University of Lille 1, Villeneuve d'Ascq, France. 2006-2007 Licence in computer sciences, University of Lille 1, Villeneuve d'Ascq, France. Computer skills Languages: Smalltalk, Java, C/C++, Prolog Web: Seaside, J2EE, ASP .NET IDE: Pharo, Eclipse, NetBeans OS: Mac OS, Linux, Windows Databases: MySQL, PostgreSQL Tools: LaTeX Languages French, Fluent, Native language. English, Intermediate, Read, spoken, written during my contract in the RMoD team (main language of the team).
[Pharo-project] Squeaksource down?
Hello, I am not able to connect to squeaksource
Re: [Pharo-project] changes with announcements ?
Ok, thank you henrik. So I understand well that the announcement delivery handler will recast in new thread. The point I do not get (and maybe its obvious, sorry in advance), is why does it raise an error ? When I look at the debugger, it seems that at one moment in the on:fork: method we got a 'context' that is nil whereas it should not. It is quite to understand what is problem (As I do not have a lot of knowledge around that) 2011/6/28 Henrik Johansen henrik.s.johan...@veloxit.no On Jun 28, 2011, at 10:23 56AM, Cyrille Delaunay wrote: I got another issue related to that i think. In moose , at one moment in a announcement handling code, we are doing: Notification signal: 'Save successful!'. That has for consequence that the on:fork: cuts the stack and I end up with a 'MessageNotUnderstood: receiver of sender is nil'. So I don't know if the problem is that we are signaling a notification? Yes, if nothing inside the announcement handling code handles it, it will get handled by the announcement delivery handler which recasts it in new thread, for the reason Igor mentioned below. It's not safe to simply pass it on for handling by the code that made the announcement, if you want to ensure delivery. if yes what should we use to notify something ? ... an Announcement? It was because on:fork: cuts the stack. If you signaling exception in your code, you should handle it before leaving your #actionSelector method. Otherwise you may put the rest recipients of announcement in danger and that's why there #on:fork: to prevent that. -- Best regards, Igor Stasenko AKA sig. Cheers, Henry
Re: [Pharo-project] changes with announcements ?
Igor this is the code you proposed: on: exception fork: handlerAction Activate the receiver. In case of exception, fork a new process, which will handle an error. An original process will continue running as if receiver evaluation finished and answered nil, i.e., an expression like: [ self error: 'some error'] on: Error fork: [:ex | 123 ] will always answer nil for original process, not 123. The context stack , starting from context which sent this message to receiver and up to the top of the stack will be transferred to forked process, with handlerAction on top. (so when forked process resuming, it will enter the handlerAction) ^ self on: exception do: [:ex | | copy onDoCtx process handler bottom thisCtx | onDoCtx := thisContext. thisCtx := onDoCtx home. find the context on stack for which this method's is sender [ onDoCtx sender == thisCtx] whileFalse: [ onDoCtx := onDoCtx sender. onDoCtx ifNil: [ ^ ex pass ] ]. bottom := [ Processor terminateActive ] asContext. onDoCtx privSender: bottom. handler := [ handlerAction cull: ex ] asContext. handler privSender: thisContext sender. (Process forContext: handler priority: Processor activePriority) resume. cut the stack of current process thisContext privSender: thisCtx. nil ] 2011/6/28 Igor Stasenko siguc...@gmail.com On 28 June 2011 11:43, Cyrille Delaunay cy.delau...@gmail.com wrote: Ok, thank you henrik. So I understand well that the announcement delivery handler will recast in new thread. The point I do not get (and maybe its obvious, sorry in advance), is why does it raise an error ? When I look at the debugger, it seems that at one moment in the on:fork: method we got a 'context' that is nil whereas it should not. It is quite to understand what is problem (As I do not have a lot of knowledge around that) What VM you using? Can you try running using other VM? 2011/6/28 Henrik Johansen henrik.s.johan...@veloxit.no On Jun 28, 2011, at 10:23 56AM, Cyrille Delaunay wrote: I got another issue related to that i think. In moose , at one moment in a announcement handling code, we are doing: Notification signal: 'Save successful!'. That has for consequence that the on:fork: cuts the stack and I end up with a 'MessageNotUnderstood: receiver of sender is nil'. So I don't know if the problem is that we are signaling a notification? Yes, if nothing inside the announcement handling code handles it, it will get handled by the announcement delivery handler which recasts it in new thread, for the reason Igor mentioned below. It's not safe to simply pass it on for handling by the code that made the announcement, if you want to ensure delivery. if yes what should we use to notify something ? ... an Announcement? It was because on:fork: cuts the stack. If you signaling exception in your code, you should handle it before leaving your #actionSelector method. Otherwise you may put the rest recipients of announcement in danger and that's why there #on:fork: to prevent that. -- Best regards, Igor Stasenko AKA sig. Cheers, Henry -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] How to know 'real' extent of a PanelMorph
I would like a method that always return something like the first result (from the first example) , whatever the 'extending stratgies' of the submorphs (in my two examples, both would return the 'first' result). 2011/5/30 Stéphane Ducasse stephane.duca...@inria.fr cyrille I was rereading your mail and I could not really understand what you are really looking for. Stef On May 20, 2011, at 3:34 PM, Cyrille Delaunay wrote: Hello, I have a panelMorph composed by several row/columns with different kind of morphs. What I would like to know is, what is the extent / size that I should use to FULLY display this panel (without scrollbars). Each time I ask for the extent of a panelMorph, it answers 50@40, whatever what is inside. If you openInWorld you will have something very very small. Is there a way to retrieve an extent with which the panel morph will be 'well' displayed (without having scrollbars everywhere)? In other words, what I really want to know is: Given two panelMorph, is there a way to say that one need more place than the other to be displayed?
Re: [Pharo-project] How to know 'real' extent of a PanelMorph
2011/5/31 Stéphane Ducasse stephane.duca...@inria.fr so I suggest that you just try to add optimalExtent based on minimal it does not seem that an existing method compute what you want. For me I still did not clearly get it. It seems that you want the potential space that a morph should occupy in the space of its container? Yes :) Stef On May 31, 2011, at 9:51 AM, Cyrille Delaunay wrote: I would like a method that always return something like the first result (from the first example) , whatever the 'extending stratgies' of the submorphs (in my two examples, both would return the 'first' result). 2011/5/30 Stéphane Ducasse stephane.duca...@inria.fr cyrille I was rereading your mail and I could not really understand what you are really looking for. Stef On May 20, 2011, at 3:34 PM, Cyrille Delaunay wrote: Hello, I have a panelMorph composed by several row/columns with different kind of morphs. What I would like to know is, what is the extent / size that I should use to FULLY display this panel (without scrollbars). Each time I ask for the extent of a panelMorph, it answers 50@40, whatever what is inside. If you openInWorld you will have something very very small. Is there a way to retrieve an extent with which the panel morph will be 'well' displayed (without having scrollbars everywhere)? In other words, what I really want to know is: Given two panelMorph, is there a way to say that one need more place than the other to be displayed?
[Pharo-project] squeaksource is down
Re: [Pharo-project] squeaksource is down
Yes it works fine now :) 2011/5/31 Fabrizio Perin fabrizio.pe...@gmail.com no is not 2011/5/31 Cyrille Delaunay cy.delau...@gmail.com
Re: [Pharo-project] How to know 'real' extent of a PanelMorph
Thanks gary. Indeed #minExtent give something interesting according the 'resizing strategy' of the submorphs (#rigid #spaceFill #shrinkWrap). If resizing of submorphs are #rigid, it works well. For example : |tmpPanelMorph| tmpPanelMorph := PanelMorph new changeTableLayout;hResizing: #shrinkWrap; vResizing: #shrinkWrap; listDirection: #leftToRight; yourself. tmpPanelMorph addMorphBack: ( (PluggableListMorph on: (ListModel new list: #(adededed ) ;yourself) list: #list selected: #selectionIndex changeSelected: #selectionIndex: ) hResizing: #rigid; vResizing: #rigid ; yourself) . tmpPanelMorph addMorphBack: ( (PluggableListMorph on: (ListModel new list: #(a b c d e f g h i j k l m n ) ;yourself) list: #list selected: #selectionIndex changeSelected: #selectionIndex: ) hResizing: #rigid; vResizing: #rigid ; yourself). tmpPanelMorph minExtent. The minExtent is 'correct'. Now if you try with: |tmpPanelMorph| tmpPanelMorph := PanelMorph new changeTableLayout;hResizing: #shrinkWrap; vResizing: #shrinkWrap; listDirection: #leftToRight; yourself. tmpPanelMorph addMorphBack: ( (PluggableListMorph on: (ListModel new list: #(adededed ) ;yourself) list: #list selected: #selectionIndex changeSelected: #selectionIndex: ) hResizing: #spaceFill; vResizing: #spaceFill ; yourself) . tmpPanelMorph addMorphBack: ( (PluggableListMorph on: (ListModel new list: #(a b c d e f g h i j k l m n ) ;yourself) list: #list selected: #selectionIndex changeSelected: #selectionIndex: ) hResizing: #spaceFill; vResizing: #spaceFill ; yourself). tmpPanelMorph minExtent. It answers something smaller. So I don't know if it would make sense to be able to retreive the same extent whatever the 'extending stratgies' of the submorphs ? Maybe another method that would always return this value (optimalExtent like you said) ? 2011/5/23 Gary Chambers gazzagu...@btinternet.com Try #minExtent, though that won't cater for things with scrollbars. Perhaps worth re-implementing #optimalExtent to deal with those. Regards, Gary - Original Message - *From:* Cyrille Delaunay cy.delau...@gmail.com *To:* pharo-project Pharo-project@lists.gforge.inria.fr *Sent:* Friday, May 20, 2011 2:34 PM *Subject:* [Pharo-project] How to know 'real' extent of a PanelMorph Hello, I have a panelMorph composed by several row/columns with different kind of morphs. What I would like to know is, what is the extent / size that I should use to FULLY display this panel (without scrollbars). Each time I ask for the extent of a panelMorph, it answers 50@40, whatever what is inside. If you openInWorld you will have something very very small. Is there a way to retrieve an extent with which the panel morph will be 'well' displayed (without having scrollbars everywhere)? In other words, what I really want to know is: Given two panelMorph, is there a way to say that one need more place than the other to be displayed?
[Pharo-project] changes with announcements ?
Hello, Today I experimented some strange behaviours with announcements that I didn't have in some previous moose images (moose in now based on Pharo 1.3). I think that there was some changes related to announcements in pharo recently, but I could not be sure it is related. At one point in my code I have: browser on: AnnouncementClass send: #actionSelector browser announce: anAnnouncementClass. The behaviour I have is like if #actionSelector was executed asynchronously from the rest of the code below 'browser announce: ...' . Not sure but there is maybe something with exception signals. If any signal is emited in #actionSelector it will not execute the rest of the method. I was at least able to write a test that do not pass in latest pharo 1.3 Gofer new squeaksource: 'DelaunayTmpStuffs'; package: 'ExampleAnnouncementProblems'; load.
Re: [Pharo-project] changes with announcements ?
I entered an Issue: http://code.google.com/p/pharo/issues/detail?id=4296 2011/5/27 Cyrille Delaunay cy.delau...@gmail.com Hello, Today I experimented some strange behaviours with announcements that I didn't have in some previous moose images (moose in now based on Pharo 1.3). I think that there was some changes related to announcements in pharo recently, but I could not be sure it is related. At one point in my code I have: browser on: AnnouncementClass send: #actionSelector browser announce: anAnnouncementClass. The behaviour I have is like if #actionSelector was executed asynchronously from the rest of the code below 'browser announce: ...' . Not sure but there is maybe something with exception signals. If any signal is emited in #actionSelector it will not execute the rest of the method. I was at least able to write a test that do not pass in latest pharo 1.3 Gofer new squeaksource: 'DelaunayTmpStuffs'; package: 'ExampleAnnouncementProblems'; load.
Re: [Pharo-project] bug in Nautilus/RPackage?
I don't know how to reproduce the situation in the screenshot, but I have a small idea of what the problem is: Your package Spy is composed of several subcategories. All the classes are defined in the subcategories but none is defined in the one called 'Spy'. In Rpackage, the classes are put inside the RPackage matching the category in which the class is defined 2011/5/19 Alexandre Bergel alexandre.ber...@me.com Thanks for making it happen :-) Alexandre On 19 May 2011, at 15:39, Stéphane Ducasse wrote: thanks for reporting it. do you have a reproducable way of arriving to this state? Hi ! I think I bumped into a bug when using Nautilus. I am not sure whether this is due to RPackage or not. I loaded Spy, and apparently there is no class in the package within Nautilus. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. Screen shot 2011-05-19 at 11.21.23.png -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
[Pharo-project] How to know 'real' extent of a PanelMorph
Hello, I have a panelMorph composed by several row/columns with different kind of morphs. What I would like to know is, what is the extent / size that I should use to FULLY display this panel (without scrollbars). Each time I ask for the extent of a panelMorph, it answers 50@40, whatever what is inside. If you openInWorld you will have something very very small. Is there a way to retrieve an extent with which the panel morph will be 'well' displayed (without having scrollbars everywhere)? In other words, what I really want to know is: Given two panelMorph, is there a way to say that one need more place than the other to be displayed?
[Pharo-project] RPackage not updated when adding a category
This is maybe related to SystemOrganizeraddCategory:before: which seems to never notify that a category has been added (whereas SystemOrganizeraddCategory: does it). I opened an issue : http://code.google.com/p/pharo/issues/detail?id=3974
Re: [Pharo-project] allOverriddenMethods is confusing
I think that this part of RPackage has just been copied from PackageInfo to work quickly with monticello. So for now RPackage deal with overriden methods in the same way than PackageInfo 2011/3/21 Henrik Johansen henrik.s.johan...@veloxit.no On Mar 20, 2011, at 9:48 31AM, Stéphane Ducasse wrote: So allOverriddenMethods returns all the methods of the complete system and it may be correct but strange to have it on the instance side. Probably for convenience, so you don't write self class allIOverriden... in methods like the one below. Now my hypothesis is that overriddenMethodsDo: aBlock Enumerates the methods the receiver contains which have been overridden by other packages ^ self allOverriddenMethodsDo: [:ea | (self isOverrideOfYourMethod: ea) ifTrue: [aBlock value: ea]] check the complete system for every package snapshot and since we have a lot of override because of polymorph we pay the price. I will fold the overrides first and try to understand mc Stef Yes, allOverridenMethods returns all overrides in the entire system. Another example of what you have to do when using categories for packaging :) To figure out the overridden methods in your package, it - Checks class category is not yours - Scans source for old category. Since .changes has been trunkated since Polymorph was merged, you won't find any packages whose methods are actually overridden by the Polymorph overrides :P Cheers, Henry PS. How does RPackage deal with overriden methods? PPS. I profiled this long ago, while it did show up, removing overrides didn't actually have a noticeable impact on the loading speed of Monticello
[Pharo-project] RPackage images
We have now an hudson job that build images with RPackage integrated and that run all the tests in the image: https://pharo-ic.lille.inria.fr/hudson/view/Pharo-TaskForces/job/Pharo%20RPackage%20All%20Tests/ Feel free to use it and report any problem. See also: http://code.google.com/p/pharo/issues/detail?id=3609q=RPackagecolspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty
Re: [Pharo-project] RPackage images
There is some comments in the classes RPackage and RPackageOrganizer. To load RPackage manually, there is a ConfigurationOfRPackage in www.squeaksource.com/PharoTaskForces 2011/2/15 Torsten Bergmann asta...@gmx.de Is there any documentation available on RPackage already? Or a help book? -- Schon gehört? GMX hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://www.gmx.net/de/go/toolbar
Re: [Pharo-project] RPackage
I opened an issue http://code.google.com/p/pharo/issues/detail?id=3609 2011/1/20 Alexandre Bergel alexan...@bergel.eu 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.delau...@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 csra...@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.gi...@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
Re: [Pharo-project] RPackage
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.delau...@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 csra...@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.gi...@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
Re: [Pharo-project] RPackage
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 csra...@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.gi...@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.
[Pharo-project] RPackage
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 :)
[Pharo-project] rename a method programatically
Hello, I would like to know how I can rename a method programatically and safelly (without missing to raise any event that has to be raised)
[Pharo-project] SystemOrganizer classify:under: to recategorized a class ?
Hello, I'm looking for the right way to move a class from a category to another category. When I do: Smalltalk organization classify: #AClassName to: #aCategoryName, it does the job. But when I do that, no event is emited to notify that the class has been moved. So I guess I'm using this method in a wrong way, is there another way to move a class from a category to another ? Or Should this method emit an event ?
[Pharo-project] Conflict between RPackage: ClassDescription package and BogusInfo class package
Hello, I'm currently testing RPackage. RPackage define the method 'package' in ClassDescription. In my image there's only one class that already define this method, it's BogusInfo. I don't know what is this class and what would be the best solution to solve this conflict
[Pharo-project] PluggableListMorphByItem getCurrentSelectionIndex access directly a non-initailized instance variable
In pharo 1.2, MorphicToolBuilderTests testGetListSelection raise an error. This error is caused by PluggableListMorphByItem getCurrentSelectionIndex, which looks like that: getCurrentSelectionIndex Answer the index of the current selection. | item | getIndexSelector == nil ifTrue: [^ 0]. item := model perform: getIndexSelector. ^ list findFirst: [ :x | x = item]. list is nil when runing the test. I guess that a better way is to use the accessor 'getList'. This method seems to make the correct initializations befor retrning the instance variable 'list'. When replacing by: getCurrentSelectionIndex Answer the index of the current selection. | item | getIndexSelector == nil ifTrue: [^ 0]. item := model perform: getIndexSelector. ^ self getList findFirst: [ :x | x = item]. The test pass. I opened an issue: http://code.google.com/p/pharo/issues/detail?id=3028 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] SystemVersionTesttestDowngrade use a deprecated method
The test SystemVersionTesttestDowngrade use SytemVersion version, which is deprected. It raise a warning when running the tests in a pharo 1.2 core image. I opened an issue: http://code.google.com/p/pharo/issues/detail?id=3025colspec=ID%20Type%20Status%20Summary%20Milestone%20Difficultystart=300 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] CodeMorph text should return an instance of Text but return a String
In pharo 1.2, NewTextMorphTests#testFullMethodName raise an error. This error happen when calling: CodeMorph defaultStyledText | text attribute | text := self text. text addAttribute: ( self newTextColorAttribute: Color black ). ^ text. text is a string, and therefore it does not understand 'addAttribute'. The value return by 'text' depends on the value of the instance variable 'adapter'. adapter can have different values according the way we initialize the CodeMorph. One of them is: beFullMethodName aspect := #selector. adapter := [:selector| target methodClass name , '.' , self selectorWithArguments ]. The block return a String and I guess the right code should be beFullMethodName aspect := #selector. adapter := [:selector| (target methodClass name , '.' , self selectorWithArguments) asText ] ??. I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=3031 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] CodeMorph text should return an instance of Text but return a String
I just saw that there is propositions to remove CodeMorph: http://code.google.com/p/pharo/issues/detail?id=2902q=CodeMorphcolspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty So maybe the best fix will be to remove all the tests related ? :) 2010/10/1 Cyrille Delaunay cy.delau...@gmail.com In pharo 1.2, NewTextMorphTests#testFullMethodName raise an error. This error happen when calling: CodeMorph defaultStyledText | text attribute | text := self text. text addAttribute: ( self newTextColorAttribute: Color black ). ^ text. text is a string, and therefore it does not understand 'addAttribute'. The value return by 'text' depends on the value of the instance variable 'adapter'. adapter can have different values according the way we initialize the CodeMorph. One of them is: beFullMethodName aspect := #selector. adapter := [:selector| target methodClass name , '.' , self selectorWithArguments ]. The block return a String and I guess the right code should be beFullMethodName aspect := #selector. adapter := [:selector| (target methodClass name , '.' , self selectorWithArguments) asText ] ??. I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=3031 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] PharoCorePackageDependenciesTests make tests with packages not presents in pharo 1.2
Several tests from PharoCorePackageDependenciesTests raise errors because it specify packages not present in pharo 1.2: 'AST-Tests-Core' 'AST-Core' 'AST-Semantic' The error come from: referencesInPackageNamed: pkgNameAsString | pi | pi := PackageOrganizer default packageNamed: pkgNameAsString ifAbsent: [^ self]. The package is not found, therefore it returns 'self', later in the code we iterate on that 'self', it raise a DNU Message. Maybe rather that returning self, we should return a more explicit error so that we know directly where does the problem comes from? Anyway, I guess the main problem here is that the packages specified are not present in the image? I opened an issue:http://code.google.com/p/pharo/issues/detail?id=3033 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Base64MimeConverterTest#testOnByteArray raise an error
ByteArray base64Encoded is no longer defined in Pharo 1.2, but used in the test Base64MimeConverterTest#testOnByteArray. It raise a DNU message. I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=3027q=base64Encodedcolspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] ToolBuilderTeststestGetButtonSideEffects seems to be wrong
if you look at the code of ToolBuilderTeststestGetButtonSideEffects: testGetButtonSideEffects self makeButton. queries := IdentitySet new. self changed: #testSignalWithNoDiscernableEffect. self expectedButtonSideEffects do:[:sym| self assert: (queries includes: sym). queries remove: sym. ]. the variable queries is never fill in, therefore I don't understand how the assertion could pass. In pharo 1.2-12159 the test fail for the class MorphicToolBuilderTests for which 'expectedButtonSideEffects' return a non-empty collection (unlike ToolBuilderTests). I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=3038 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] PluggableShoutMorph okToStyle still make a reference to Preferences
PluggableShoutMorph okToStyle still make a reference to Preferences, which is no longer present in pharo 1.2. It generate problem when opening a debugger for example (which is a problem :)). I opened an issue: http://code.google.com/p/pharo/issues/detail?id=2905 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] PluggableShoutMorph okToStyle still make a reference to Preferences
When I look at http://www.squeaksource.com/shout, It seems that I have the last version of the package 'Shout'. Am I looking at the right place ? 2010/9/3 Lukas Renggli reng...@gmail.com Not if you use the latest version. I fixed that a long time ago. Lukas 2010/9/3 Cyrille Delaunay cy.delau...@gmail.com: PluggableShoutMorph okToStyle still make a reference to Preferences, which is no longer present in pharo 1.2. It generate problem when opening a debugger for example (which is a problem :)). I opened an issue: http://code.google.com/p/pharo/issues/detail?id=2905 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli 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] PluggableShoutMorph okToStyle still make a reference to Preferences
Thanks :) 2010/9/3 Lukas Renggli reng...@gmail.com 2010/9/3 Cyrille Delaunay cy.delau...@gmail.com: When I look at http://www.squeaksource.com/shout, It seems that I have the last version of the package 'Shout'. Am I looking at the right place ? http://source.lukas-renggli.ch/unsorted, but I committed the changes now to the official repository. Lukas -- Lukas Renggli 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] [OSProcess] Proposal for Pharo 1.2 compatibility
Hello, I would suggest to replace the two methods -- OSPRocess class platformName After Squeak version 3.6, #platformName was moved to SmalltalkImage ^ ((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk platformName]) current platformName OSPRocess class osVersion After Squeak version 3.6, #osVersion was moved to SmalltalkImage ^ ((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current osVersion -- by: - OSProcess class platformName ^ ((Smalltalk classNamed: 'OSPlatform') ifNil: [ (Smalltalk classNamed: 'SmalltalkImage') current ifNil: [^ Smalltalk platformName]]) platformName OSProcess class osVersion ^ ((Smalltalk classNamed: 'OSPlatform') ifNil: [ (Smalltalk classNamed: 'SmalltalkImage') current ifNil: [^ Smalltalk osVersion]]) osVersion to avoid deprecation messages when using it in Pharo 1.2. Does it looks good? I'm not able to publish on the squeaksource repository ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] FSPlatformResolver classforCurrentPlatform use a deprecated method
In the package Filesystem, FSPlatformResolver class forCurrentPlatform | platformName | platformName := SmalltalkImage current platformName. ^ (self allSubclasses detect: [:ea | ea platformName = platformName]) new should be replaced by FSPlatformResolver class forCurrentPlatform | platformName | platformName := OSPlatform platformName. ^ (self allSubclasses detect: [:ea | ea platformName = platformName]) new ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FSPlatformResolver classforCurrentPlatform use a deprecated method
Yes, I naively repeated what was telling me the 'deprecated' message :) But indeed, use 'Smalltalk platformName' seems to work fine. 2010/9/3 Henrik Johansen henrik.s.johan...@veloxit.no A better choice might be Smalltalk os platformName, which works on Pharo 1.1, 1.2, Squeak 4.1 and 4.2. (well, as soon as it's properly undeprecated in 1.2 at least, #platform should be removed instead...) Cheers, Henry On Sep 3, 2010, at 2:30 23PM, Lukas Renggli wrote: Why? OSPlatform doesn't even exist in Pharo 1.1. Lukas 2010/9/3 Cyrille Delaunay cy.delau...@gmail.com: In the package Filesystem, FSPlatformResolver class forCurrentPlatform | platformName | platformName := SmalltalkImage current platformName. ^ (self allSubclasses detect: [:ea | ea platformName = platformName]) new should be replaced by FSPlatformResolver class forCurrentPlatform | platformName | platformName := OSPlatform platformName. ^ (self allSubclasses detect: [:ea | ea platformName = platformName]) new ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli 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] programmatically update a Pharo image
Both, updater and solution of yanni are doing what I was expecting. Thanks :) 2010/9/1 Stéphane Ducasse stephane.duca...@inria.fr Hi cyrille I published a read to be tested version of UpdateStreamer. Please have a look this is in PharoTaskForces/Updater I'm a little class inspired heavily from Utilities that download update.list and launch update. you can tell me to update throw a given number of update or to be verbose. UpdateStreamer new beVerbose; updateFromServer This will update all the updates available and show up dialogs UpdateStreamer new beSilent; upToNumber: 13000; updateFromServer let me know if this is working. I tested it and it seems so. Once we are a bit more confident :), we can use it in pharo and nuke (yeah) Utilities. 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] Metacello for pharo 1.2
Yes it seems to work, thanks :) 2010/9/1 Dale Henrichs dhenr...@vmware.com Mariano Martinez Peck wrote: Try (ConfigurationOfMetacello project version: '1.0-beta.27-baseline' ) load 2010/9/1 Cyrille Delaunay cy.delau...@gmail.com mailto: cy.delau...@gmail.com When I try to load moose in a pharo 1.2 image, Metacello is loading (via ConfigurationOfMetacello) an ancient version of OB which is no longer compatible with pharo 1.2 (at least for the use of 'Preferences'). Does anyone know if there is a version of metacello working for 1.2? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr mailto:Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ...Except that when you do that, you may get Metacello work in progress. I am working on 1.0-beta.27.4 right now and you could end up with code that I am attempting to debug which could lead to unexpected results for you:) If you load in a version of OmniBrowser that is compatible with 1.2, before loading the Metacello UI that should work ... A safer course of action would be to do this...load the latest packages from OmniBrowser and then the latest _released_ version of Metacello: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOmniBrowser'; package: 'ConfigurationOfMetacello'; load. then: (ConfigurationOfOmniBrowser project version: '1.1-baseline') load. (ConfigurationOfMetacello project latestVersion) load: 'UI'. You'll get an OmniBrowser that runs in 1.2 and the OB-Metacello tools. I've tried this and it appears to work fine... Dale ___ 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] [Moose-dev] Re: load moose in Pharo1.2
Now I have exactly the same problem with 'PluggableShoutMorph' in the package Shout (This package is loaded with ConfigurationOfPetitParser). PluggableShoutMorph (like MOEaselTextEditor) declare the two instance variables 'styler' and 'unstyledAcceptText' which are already declared in the superclass PluggableTextMorph (in Pharo 1.2). Maybe those variable have been integrated in the superclass for pharo 1.2 and are no longer usefull ? Anyone know? 2010/9/2 Alexandre Bergel alexan...@bergel.eu Strange indeed. This method is apparently never called. This is related somehow to the completion (which does not work for me. I will contact Lukas). Alexandre On 2 Sep 2010, at 08:22, Cyrille Delaunay wrote: What is strange, is that there is only one reference to unstyledAcceptText, without affecting it a value. 2010/9/2 Cyrille Delaunay cy.delau...@gmail.com No, same problem now with 'unstyledAcceptText' 2010/9/2 Tudor Girba tudor.gi...@gmail.com And does the loading work now? Doru On 2 Sep 2010, at 13:08, Cyrille Delaunay wrote: done 2010/9/2 Tudor Girba tudor.gi...@gmail.com Yes, please rename it to shoutStyler. Cheers, Doru On 2 Sep 2010, at 12:25, Cyrille Delaunay wrote: So that means that a 'styler' instance variable has been defined in PluggableTextMorph between pharo 1.1 and Pharo 1.2? Should we rename the Mondrian instance variable? 2010/9/2 Cyrille Delaunay cy.delau...@gmail.com So a solution is to load in a version of OmniBrowser that is compatible with 1.2, before loading moose: (ConfigurationOfOmniBrowser project version: '1.1-baseline') load. Now, I have another error: The class MOEaselTextEditor from Mondrian-Easel re-declare the instance variable 'styler', which is already defined in its superclass PluggableTextMorph. 2010/9/1 Lukas Renggli reng...@gmail.com Metacello is loading an ancient version of OB. References to Preferences have been removed a long time ago. However there is still a problem with the highlighting in Pharo 1.2. You only get a working environment if you do not load the package OB-Shout. Lukas On 1 September 2010 16:10, Tudor Girba tudor.gi...@gmail.com wrote: Hi Cyrille, That means that OB needs to be fixed :). Could you raise the issue on the pharo mailing list? Cheers, Doru On 1 Sep 2010, at 14:48, Cyrille Delaunay wrote: When I try with the configuration, I get an error when loading the class OBMercuryPanel (from the package OB-Standard, that seems to be loaded with ConfigurationOfMetacello): The initialize method is using the old class Preferences (that is no longer present in Pharo 1.2). 2010/9/1 Tudor Girba tudor.gi...@gmail.com What do you mean by script? Did you try with the configuration? Doru On Sep 1, 2010, at 11:12, Cyrille Delaunay cy.delau...@gmail.com wrote: Hello, Is moose loadable in Pharo 1.2 ? Is there a special script somwhere to that? ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com When people care, great things can happen. ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Lukas Renggli www.lukas-renggli.ch ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com When people care, great things can happen. ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com Being happy is a matter of choice. ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http
Re: [Pharo-project] [Moose-dev] Re: load moose in Pharo1.2
There is already an issue for that: http://code.google.com/p/pharo/issues/detail?id=2734q=PluggableShoutMorphcolspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty Should we (I) remove those variables from PluggableShoutMorph? 2010/9/2 Cyrille Delaunay cy.delau...@gmail.com Now I have exactly the same problem with 'PluggableShoutMorph' in the package Shout (This package is loaded with ConfigurationOfPetitParser). PluggableShoutMorph (like MOEaselTextEditor) declare the two instance variables 'styler' and 'unstyledAcceptText' which are already declared in the superclass PluggableTextMorph (in Pharo 1.2). Maybe those variable have been integrated in the superclass for pharo 1.2 and are no longer usefull ? Anyone know? 2010/9/2 Alexandre Bergel alexan...@bergel.eu Strange indeed. This method is apparently never called. This is related somehow to the completion (which does not work for me. I will contact Lukas). Alexandre On 2 Sep 2010, at 08:22, Cyrille Delaunay wrote: What is strange, is that there is only one reference to unstyledAcceptText, without affecting it a value. 2010/9/2 Cyrille Delaunay cy.delau...@gmail.com No, same problem now with 'unstyledAcceptText' 2010/9/2 Tudor Girba tudor.gi...@gmail.com And does the loading work now? Doru On 2 Sep 2010, at 13:08, Cyrille Delaunay wrote: done 2010/9/2 Tudor Girba tudor.gi...@gmail.com Yes, please rename it to shoutStyler. Cheers, Doru On 2 Sep 2010, at 12:25, Cyrille Delaunay wrote: So that means that a 'styler' instance variable has been defined in PluggableTextMorph between pharo 1.1 and Pharo 1.2? Should we rename the Mondrian instance variable? 2010/9/2 Cyrille Delaunay cy.delau...@gmail.com So a solution is to load in a version of OmniBrowser that is compatible with 1.2, before loading moose: (ConfigurationOfOmniBrowser project version: '1.1-baseline') load. Now, I have another error: The class MOEaselTextEditor from Mondrian-Easel re-declare the instance variable 'styler', which is already defined in its superclass PluggableTextMorph. 2010/9/1 Lukas Renggli reng...@gmail.com Metacello is loading an ancient version of OB. References to Preferences have been removed a long time ago. However there is still a problem with the highlighting in Pharo 1.2. You only get a working environment if you do not load the package OB-Shout. Lukas On 1 September 2010 16:10, Tudor Girba tudor.gi...@gmail.com wrote: Hi Cyrille, That means that OB needs to be fixed :). Could you raise the issue on the pharo mailing list? Cheers, Doru On 1 Sep 2010, at 14:48, Cyrille Delaunay wrote: When I try with the configuration, I get an error when loading the class OBMercuryPanel (from the package OB-Standard, that seems to be loaded with ConfigurationOfMetacello): The initialize method is using the old class Preferences (that is no longer present in Pharo 1.2). 2010/9/1 Tudor Girba tudor.gi...@gmail.com What do you mean by script? Did you try with the configuration? Doru On Sep 1, 2010, at 11:12, Cyrille Delaunay cy.delau...@gmail.com wrote: Hello, Is moose loadable in Pharo 1.2 ? Is there a special script somwhere to that? ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com When people care, great things can happen. ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Lukas Renggli www.lukas-renggli.ch ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com When people care, great things can happen. ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com Being happy is a matter of choice. ___ Moose-dev mailing list moose-...@iam.unibe.ch
[Pharo-project] programmatically update a Pharo image
Hello, Is there a 'magic' command to programmatically update and load the last version of a Pharo 1.2 core image? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] programmatically update a Pharo image
Ok, thanks :) The problem now is that 'Utilities updateFromServer' open a window to inform the user, waiting for the user to click on ok. In my case, I want to use such a method to update the image from a script (for example launched from hudson). But this 'inform' window stop the execution of the script 2010/9/1 Stéphane Ducasse stephane.duca...@inria.fr soon obsolete :) But for now ok :) soon UpdateStreamer new updateFromServer Hello, Is there a 'magic' command to programmatically update and load the last version of a Pharo 1.2 core image? ç Check Utilities updateFromServer ___ 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] programmatically update a Pharo image
Cool :) 2010/9/1 Stéphane Ducasse stephane.duca...@inria.fr cyrille I'm about to publish UpdateStreamer which will be silent or verbose and does what you want. Stef On Sep 1, 2010, at 2:54 PM, Cyrille Delaunay wrote: Hello, Is there a 'magic' command to programmatically update and load the last version of a Pharo 1.2 core image? ___ 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] Metacello for pharo 1.2
When I try to load moose in a pharo 1.2 image, Metacello is loading (via ConfigurationOfMetacello) an ancient version of OB which is no longer compatible with pharo 1.2 (at least for the use of 'Preferences'). Does anyone know if there is a version of metacello working for 1.2? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Question about about LintRule
Hello,
I'm currently looking a bit at how lint rules work. The current example I'm
looking at is:
RBTempVarOverridesInstVarRule
= this rule check for tmp variables that override an existing
instance variable in the class
= when such a case is detected, the result is stored like that:
result
addClass: aContext selectedClass
selector: aContext selector.
result addSearchString: varName.
= so, all variables are just stored one by one in a collection
('searchString') and never linked to the method in which the problem
happened.
What I wonder is: How are you able then to display, as result, a list of
method, and for each of them to highligth the 'problematic' tmp variable?
How do you make the the link between a class-selector from the result, and,
the variable name causing the problem for this selector?
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Pharo benchmarks ?
Hello, We are looking for any kind of benchmark in pharo, we would like to include such benchmarks in a reporting system for Pharo. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] new lint rule NoClassComment
A proposal for a new lint rule that detect classes with empty comment. Lukas could you include it to the next version of the refactoring browser ? http://code.google.com/p/pharo/issues/detail?id=2790 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]
Some news (sources at www.squeaksource.com/Athens): About having a first 'minimal' version, working with RomePluginCanvas and RomeReferenceCanvas, it seems to be ok. I retrieve the tests from Sophie and all are green. In romeDemo, I made a category with some working examples (using RomePluginCanvas and RomeRefrenceCanvas). However, There is still some primitive faillures for which I'm not able to do a lot of things: see for example RomeDemo class demoRotateWindow. Now about fonts, I thing the best is to rebuild all: a part of the code is using some Tweak specific classes, or other classes no longer present in Pharo. Morover I wonder why it is usefull to have a Rome-comon API for fonts (RomeFont), when pharo as already its own AbstractFont API ? fonts are just set to a canvas to draw strings. You can see an example using fonts in RomeDemo class demoRotateSophieLogo. From tweak, I only kept classes about CTransformCanvas, but I don't know what it is :) There is just a working example in RomeDemo. So maybe it could be removed (I think all the 'Athens-Tweak' category could be removed). So maybe at this point we could start to fix the API (?) 2010/5/24 Igor Stasenko siguc...@gmail.com On 24 May 2010 22:11, Stéphane Ducasse stephane.duca...@inria.fr wrote: Ok. Let me start. Excellent I want to learn. And I will ask cyrille to read all that. The first things is that we should get Rome working then we fix the api. Rome/Athens adds variouls extension methods to classes which are involved with graphics. Here is one of them: GradientFillStyleinstallOnRomePluginCanvas: aCanvas | colorStops i | colorStops := WordArray new: colorRamp size * 3. i := 0. colorRamp do: [:stop | colorStops at: (i:=i+1) put: (stop key * 65536.0) rounded. colorStops at: (i:=i+1) put: stop value privateRGB. colorStops at: (i:=i+1) put: stop value privateAlpha]. radial == true ifTrue: [ aCanvas primFillRadialGradientOriginX: origin x asFloat y: origin y asFloat directionX: direction x asFloat y: direction y asFloat normalX: self normal x asFloat y: self normal y asFloat colorStops: colorStops] ifFalse: [ aCanvas primFillLinearGradientOriginX: origin x asFloat y: origin y asFloat directionX: direction x asFloat y: direction y asFloat colorStops: colorStops] Good: - a conversion method is context sensitive (it takes a canvas as an argument) Bad: - this conversion method will work only for Rome plugin and nothing else. how to you see that? Well, consider this: colorRamp do: [:stop | colorStops at: (i:=i+1) put: (stop key * 65536.0) rounded. colorStops at: (i:=i+1) put: stop value privateRGB. colorStops at: (i:=i+1) put: stop value privateAlpha]. most likely, this will be inappropriate for anything else than RomePlugin. While, of course each kind of canvas could implement own #primFillLinearGradientOriginX: y:directionX: y: colorStops: except that it should not be a prim, and then it will waste time converting color stops again - into a form, which fits best for its own needs. So, why using 2 conversions, where 1 is enough? :) In same way, #asFloat may be not necessary, because canvas could accept integers as well as floats, so converting everything to floats is just a waste of time. This means, that if i'd want to use different canvas, i will need to add another method which will perform a conversion. you lost me there. But I ;m sure that you will explain it to me :) I meant that i would need to add the GradientFillStyleinstallOnRomeGLCanvas: aCanvas instead of reusing the code. But this can be avoided, if we provide a generic canvas method to create a gradient fills. Then this method could be renamed to #installOnRomeCanvas: and implementation will consist of messages, sent to canvas to build a gradient fill. do you have a sketch that I follow the example 100% GradientFillStyleinstallOnRomeCanvas: aCanvas ^ aCanvas cacheAt: self ifAbsentPut: [ aCanvas gradientFill: #linear origin: ... colors: ... ] and generally, a persistent resources (or ones which may change, but rarely) could use a following pattern: SomethinginstallOnRomeCanvas: aCanvas self isChanged ifTrue: [ aCanvas invalidateCache: self ]. ^ aCanvas cacheAt: self ifAbsentPut: [ aCanvas createSomething: ... ] Then, after heating-up, it will run at maximum efficiency by using a cached (and already converted resources) instead of performing conversions each
Re: [Pharo-project] [Moose-dev] rome
Hello, Indeed, I started to build a small package, integrating one by one things working in Rome. You can load it from the squeak source repository: www.squeaksource.com/Athens For now, the working canvas are: - RomePluginCanvas (making the binding with cairo) - RomeBalloonCanvas You can see some examples in the class side of RomeDemo. All is not working. You can have a look at RomeDemo demoMovingCar, that should work with the RomePluginCanvas and the RomeBalloonCanvas. All that concern fonts is not yet integrated, a lot of thing are already broken in the sophie dev image. So all examples drawing simple form, without text, should work. You can also have a look at the version of Alain plantec, from which I based the package Athens. This is already a condense version of all stuffs from the sophie image. You can load it from: www.squeaksource.source/PharoTaskForces (load te last version of 'Rome'). The next steps are: - Integrate fonts - The class RomeSVGDemo doesn't work 2010/5/17 Tudor Girba tudor.gi...@gmail.com Hi Cyrille, A bird told me that you are working on a Rome plugin. What is the status? Could we test something? :) Cheers, Doru -- www.tudorgirba.com The coherence of a trip is given by the clearness of the goal. ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Unknown variable in CodeMorph
Hello, The method CodeMorph stylerClass returns 'SHTextStylerST80', which is not defined. I opened an issue: http://code.google.com/p/pharo/issues/detail?id=2373 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Strange bug
Hello, Last week I had a error due to a strange behaviour: I had an instance variable and an accessor to this instance variable. The instance variable is instanciated at the initialization of the class. When the error occure, the instance variable is not nil (when inspecting it from the debugger ). But, when evaluating the accessor, it return nil. This occure in the pharo 1.0 dev image. I test it this morning on a clean image and on a click image with moose. It seems that the bug is specific to moose. If you want to reproduce it: Download the last version of Merlin from www.squeaksource.com/DelaunayTmpStuffs. run the method MerlinExamples class parametrizedMorphDropLists. it should work correctly. Now restart, load moose (load ConfigurationOfMoose, and evaluate 'ConfigurationOfMoose loadDefault') and then load Merlin from 'DelaunayTmpStuffs'. It should raise an error and you should be able to see this strange behaviour. From the debugger, evaluate 'self dropList' in MorphDropListPart. After showing this bug to Marcus, it seems that something is not weel compiled at one point: browse the method 'dropList' in dropListPart. Now, click on 'view' and 'byte code'. The offset indicated is 10 whereas it should be 15 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] how to control a TabGroupMorph ?
Hello, I would like to make a specific action when selecting a page of a tabGroupMorph. After looking a bit, I didn't find an easy way to do that. Usually, to control a morph, for example a DropListMorph, I use the class defining the dropList as Model, and therefore implement myself a #selectionIndex: method that does what I want to do. For TabGroupMorph I have the impression that there is not the possibility to set such a model and deal with #setSelector #getSelector mechanism. Am I wrong? The solution I use for now is to define my own subclass of TabGroupMorph to make my specific actions, which doesn't look very nice. As you know much more than me, How would you do that ? I probably miss something, but if there is effectively no easy way to control a TabGroupMorph, wouldn't it be a good thing to implement such a mechanism? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] we need help for rome
Ok, it works when adding the instance variables:) Thank you 2010/4/19 Stéphane Ducasse stephane.duca...@inria.fr probably :) one coming from sophie and one coming from the repository. We will fix that as soon as we can make it run on mac (ok we just have to add the inst var) but would be nice to have a clean plugin but I imagine that john is stressed with the Scratch problem. Stef On Apr 19, 2010, at 8:44 AM, Alain Plantec wrote: Stéphane Ducasse a écrit : Thanks john oops I learned something. Now the problem is that I did not touch them. I just loaded code. So I wonder where they got lost or changed. Alain do you have the same in your image? Hi all, Just back from a cool week-end, with a lot of sun... Yes, my RomePluginCanvas is the same as yours and it runs well on linux. But I've not removed any inst var myself. My version comes from the www.squeaksource.com/Rome. I've checked, and the RomePluginCanvas from squeaksource is still the same as mine: RomeCanvas subclass: #RomePluginCanvas instanceVariableNames: 'handle target flags strokeColor stack font fontSize fontMatrix' classVariableNames: 'FlagFill FlagStroke Registry' poolDictionaries: '' category: 'Rome-PluginCanvas' so, does it means that there are also two version of the plugin ? Cheers Alain Stef On Apr 17, 2010, at 4:09 AM, John M McIntosh wrote: (a) In Sophie RomeCanvas subclass: #RomePluginCanvas instanceVariableNames: 'handle target flags strokeColor stack font fontSize fontMatrix currentFillColor currentBackColor glyphAccuracy cachedGlyphBlt cachedClearBlt drawRunPositions drawRunGlyph drawRunPointY' classVariableNames: 'CachedTarget FlagFill FlagStro (b) In Pharo RomeCanvas subclass: #RomePluginCanvas instanceVariableNames: 'handle target flags strokeColor stack font fontSize fontMatrix' classVariableNames: 'FlagFill FlagStroke Registry' poolDictionaries: '' category: 'Rome-PluginCanvas' Comment warning: INST VAR ORDER IS KNOWN TO PLUGIN! DO NOT REARRANGE! So in the plugin we have... if (interpreterProxy-slotSizeOf(canvasOop)) CanvasInstSize) fail(). where CanvasInstSize is 13 but as you see in (b) the number of instance slots for the canvas Oops is 8. 8 13, oops you fail. So where did the instance vars currentFillColor currentBackColor glyphAccuracy cachedGlyphBlt cachedClearBlt go? On purpose gone, refactored, old code. etc On 2010-04-16, at 1:37 PM, Stéphane Ducasse wrote: On Apr 16, 2010, at 10:30 PM, John McIntosh wrote: Well I'm just as puzzled as you since the primitive gets executed and you are using the same binary that was shipped with Sophie years back. I like to hear that because I feel less idiot. :) ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Rome and Rome plugin
RomePlugin is present in none of listLoadedModules and listBuiltinModules 2010/4/14 Stéphane Ducasse stephane.duca...@inria.fr Hi mike and john We started to play with Rome with cyrille. Alain published a version that he started to clean in the Miro repository on squeaksource and we got the following behavior When we tried the car demo with sophie dev it works When we tried the car demo on the latest untable on mac with 4.2.2 it does not work we get a RomePlugin primitive Apparently it works with alain on linux Now if we take the sophie image and execute it with 4.2.2 it works. So do you have any idea how to fix that? Cyrille can you execute Smalltalk listLoadedModules SmalltalkImage listBuiltinModules 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] browse hierarchyImplementors raise an error
Hello, In a Pharo-1.0-10515-rc3 image, In the standard class browser, when you click on the green arrow at the left of a method, to browse hierarchyImplementor, an error occur. I opened an issue: http://code.google.com/p/pharo/issues/detail?id=2305 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Automatic generation of abstract methods
Hello, Would it be difficult to generate automatically superclass-abstract methods (with an empty contents) when creating a new subclass? For example, imagine I want to make my own subclass of Collection. As there is a lot of methods in this class and probably abstract methods, it would be cool to see them directly in my subclass without having to look to Collection method one by one (?). I'm probably not the first to ask this question, but in case it is, that's done:) ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: Tools to format source code ?
Yes, it works. Thank you 2010/4/3 Mariano Martinez Peck marianop...@gmail.com there was a problem in the OB of previous Pharo images. Now it is fixed. So...with RC3 or RC4 it should work for sure. If it is not, please report. Cheers Mariano 2010/4/2 Laval Jannik jannik.la...@gmail.com Argh, we try format, but it does not work. Maybe a special charater I don't know. Jannik On Apr 2, 2010, at 17:15 , Mariano Martinez Peck wrote: I think I don't understand. Select a method, right button, format. 2010/4/2 Stéphane Ducasse stephane.duca...@inria.fr :) Begin forwarded message: *From: *Cyrille Delaunay cy.delau...@gmail.com *Date: *April 2, 2010 1:11:00 PM GMT+02:00 *To: *Stéphane Ducasse stephane.duca...@inria.fr *Subject: **Tools to format source code ?* Hello, I would like to know if there is a way, a tool to format source code in Pharo. Or does anyOne have already implement something that I could retrieve and use ? It would be cool :) (Because format manually code imported from VW can really be horrible) ___ 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 ___ 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] bug in the code of CompiledMethod =
try in a Pharo-1.0-10515-rc3 image : |set| set := Set new. Collection withAllSubclasses do: [:aClass | set addAll: aClass methods ]. It will raise an exception telling: MessageNotUnderstood: ByteSymbolanalogousCodeTo:. Indeed, in the code of CompiledMethod = , the message 'analogousCodeTo:' is send to a symbol. I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=2185 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Problems using java code importer with inFusion under windows
The command send to OSProcess is a Unix-specific command .This command generate the mse file usimg the '.sh' file from inFusion. The solution add a condition, and use the .bat file (and the command line that come with ) if the OS is windows. 2010/2/18 Fabrizio Perin fabrizio.pe...@gmail.com Hi, i was using moose in windows and i had an error trying to use the function import from Java source with inFusion. Seems that OSProcess doesn't work properly. To reproduce the error just try to import java code using this function in the Moose panel in windows. In Mac i never had problem using that cool function. Anybody can help me to figure out where the problem is? Thanks in advance for the support, Fabrizio PS: Here the stack trace: --- The full stack --- UndefinedObject(Object)doesNotUnderstand: #nextPutAll: ExternalWindowsOSProcessvalue ExternalWindowsOSProcess classcommand: WindowsProcesscommand: WindowsProcesswaitForCommand: OSProcess classwaitForCommand: MooseImportFromJavaSourceFilesWizardvalidateImportation [] in MooseImportFromJavaSourceFilesWizardperformTerminateButtonAction [] in ProgressInitiationExceptiondefaultAction BlockClosureensure: ProgressInitiationExceptiondefaultAction UndefinedObjecthandleSignal: MethodContext(ContextPart)handleSignal: ProgressInitiationException(Exception)signal ProgressInitiationExceptiondisplay:at:from:to:during: ProgressInitiationException classdisplay:at:from:to:during: PSUIManager(MorphicUIManager)displayProgress:at:from:to:during: MooseImportFromJavaSourceFilesWizardperformTerminateButtonAction WizardLastPaneterminateButtonAction PluggableButtonMorphPlus(PluggableButtonMorph)performAction PluggableButtonMorphPlusperformAction [] in PluggableButtonMorphPlus(PluggableButtonMorph)mouseUp: Array(SequenceableCollection)do: PluggableButtonMorphPlus(PluggableButtonMorph)mouseUp: PluggableButtonMorphPlusmouseUp: PluggableButtonMorphPlus(Morph)handleMouseUp: MouseButtonEventsentTo: PluggableButtonMorphPlus(Morph)handleEvent: PluggableButtonMorphPlus(Morph)handleFocusEvent: [] in HandMorphsendFocusEvent:to:clear: [] in PasteUpMorphbecomeActiveDuring: BlockClosureon:do: PasteUpMorphbecomeActiveDuring: HandMorphsendFocusEvent:to:clear: HandMorphsendEvent:focus:clear: HandMorphsendMouseEvent: HandMorphhandleEvent: HandMorphprocessEvents [] in WorldStatedoOneCycleNowFor: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Array(SequenceableCollection)do: WorldStatehandsDo: WorldStatedoOneCycleNowFor: WorldStatedoOneCycleFor: PasteUpMorphdoOneCycle [] in Project classspawnNewProcess [] in BlockClosurenewProcess ___ 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] Monticello browser doesn't take into account a new package
Hi, I have try that with the last dev image on the pharo website: When I create a new package (right-click = add category on the default browser), this new package will not appear in the monticello browser. Therefore, you will not be able to save it in any squeaksource repository (?). The package will appear only after specific manipulations (for example, move a class from this new package to another one). ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Monticello browser doesn't take into account a new package
This is a Pharo1.0-10508-rc2dev10.01.2 image 2010/2/16 Cyrille Delaunay cy.delau...@gmail.com Hi, I have try that with the last dev image on the pharo website: When I create a new package (right-click = add category on the default browser), this new package will not appear in the monticello browser. Therefore, you will not be able to save it in any squeaksource repository (?). The package will appear only after specific manipulations (for example, move a class from this new package to another one). ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] roelTyper doesn't always return assignements
Hi, I'm trying to use RoelTyper in Pharo. A question I ask myself is: 'Is it normal that roelTyper doesn't always return some assignements' ? For example, when I evaluate: TypeCollector typeInstvar: #array ofClass: OrderedCollection . the assignements returned is an empty collection. I would expect that even roelTyper doesn't retrieve the exact type, it would always return a collection of 'candidate' types. Am I using it in a wrong way? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] roelTyper doesn't always return assignements
Ok, thank you very much :) 2009/12/10 Frederic Pluquet fpluq...@ulb.ac.be Oups... I answered too quickly ! It is not a bug :) ! As explain in this articlehttp://decomp.ulb.ac.be:9090/FrepSite/Papers/Fast%20Type%20Reconstruction%20for%20Dynamically%20Typed%20Programming%20Languages.pdf, we link the variables (temporary variables, instance variables and returned values of methods) during the extraction of types. The links permit to associate some varaibles between them. For example in *OrderedCollectiongrow Become larger. Typically, a subclass has to override this if the subclass adds instance variables. | newArray | newArray := Array new: self size + self growSize. newArray replaceFrom: 1 to: array size with: array startingAt: 1. array := newArray * RoelTyper links the temporary variable #newArray to the instance variable #array (because #newArray is assigned to #array). When you ask the extractedType by: * TypeCollector typeInstvar: #array ofClass: OrderedCollection. * the extractedType for #array contains the types assignements found for #array. And in the code, there are no one (no direct assignment of an object created by a message defined in the instance creation protocol of the class on which the message is sent (see the table of heuristics at the beginning of the page 4th of the paper)). But other linked extractedTypes has types assignements (as #newArray in OrderedCollectiongrow). So to retrieve this information in the extractedType of #array you must flatten the links (read the section 7 of the paper if you want more information), so: * (TypeCollector typeInstvar: #array ofClass: OrderedCollection) flattenLinks. * We don't flatten the links automatically because once flattened, the links are deleted from linked extractedTypes. We think it is important to keep this information available by default. The links are automatically flattened when you ask to calculate the possible types: * (TypeCollector typeInstvar: #array ofClass: OrderedCollection) types. * Fréd Frédéric Pluquet Université Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2009/12/10 fpluquet fpluq...@ulb.ac.be Hello Cyrille, First of all, thanks for trying to use RoelTyper! It is always interesting to have feedback ! There are two things. Firstly, you found a bug in RoelTyper :) RoelTyper should find some assignments for #array in OrderedCollection (in OrderedCollectiongrow for example). I must fix that. Secondly, RoelTyper found the right type for #array: Array! When you execute: * TypeCollector typeInstvar: #array ofClass: OrderedCollection.* it returns an ExtractedType (containing Assignments (normally :)) and Messages sends). To merge information and find the possible types for this extractedType you must send the message #types on it. *(TypeCollector typeInstvar: #array ofClass: OrderedCollection) types.* giving: Array Fréd Frédéric Pluquet Université Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2009/12/10 Cyrille Delaunay cy.delau...@gmail.com Hi, I'm trying to use RoelTyper in Pharo. A question I ask myself is: 'Is it normal that roelTyper doesn't always return some assignements' ? For example, when I evaluate: TypeCollector typeInstvar: #array ofClass: OrderedCollection . the assignements returned is an empty collection. I would expect that even roelTyper doesn't retrieve the exact type, it would always return a collection of 'candidate' types. Am I using it in a wrong way? ___ 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] Merlin: a library to build Wizards
Hi, Thanks for your comments. I have changed the default buttons to 'Next ' and ' Back'. I have not yet find how to fix the same size to all panes. For the moment I'm using a 'PluggableDialogWindow' that I open in a StandardWindow (StandardWindow new openModal: dialogWindow). Doing this, the pane is automatically resize according the elements of the dialogWindow. But indeed, it would maybe be more usefull for the user to click the next buttons one after the others without moving the moose according the resized pane. WizardPart is not so specific to the wizard hierarchy: - There is the two methods 'outputValue' and 'retrieveInputRequired' that make the link with a cooresponding wizard pane , but they are abstract methods. Therefore, you can retrieve the inputs in the way you want and make what you want with the output. - The other link is a kind of control for enabling the next button of the wizard pane. By default, it's an instance variable set to true, so you can not take care of that. A lot of subclasses of WizardPart I made don't retrieve any input and don't care about the next button. You can create instances and directly have the morph contents (with the method 'contents'). I agree for the LastPane. For example, in the addition, soustraction, ... wizard example, a LastPane could have been the selection of the last element of the operation, and after that we could have a pane that simply display the result (without any control). However, the first pane diplayed in a wizard will allways look like a FirstWizardPane (or maybe a customized version of it). 2009/11/23 Schwab,Wilhelm K bsch...@anest.ufl.edu If I understand you, that's not a good idea: the last pane in the sequence is not necessarily the last step in the wizard. I have examples in Dolphin that branch depending on user's choices along the way, and sometimes it reaches a close with additional panes remaining in the list, but those are for the road not taken. Bill -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto: pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of vicnet Sent: Monday, November 23, 2009 8:21 AM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Merlin: a library to build Wizards Hello, Cyrille Delaunay wrote: Just send this email to inform you that I have developed a small library ( called 'Merlin' ) that provide a simple structure to build Wizards. I test it. It is quit good. Just wondering why user have to say a pane is the first pane, dans another pane is the last. Could not the framework find it by itself ? The first one is a FirstPane and the last one when it is launch is a LastPane ? a+ Vicnet -- View this message in context: http://n2.nabble.com/Merlin-a-library-to-build-Wizards-tp4038238p4051036.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] Merlin: a library to build Wizards
Hi everybody, Just send this email to inform you that I have developed a small library ( called 'Merlin' ) that provide a simple structure to build Wizards. It is available on squeaksource at: http://www.squeaksource.com/Merlin. You will find a small example in the class side of 'WizardControl'. I have been making this library to build a Moose wizard that enable to select packages and some importations informations. Therefore, you can see this other example by loading Moose with: 'ConfigurationOfMoose loadDefault '. It will load all required classes. The Moose Wizard will be in the package Moose-Wizard. So, feel free to test it or use it if needed :) ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] problem with updating checkBoxes in morph
= this is a small exemple of my problem that you can run in your own image
(also available in the class side of UITheme by merging the
'Polymorph-Widgets' package in the PharoInBox repository) :
exampleProblemUpdatingCheckboxes
little example to show the problem with the method #on:send:to:with for a
CheckboxMorph :
In this example, when you click on the check box, all the other checkboxes
should be updated and selected.
This works when you click on the checkbox label BUT NOT on the checkbox
button.
self exampleProblemUpdatingCheckboxes
| builder dialog checkboxes |
checkboxes := OrderedCollection new.
builder := ExampleBuilderMorph new.
dialog := (builder newPluggableDialogWindow: 'Example :') useDefaultOKButton
.
dialog contentMorph: (
dialog newGroupboxForAll: {
checkboxes add:
(dialog newCheckboxFor:
(ValueHolder new contents: false)
getSelected: #contents
setSelected: #contents:
label: '1'
help: '').
checkboxes add:
(dialog newCheckboxFor:
(ValueHolder new contents: false)
getSelected: #contents
setSelected: #contents:
label: '2'
help: '').
checkboxes add:
(dialog newCheckboxFor:
(ValueHolder new contents: false)
getSelected: #contents
setSelected: #contents:
label: '3'
help: '').
}
); model: nil.
checkboxes do: [:each | each on: #click send: #updateCheckboxes:a:b: to:
self withValue: checkboxes ].
builder openModal: dialog.
= and the method :
updateCheckboxes: collectionOfCheckboxes a:a b:b
collectionOfCheckboxes do: [:each | each buttonMorph selected: true].
2009/10/6 Igor Stasenko siguc...@gmail.com
I'm a bit wonder, why you sending a #buttonMorph to checkbox morph,
trying to intercept
a messages?
As to me this is a wrong approach, because you as a user of checkbox,
should not care
about its internals, and speak directly with checkbox public layer ,
but not with its internal components.
2009/10/6 Cyrille Delaunay cy.delau...@gmail.com:
here is the code of the method creating the checkboxes:
checkBoxes := OrderedCollection new.
builder := ExampleBuilderMorph new.
dialog := (builder newPluggableDialogWindow: 'Context to import :')
useDefaultOKButton .
dialog contentMorph: (
dialog newRow: {
dialog newGroupboxForAll:
(self allContexts collect: [:each | (checkBoxes add: (dialog
newCheckboxFor:
(ValueHolder new
contents: (collectionWithItemsToCheck includes: each))
getSelected: #contents
setSelected: #contents:
label: each asString
help: '')
).
])
}
);
model: nil.
checkBoxes do: [:each | each on: #click send: #updateDependenciesFor:i:a:
to: self withValue: each label asString].
= That code make what I want when I click on the label, but with:
checkBoxes do: [:each | each buttonMorph on: #click send:
#updateDependenciesFor:i:a: to: self withValue: each label asString].
= nothing happen when I click on the checkbox button.
2009/10/6 Stéphane Ducasse stephane.duca...@inria.fr
can you send some text :)
On Oct 6, 2009, at 2:02 PM, Cyrille Delaunay wrote:
I join a screenshot of my code.
2009/10/6 Stéphane Ducasse stephane.duca...@inria.fr
cyrille
do you have a piece of code to illustrate your problem?
Let me rephrase our discussions:
you can get the associated checkbox event (set by
on: #click send: #amessage to: receiver) raised only
when you click on the label but not on the tick.
And that
checkbox buttonMorph on: #click send: #amessage to: receiver,
is not working on click
but checkbox buttonMorph on: #mouseDown send: #amessage to:
receiver,
is.
Stef
On Oct 6, 2009, at 12:08 PM, Cyrille Delaunay wrote:
Hi,
Here is what I want to do:
- I have checkbox: ChekboxMorph new
- A checkbox is made of a label and a button
- I want to do a specific action when there is a mouse click on the
button
For that:
- I saw that there is a method #on:send:to: in Morph with wich we
can do:
checkbox on: #click send: #amessage to: receiver
Problem:
- when I do
checkbox on: #click send: #amessage to: receiver,
all is ok.
- when I do
checkbox buttonMorph on: #click send: #amessage to:
receiver,
to consider the click on the button, it doesn't work, the event is
never handled (whereas #mouseDown for example is handled).
___
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
checkboxes.tiff___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo
Re: [Pharo-project] Examples for UITheme
Changes are for the package 'Polymorph-Widgets' in the inbox. 2009/10/7 Stéphane Ducasse stephane.duca...@inria.fr which file in the inbox? You see been more precise make sure that we are not losing time. Stef On Oct 2, 2009, at 4:32 PM, Cyrille Delaunay wrote: Hi, I have added comments to the UITheme classe description and into the examples methods, to evaluate directly the examples. I have saved that in 'PharoInBox' in squeaksource. ___ 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] problem with updating checkBoxes in morph
Hi, Here is what I want to do: - I have checkbox: ChekboxMorph new - A checkbox is made of a label and a button - I want to do a specific action when there is a mouse click on the button For that: - I saw that there is a method #on:send:to: in Morph with wich we can do: checkbox on: #click send: #amessage to: receiver Problem: - when I do checkbox on: #click send: #amessage to: receiver, all is ok. - when I do checkbox buttonMorph on: #click send: #amessage to: receiver, to consider the click on the button, it doesn't work, the event is never handled (whereas #mouseDown for example is handled). ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] problem with updating checkBoxes in morph
here is the code of the method creating the checkboxes:
checkBoxes := OrderedCollection new.
builder := ExampleBuilderMorph new.
dialog := (builder newPluggableDialogWindow: 'Context to import :')
useDefaultOKButton .
dialog contentMorph: (
dialog newRow: {
dialog newGroupboxForAll:
(self allContexts collect: [:each | (checkBoxes add: (dialog
newCheckboxFor:
(ValueHolder new
contents: (collectionWithItemsToCheck includes: each))
getSelected: #contents
setSelected: #contents:
label: each asString
help: '')
).
])
}
);
model: nil.
checkBoxes do: [:each | each on: #click send: #updateDependenciesFor:i:a:
to: self withValue: each label asString].
= That code make what I want when I click on the label, but with:
checkBoxes do: [:each | each buttonMorph on: #click send:
#updateDependenciesFor:i:a: to: self withValue: each label asString].
= nothing happen when I click on the checkbox button.
2009/10/6 Stéphane Ducasse stephane.duca...@inria.fr
can you send some text :)
On Oct 6, 2009, at 2:02 PM, Cyrille Delaunay wrote:
I join a screenshot of my code.
2009/10/6 Stéphane Ducasse stephane.duca...@inria.fr
cyrille
do you have a piece of code to illustrate your problem?
Let me rephrase our discussions:
you can get the associated checkbox event (set by
on: #click send: #amessage to: receiver) raised only
when you click on the label but not on the tick.
And that
checkbox buttonMorph on: #click send: #amessage to: receiver,
is not working on click
but checkbox buttonMorph on: #mouseDown send: #amessage to:
receiver,
is.
Stef
On Oct 6, 2009, at 12:08 PM, Cyrille Delaunay wrote:
Hi,
Here is what I want to do:
- I have checkbox: ChekboxMorph new
- A checkbox is made of a label and a button
- I want to do a specific action when there is a mouse click on the
button
For that:
- I saw that there is a method #on:send:to: in Morph with wich we
can do:
checkbox on: #click send: #amessage to: receiver
Problem:
- when I do
checkbox on: #click send: #amessage to: receiver,
all is ok.
- when I do
checkbox buttonMorph on: #click send: #amessage to:
receiver,
to consider the click on the button, it doesn't work, the event is
never handled (whereas #mouseDown for example is handled).
___
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
checkboxes.tiff___
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] Examples for UITheme
It's done :) 2009/10/2 Marcus Denker den...@acm.org On 02.10.2009, at 10:32, Cyrille Delaunay wrote: Hi, I have added comments to the UITheme classe description and into the examples methods, to evaluate directly the examples. I have saved that in 'PharoInBox' in squeaksource. Can you add an entry in the issue tracker for that? Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile ___ 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] need tests for DataStream
Hi, I wrote a new version of DataStream ( and its subclasses : ReferenceStream and SmartRefStream) in Nile and I would like to write tests for those classes. I would be very interested by anyone that has already write some tests for that. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] tests for FasterSets
Hi, I have saved some tests for A lot of subclasses of Dictionary and Set in 'PharoTaskForces'. Those tests only test basic behavior of a Set or a Dictionary. You will probably find errors and failures not due to fasterSets specificities : - uncommented classes - methods unclassified - class implementation bugs ( like smallDictionary . MethodDictionary ) - class specific behavior ( in this case, tests should maybe be rewriten). ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] problem mixing Traits and Inheritance
Hi, Here's my problem : - I have the class NSCollectionStream which define ( for example ) #atEnd - I have the class NSSubclassOfCollectionStream ( which is a suclass of NSCollectionStream). When I use a trait in NSSubclassOfCollectionStream that required the method #atEnd, the defintion in NSCollectionStream is not used and the method #atEnd is overridden with : atEnd self explicitRequirement. I think we should take care about definitions in superclass, no? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Tests
It's probably that.I just try to run the tests from FloatArray ( that was not tested at all before), it represent 251 tests. With all collections tested it seems possible that there is like 2000 new tests. 2009/7/6 Marcus Denker den...@acm.org On 05.07.2009, at 12:36, Adrian Lienhard wrote: Running the tests in the latest core (10371), I get the following results: 5154 run, 5133 passes, 2 expected failures, 17 failures, 2 errors Comparing to the last result in 10292cl [1]: 3029 run, 2956 passes, 2 expected failures, 24 failures, 47 errors I wonder how it is possible to get from 3029 to 5154 tests? I think this is because of the Traits-based test for Collections (written by Cyrille). Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile ___ 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] bugs with SmallDictionary #scanFor:
SmallDictionary, unlike all subclasses of Dictionary, never used ( and initialize ) the instance variable: 'array'.Associations are stored with a key array ( called 'keys' ) and a value array ( 'values' ). Problem is that the method #scanFor: is define in Dictionary ( and not overriden ) with this code : scanFor: anObject | element start finish | finish := array size. 'array' is nil and it cause bugs for those methods : - #includesAssociation: - #associationAt: - #associationAt:ifAbsent: - #associationDeclareAt: ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] creation of ReadWriteStream with #on:
Hi, ReadWriteStream inherits from WriteStream which hinerits from PositionableStream. When you create a ReadWriteStream with #on: you use the default definition in PositionableStream : PositionableStream class on: aCollection Answer an instance of me, streaming over the elements of aCollection. ^self basicNew on: aCollection #on: is not overriden in the instance side of ReadWriteStream and therefore it's the definition of WriteStream that is called : WriteStream on: aCollection super on: aCollection. readLimit := 0. writeLimit := aCollection size. Put the readLimit at 0 make sense for a WriteStream ( with witch your not supposed to read ) but when you create a ReadWriteStream on a collection you would be able to read what is already in the collection, no? I wonder why #on: has not been overriden in the instance side of ReadWriteStream ? Maybe it's not a good idea to create a ReadWriteStream with a collection that already includes elements ? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] creation of ReadWriteStream with #on:
With both of your answers I understand that there was a problem and apparently no good reason to have a ReadLimit set at 0.That was my question, thank you :) (anyway this problem should disapear when Nile will replace the actual Stream hierarchy ;)) 2009/6/30 Henrik Johansen henrik.s.johan...@veloxit.no Well, my point was that by copying that, you don't set writeLimit, so attempting to write to the ReadWriteStream results in an error... (which is why I gave a test that both reads and writes instead of just reading) In that case, what's the point? It's functionality is then just the same as a ReadStream. (Which is doubly confusing, seeing as it inherits from WriteStream) so doing it your way, we'd have to do: on: aCollection readLimit := aCollection size. writeLimit := aCollection size. position := 0. self reset. instead of a straight copy. Btw, your version has a dependency on the super as well, mainly that it defines the correct instvars. :) Which version to prefer comes down to taste, I guess. Cheers, Henry On Jun 30, 2009, at 3:54 35PM, Alexandre Bergel wrote: You haven't set the writeLimit by just copying PositionableStream though, have you? I suggested to copy PositionableStreamon: in ReadWriteStream: on: aCollection collection := aCollection. readLimit := aCollection size. position := 0. self reset Your implementation works well too, it has no duplication, but has a dependency over the implementation of the superclass. Cheers, Alexandre On Jun 30, 2009, at 3:00 46PM, Alexandre Bergel wrote: Put the readLimit at 0 make sense for a WriteStream ( with witch your not supposed to read ) but when you create a ReadWriteStream on a collection you would be able to read what is already in the collection, no? I wonder why #on: has not been overriden in the instance side of ReadWriteStream ? Maybe it's not a good idea to create a ReadWriteStream with a collection that already includes elements ? It looks like on: must be overridden in ReadWriteStream. With ReadStream I have: (ReadStream on: (1 to: 20)) next = 1 (ReadStream on: (1 to: 20)) next; next = 2 However, with ReadWriteStream, nil is returned, for the very problem you mentioned: (ReadWriteStream on: (1 to: 20)) next = nil If I cut and paste PositionnableStreamon: in ReadWriteStream, then I have the behavior I expected: (ReadWriteStream on: (1 to: 20)) next = 1 (ReadWriteStream on: (1 to: 20)) next; next = 2 Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] different behavior between Dictionary and MethodDictionary for #add:
Hi, I'm trying to test all subclasses of Dictionary and I just find a specific behavior for MethodDictionary : - #add: return the association that has been added except for SmallDictionary for which #add: return the value of the association. Is there a reason for such an implementaion? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] different behavior between Dictionary and MethodDictionary for #add:
Same problem with #removeKey:ifAbsent that doesn't return anything for MethodDictionary ( instead of the value of association removed). 2009/6/29 Cyrille Delaunay cy.delau...@gmail.com Hi, I'm trying to test all subclasses of Dictionary and I just find a specific behavior for MethodDictionary : - #add: return the association that has been added except for SmallDictionary for which #add: return the value of the association. Is there a reason for such an implementaion? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] different behavior between Dictionary and MethodDictionary for #add:
2009/6/29 Cyrille Delaunay cy.delau...@gmail.com Same problem with #removeKey:ifAbsent that doesn't return anything for MethodDictionary ( instead of the value of association removed). 2009/6/29 Cyrille Delaunay cy.delau...@gmail.com Hi, I'm trying to test all subclasses of Dictionary and I just find a specific behavior for MethodDictionary : - #add: return the association that has been added except for SmallDictionary for which #add: return the value of the association. *this is for MethodDictionary and not SmallDictionary Is there a reason for such an implementaion? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] #IdentityIncludes: for FloatArray
try to inspect: (FloatArray new:1)at: 1 put: 2.5 ; yourself and print: self identityIncludes: self anyOne It returns false. Is it a 'normal' comportment ? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] tests for Collection classes
Hello I'm Cyrille Delaunay, I work for the RMOD Inria team. I'm currently working on tests for the Pharo Collection Library using traits. I've modified, added some traits and therefore redifined things in test classes to attempt to get a best coverage. (For the moment : Arraytest , BagTest , DictionaryTest , IntervalTest , OrderedCollectionTest , SetTest , SortedCollectionTest StringTest , SymbolTest , LinkedListTest ). All modification have been saved in 'PharoTaskForces'. With a static coverage tool (also saved in PharoTaskPhorces ) removing noise for each class (methods defined too high in hierarchy that are not appropriated , private methods , very specific methods that may should not be tested for collection ), I got those coverage : Arraytest : tested at 94.5 % BagTest : 88.4 % DictionaryTest: 85 % IntervalTest : 93 % OrderedCollectionTest : 93.9% SetTest : 85.9% SortedCollectionTest : 92.3 % StringTest : 91% LinkedListTest : 90.5 % Here are the more important modifications i've made about traits : - new trait TConvertTest : testing converting methods (such that 'asArray,' asBag', .. ) - new trait 'TSortTrait' : testing sorting methods for 'ArrayedCollection'. -sort -sort: -isSorted -isSortedBy: - new trait: 'TCopySequenceable' : testing copying methods using an order, an index access (copyAfter: for example) - new trait 'TOccurrencesTest' : testing method : - OccurencesOf: - new trait: TIterateSequencedReadableTest' testing iterating methods using a specific order ( usable therefore only by sequenceable collection ) - new trait: 'TConcatenaionTest' Bad initial version (specific to sequenceable collection) Split into two trait: - TSequencedConcatenationTest (initial version) - TConcatenationTest (to do) - new trait: 'TReplacementSequencedTest' testing replacemnt methods : - replaceAll:with: - replaceFrom:to:with: - replaceFrom:to:with:startingAt: for Sequenced Collection - Modification of all the methods in 'TIndexAccessingTest' making them independent of elements in collection's Type.( so that it can be used with all type of sequenceable collection like 'String'). - - modification of all the tests in 'TAsStringAndDelimiterTest' making its independent of the elements' type in collection. 'TAsStringAndDelimiterTest' added to 'ArrayTest'. - redefinition of 'TAsStringCommaAndDelimiterTest' which were specific to sequenceable collection (and didn't work for 'BagTest'). The initial version has been kept in a new trait: 'TAsStringCommaAndDelimiterSequenceableTest'. - with new trait: 'TBeginsEndsWith' testing methods: - beginsWith: - endsWith: - Remodularisation of the initial trait 'TIndexAccessing' (which became to big) Split into three traits: - methods like 'indexOf' added to the New trait 'IndexAccess' . - methods concerning 'SubCollectionAccess' added to a new trait: 'TSubCollectionAccess'. - methods concerning elements access added to a new trait : 'TSequencedElementAccessTest' - new trait: 'TPrintTest' testing 'stream printing' methods Modification of TPrintTest wich was specific to sequenceable collections. Initial version has been kept in a new trait : TPrintSequencedTest - Modification of TConvertTest wich tested some methods (asSet, asIdentitySet) for duplicate contents what can't work for Interval or Collection without equel elements. Creation of a new trait : 'TConvertAsSetForMultiplinessTest'. - Remodularisation of TCopySequenceableTest wich were too big. Creation of a new trait : - TCopySequenceableSameContents testing copying methods that only change the order of elements and don't remove or add any elements to the copy. - TCopyPartOfSequenceable testing copying methods that only copy a part of a collection (copyAfter: copyUpTo: ) - TCopySequenceableWithOrWithoutSpecificElements testing copying methods ( from the initial trait TCopySequenceable ) that copy the collection with more or less specified elements . - 'TCopySequenceableWithReplacement' testing copying methods ( from the initial version of TSequenceableTest ) that copy and replace subcollections in the receiver. - Refinition of all tests in TIndexAccess so that they required a simple collection
[Pharo-project] run all tests from superClass
A change have been saved in 'PharoInBox' for class TestCase in package SUnit so that suite are now built from allSelectors. This makes sense when you have testcase classes which inherits from each other and have parametrized (hook-based) setup. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
