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

[Pharo-project] [update 1.3] #13024

by StÃ©phane Ducasse

13024 ----- - Repackaging a lot of classes and creating UI-Basic for Model and RealEstateAgent. Stef and Ben

Jan. 28, 2011

Re: [Pharo-project] RPackage

by Cyrille Delaunay

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

Jan. 28, 2011

[Pharo-project] Issue 3612 in pharo: Full Image uses wrong Theme

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.2-DevImage New issue 3612 by marcus.d...(a)gmail.com: Full Image uses wrong Theme http://code.google.com/p/pharo/issues/detail?id=3612 Full Image uses wrong Theme Should use Glamour Theme for 1.2

Jan. 28, 2011

Re: [Pharo-project] Issue 3611 in pharo: ParagraphEditor should be removed

by pharo＠googlecode.com

Updates: Summary: ParagraphEditor should be removed Cc: aplantec Comment #1 on issue 3611 by stephane...(a)gmail.com: ParagraphEditor should be removed http://code.google.com/p/pharo/issues/detail?id=3611 Am'I correct that we can soon get rid of paragraphEditor

Jan. 28, 2011

[Pharo-project] Issue 3610 in pharo: Should remove Morphic-Undo

by pharo＠googlecode.com

Status: Accepted Owner: stephane...(a)gmail.com CC: aplan...(a)gmail.com New issue 3610 by stephane...(a)gmail.com: Should remove Morphic-Undo http://code.google.com/p/pharo/issues/detail?id=3610 Alain is it correct that we could remove Command and CommandHistory now?

Jan. 28, 2011

[Pharo-project] Issue 3611 in pharo: ParagraphEditor deprecated in 1.2

by pharo＠googlecode.com

Status: Accepted Owner: stephane...(a)gmail.com New issue 3611 by stephane...(a)gmail.com: ParagraphEditor deprecated in 1.2 http://code.google.com/p/pharo/issues/detail?id=3611 If you fill an issue for the first time, please read "How to report bugs" at http://www.pharo-project.org/community/issue-tracking Pharo image: <core, dev or web> Pharo core version: <copy from World/System/About> Virtual machine used: <ex: pharo-vm-0.15.2f-linux> Class browser used if applicable: <ex: O2PackageBrowserAdaptor. If you don't know, print "SystemBrowser default"> Steps to reproduce: 1. 2. 3. Paste or attach stack trace if applicable (look at the file PharoDebug.log located in the same directory as your image):

Jan. 28, 2011

[Pharo-project] Issue 3609 in pharo: Integrate RPackage

by pharo＠googlecode.com

Status: Accepted Owner: cy.delau...(a)gmail.com New issue 3609 by cy.delau...(a)gmail.com: Integrate RPackage http://code.google.com/p/pharo/issues/detail?id=3609 RPackage aims to replace PackageInfo with a faster and cleaner implementation. What RPackage is already able to do (or at least until you find something wrong;)) is: - synchronize and initialize with the current PackageOrganizer in the system (RPackageOrhanizer class>> initializeDefault) - update itself when changes are made in the system (new category, new class, new method, ... ) (see all tests in RPackageMCSynchronisationTest). To point I am working on is to modify monticello to make it work using RPackage. I have currently A version that does not seem to crash all (:) that means that it save and load from a repository without error, and viewing changes seems to match with what you would expect). Now what could be cool is that the monticello tests green. To have all this running in your image, that's what should evaluate: Gofer new squeaksource: 'PharoTaskForces'; package: 'ConfigurationOfRPackage'; load. (Smalltalk globals at: #ConfigurationOfRPackage) loadDefault. "to be sure that the organizer is initialized before loading anything else:" (Smalltalk globals at: #RPackageOrganizer) initializeDefault. Gofer new squeaksource: 'DelaunayTmpStuffs'; version: 'Monticello-cyrilledelaunay.505'; merge. Gofer new squeaksource: 'DelaunayTmpStuffs'; version: 'MonticelloGUI-cyrilledelaunay.88'; merge.

Jan. 28, 2011

[Pharo-project] Issue 3608 in pharo: Fix failing MessageTally tests

by pharo＠googlecode.com

Status: Fixed Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3608 by marcus.d...(a)gmail.com: Fix failing MessageTally tests http://code.google.com/p/pharo/issues/detail?id=3608 Fix attached Attachments: MessageTallyFix.1.cs 1.6 KB

Jan. 28, 2011

Re: [Pharo-project] Databases with full text search support

by laurent laffont

Indeed actually we use successfully MySQL full text search engine and also Lucene (but not with Pharo ;) I think I should try OpenDBX. Laurent On Fri, Jan 28, 2011 at 3:44 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Laurent: several relational databases provvide full text serach > capabilities. > > You can send a SELECT statement with a MATCH() function to the server and > get > the result of search back (in case of MySQL). I think OpenDBX > library has to do nothing special here: it depends on which query you > write. > > > MySQL and PostgreSQL server has support for full text search (aka. > tsearch in PostgreSQL I think). > > > cheers > > mariano > > > On Fri, Jan 28, 2011 at 3:57 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> On 27.01.2011, at 20:48, laurent laffont wrote: >> >> > Hi, >> > >> > I need to have full text indexing and searching over a 3-5 million >> documents. Actually the products I work on are written in PHP - MySQL. >> > >> > What would you use (open source - mandatory - our products are open >> source) in Smalltalk world to do this ? >> > >> That topic troubled me some time in the last years. The first approach I >> took was postgresql+tsearch2 because I used Glorp back then. AFAIK tsearch2 >> has been incorporated into postgresql in the meantime so this is no extra >> weight. Stemming libraries for postgresql are quite good and available for >> some languages. If you would use Glorp you can even extend the query >> language to support it out of the box. >> I changed the setup as I moved from postgresql to gemstone. With the new >> setup I would have used postgresql only for the fulltext retrieval which I >> didn't like. I used SOLR [1] instead. It is a search server build upon >> lucene which supports faceted search and a lot of nifty stuff. I used >> magritte to generate the xml that I've put into SOLR. I was satisfied with >> this solution. But all solutions that need to cross the smalltalk boundary >> start to become cumbersome at some stage. >> If I find time I would take another approach. I found a smalltalk stemming >> library while observing the moose mailing list. If you have good stemming >> support it may be a reasonable effort to produce forward and inverted >> indexes of your objects with search capabilities. If you use magritte (or >> pragmas) then you could add the fields to index there. The rest would be >> automatic: Taking all fields that should be searchable. Tokenize and >> canonicalize (using stemming) the words and build forward and inverted >> index. The only thing that would be needed is a change notification system >> that updates the index but I think this is more of an easy task. Well, that >> is the sketch what I would try to do myself but don't find time right now. I >> personally think that the power you gain by search smalltalk objects >> directly outweighs all the external servers by some extent. >> If you use a special external database anyway that supports it, well, then >> this would be the easiest start. >> >> hope this helps, >> >> Norbert >> >> >> >> >

Jan. 28, 2011

Re: [Pharo-project] Issue 3333 in pharo: [Kernel Dependencies] Integer>>#asColorOfDepth

by pharo＠googlecode.com

Updates: Status: Closed Labels: Milestone-1.3 Comment #3 on issue 3333 by stephane...(a)gmail.com: [Kernel Dependencies] Integer>>#asColorOfDepth http://code.google.com/p/pharo/issues/detail?id=3333 13024

Jan. 28, 2011