- Pharo-users - lists.pharo.org

Re: [Pharo-users] Evaluation of Pharo for Commercial Project

by StÃ©phane Ducasse

Hi runar > I am looking at Pharo to evaluate whether it can be used for a > mid-size commercial project. The system will use Seaside. I have > looked at Pharo 1.0, 1.1 and 1.2. Do not use 1.2 :) This is written Unstable on the box :) > I am impressed by the work done so far. Pharo looks and feels a lot > better than Squeak, and a lot of enhancements have been done since the > project started. We will start cleaning even more under the surface. See my mail about 1.2 vision. > There are however a few issues which hold us back > from using Pharo, listed (in decreasing importance) below: > > > 1 - Package Management > > From what I have seen so far, the concept of âpackages and categoriesâ > is confusing. We are used to VisualAge and VisualWorks, which clearly > shows the structure of packages in the browsers. In Pharo we cannot > find browsers which give us the same overview. We are uncertain how > packages are made and how they show up in Monticello. At one point we > thought category == package, but that seems not to be correct. We note > that method extensions are possible, but we also struggle to > understand all aspects of them. really simple if you declare a package then you get: PackageA = CategoryA + protocol *CategoryA After if you have PackageA PackageAB Then AB is included in A (bad) So you should do PackageA-Core PackageA-B Do you use *overrides-categoryA simple this is bogus > > I notice that a âPackage management systemâ is in work, so hopefully > this area will improve. Removing completely categories would be good but we would end up with a lot of packages. We have a really new and good implementation to have first class packages without relying on string matching but now we should integrate them into the system. > 2 - Dependency Management between Packages > Since we are unable to organize our code in packages, why? > controlling and > verifying dependencies between them is hard. but you will use package and still you point is valid. > But from what I > understand, there are not many tools for controlling that packages do > not break dependency rules. You have dependencyBrowser developed by Hernan Morales eDSM to identify cycle in your program that is working on top of Moose Then also really important and much better than the envy solution you have metacello to describe the package dependency > 3 - Name Space Support > I understand name spaces will not be supported any soon. We have a > project with thousands of classes, and name space support would be > nice to have. Not before we really understand how they interact with package. I do not like the solution of VW, Java.... So we should build and prototype something good. > 4 - Break Point Support > It would be better to have break points, than having to insert code > like âself haltâ into the code. If this is the only show stopper to use pharo this is easy. There are some support for break points. We should look around. Second you have haltIf: which is worth a lot more than halt haltIf: #foo stopped if the methods is eventually invoked by foo > Is there any reason to believe Pharo will improve to meet our > requirements? I think that the two requirements are solved, because we managed really complex software with Monticello and metacello. Namespace can be solved with simple Prefixing for now. Finally you can provide code for fixes and that you can really get an impact on the system. > Did I misunderstand some aspects of Pharo, or are there > tools which can solve what we see as shortcomings? Stef

July 14, 2010

Re: [Pharo-users] Evaluation of Pharo for Commercial Project

by Geert Claes

Hi Runar! Runar Jordahl wrote: > > 1 - Package Management > From what I have seen so far, the concept of âpackages and categoriesâ is > confusing. We are used to VisualAge and VisualWorks, which clearly shows > the structure of packages in the browsers. In Pharo we cannot find > browsers which give us the same overview. We are uncertain how packages > are made and how they show up in Monticello. At one point we thought > category == package, but that seems not to be correct. We note that method > extensions are possible, but we also struggle to understand all aspects of > them. > You are right, the whole packages and categories thing is still very confusing and in most cases they are indeed the same thing. Have a look at the Pharo By Example Book (http://pharobyexample.org) and the still-work-in-progress Pharo Collaboractive book (http://book.pharo-project.org/book/introduction/whatisanimage) which tries to clarify it a bit. Runar Jordahl wrote: > > I notice that a âPackage management systemâ is in work, so hopefully this > area will improve. > > 2 - Dependency Management between Packages > Since we are unable to organize our code in packages, controlling and > verifying dependencies between them is hard. But from what I understand, > there are not many tools for controlling that packages do not break > dependency rules. > This is where Metacello comes in. Metacello is a Package Management System for Monticello http://gemstonesoup.wordpress.com/2009/08/25/metacello-package-management-f… I believe there is also a Metacello browser called Metaceller. You may also want to have a look at GoferProjectLoader http://www.smallworks.com.ar/en/community/GoferProjectLoader Runar Jordahl wrote: > > Is there any reason to believe Pharo will improve to meet our > requirements? Did I misunderstand some aspects of Pharo, or are there > tools which can solve what we see as shortcomings? > Pharo is continuously improving :) Pharo has already been used on commercial projects (see the Pharo success stories: http://www.pharo-project.org/about/success-stories) -- View this message in context: http://forum.world.st/Evaluation-of-Pharo-for-Commercial-Project-tp2288574p… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 14, 2010

Re: [Pharo-users] Evaluation of Pharo for Commercial Project

by Mariano Martinez Peck

On Wed, Jul 14, 2010 at 1:13 PM, Runar Jordahl <runar.jordahl(a)gmail.com>wrote: > I am looking at Pharo to evaluate whether it can be used for a > mid-size commercial project. The system will use Seaside. I have > looked at Pharo 1.0, 1.1 and 1.2. > > I am impressed by the work done so far. Pharo looks and feels a lot > better than Squeak, and a lot of enhancements have been done since the > project started. There are however a few issues which hold us back > from using Pharo, listed (in decreasing importance) below: > > > 1 - Package Management > > From what I have seen so far, the concept of âpackages and categoriesâ > is confusing. We are used to VisualAge and VisualWorks, which clearly > shows the structure of packages in the browsers. In Pharo we cannot > find browsers which give us the same overview. We are uncertain how > packages are made and how they show up in Monticello. At one point we > thought category == package, but that seems not to be correct. We note > that method extensions are possible, but we also struggle to > understand all aspects of them. > > I notice that a âPackage management systemâ is in work, so hopefully > this area will improve. > > 2 - Dependency Management between Packages > Since we are unable to organize our code in packages, controlling and > verifying dependencies between them is hard. But from what I > understand, there are not many tools for controlling that packages do > not break dependency rules. > > For 1 and 2, check Metacello: http://code.google.com/p/metacello/ It is done, working well, and achieves those points. We also wrote a draft of a Metacello chapter for Pharo By Example 2. I attach it in case you want to read it. > 3 - Name Space Support > I understand name spaces will not be supported any soon. We have a > project with thousands of classes, and name space support would be > nice to have. > > There are some implementations done, but noone is working out of the box (and maybe in no case) in Pharo. One is Namespaces in SqueakSource, and the other one I know is SecureSqueak. However, from my point of view, I think namespaces is something I can live without. I mean, I rally really want to have namespaces in Pharo, but I don't it shouldn't be a stopper. I saw big projects done without using it. On the other hand, there is a GSoC project working on that: http://gsoc2010.esug.org/projects/namespaces > 4 - Break Point Support > It would be better to have break points, than having to insert code > like âself haltâ into the code. > yes, I would like to have that also. I think gaucho put that? I am not sure...but in such it would be cool to integrate it. > > > Is there any reason to believe Pharo will improve to meet our > requirements? Did I misunderstand some aspects of Pharo, or are there > tools which can solve what we see as shortcomings? > > Kind regards > Runar Jordahl > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

July 14, 2010

Re: [Pharo-users] Evaluation of Pharo for Commercial Project

by Lukas Renggli

> 1 - Package Management > > From what I have seen so far, the concept of âpackages and categoriesâ > is confusing. We are used to VisualAge and VisualWorks, which clearly > shows the structure of packages in the browsers. In Pharo we cannot > find browsers which give us the same overview. We are uncertain how > packages are made and how they show up in Monticello. At one point we > thought category == package, but that seems not to be correct. We note > that method extensions are possible, but we also struggle to > understand all aspects of them. You might want to read the chapter on Monticello from Pharo by Example 2: https://gforge.inria.fr/frs/download.php/27018/Monticello.pdf > 2 - Dependency Management between Packages > Since we are unable to organize our code in packages, controlling and > verifying dependencies between them is hard. But from what I > understand, there are not many tools for controlling that packages do > not break dependency rules. For Seaside we wrote some tools to manage our 80+ packages and their dependencies: http://source.lukas-renggli.ch/packaging > 3 - Name Space Support > I understand name spaces will not be supported any soon. We have a > project with thousands of classes, and name space support would be > nice to have. Albeit nice, it is not a big deal not to have first class namespaces. Again see Seaside. > 4 - Break Point Support > It would be better to have break points, than having to insert code > like âself haltâ into the code. I think there is support, see the class BreakpointManager. I have never used it though. Lukas -- Lukas Renggli www.lukas-renggli.ch

July 14, 2010

Evaluation of Pharo for Commercial Project

by Runar Jordahl

I am looking at Pharo to evaluate whether it can be used for a mid-size commercial project. The system will use Seaside. I have looked at Pharo 1.0, 1.1 and 1.2. I am impressed by the work done so far. Pharo looks and feels a lot better than Squeak, and a lot of enhancements have been done since the project started. There are however a few issues which hold us back from using Pharo, listed (in decreasing importance) below: 1 - Package Management >From what I have seen so far, the concept of âpackages and categoriesâ is confusing. We are used to VisualAge and VisualWorks, which clearly shows the structure of packages in the browsers. In Pharo we cannot find browsers which give us the same overview. We are uncertain how packages are made and how they show up in Monticello. At one point we thought category == package, but that seems not to be correct. We note that method extensions are possible, but we also struggle to understand all aspects of them. I notice that a âPackage management systemâ is in work, so hopefully this area will improve. 2 - Dependency Management between Packages Since we are unable to organize our code in packages, controlling and verifying dependencies between them is hard. But from what I understand, there are not many tools for controlling that packages do not break dependency rules. 3 - Name Space Support I understand name spaces will not be supported any soon. We have a project with thousands of classes, and name space support would be nice to have. 4 - Break Point Support It would be better to have break points, than having to insert code like âself haltâ into the code. Is there any reason to believe Pharo will improve to meet our requirements? Did I misunderstand some aspects of Pharo, or are there tools which can solve what we see as shortcomings? Kind regards Runar Jordahl

July 14, 2010

Fwd: [Seaside] Looking for smart and good programmers? Attend the premium conference on Smalltalk!

by Mariano Martinez Peck

I guess it can be interested for you also. ESUG will be happy if you help to do some buzz about the conference. Forwarding emails to other mailing lists, post in your blogs, twitter, facebook, etc, always help. It would be great to expand the community and forward this email to other communities like ruby, python, linux, etc.... For more details: http://www.esug.org/Conferences/2010 Cheers Mariano ---------- Forwarded message ---------- From: stephane ducasse <stephane.ducasse(a)free.fr> Date: Mon, Jul 12, 2010 at 10:40 AM Subject: [Seaside] Looking for smart and good programmers? Attend the premium conference on Smalltalk! To: Seaside - general discussion <seaside(a)lists.squeakfoundation.org> We are all looking for smart and good people... Now the best to get in touch with them is to go where they go and have a nice beer with them. Did you think about coming to ESUG the key world conference on Smalltalk to meet talented people? Did you think about sponsoring ESUG so that programmers get aware of your business? Regularly we pass job interview at ESUG. Why not you? Each year ESUG offers the possibility to young guys to participate to ESUG as student volunteers you can also come and talk to them. Some data: Amsterdam 170 participants Brest 154 Barcelona The dead-line for registration at early bird fees is approaching (one month to go). So, hurry up and register on our new seaside-based server. http://registration.esug.org/ This server comes with new features. You can now do a group registration and make a single payment. Also, we have reduction tickets (typically for Golden and Platinum sponsors). The ESUG 2010 conference program is about to be ready, and it is as promising as was for the previous editions of the conference. Checkout the preliminary schedule is already on the web, http://www.esug.org/Conferences/2010 See you in Barcelona, ESUG board. _______________________________________________ seaside mailing list seaside(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

July 12, 2010

[ANN] new 1.2 image: 12049

by StÃ©phane Ducasse

https://gforge.inria.fr/frs/download.php/27270/PharoCore-1.2-12049.zip Stef

July 12, 2010

New Engineer position for Moose

by StÃ©phane Ducasse

We got a one year engineer position to support the development of a demonstratior for Moose. The ***constraints*** linked with the position are that the person should have got his master in 2009 or 2010. The starting date is 1 of December 2010. The salary should be around 3500 Euros bruto ~> 2300 Euros before taxes (but after health insurance). The job will probably consist in - getting Moose running into a web browser - having a better reporting system. - building a dashboard - porting part of codecity What this of course means is that it's kind of a cool job: work in a research lab, but no paper writing, no teaching, no administration. In addition: -> live in France (one hour from Paris, 1h20 from London, 35 min from Brussels) -> try a lot of good beers (our office is just 10km from the border to Belgium) -> enjoy french food -> code all the day in Smalltalk and a bit of C By september we should decide if we take this year in 2010 or 2011 (for decembre 2011 the person should have got a master in 2010 or 2011). Please send your cv. More about: - RMoD: http://rmod.lille.inria.fr - INRIA Lille: http://www.inria.fr/lille/ - INRIA in General: http://www.inria.fr - Engineers at INRIA: http://bit.ly/cLe6q4 - Pharo: http://pharo-project.org - Lille: - http://en.wikipedia.org/wiki/Lille - http://www.mairie-lille.fr/en - http://wikitravel.org/en/Lille Stef

July 10, 2010

Re: [Pharo-users] [BetaTesting] [ANN] Pharo-1.1-11409-rc4dev10.07.2

by Johan Fabry

FWIW, AspectMaps works fine with RC3 (just finished testing that) so I will suppose that it also works with RC4 ;-) On 05 Jul 2010, at 11:31, Mariano Martinez Peck wrote: > Hi folks. This is Pharo 1.1 RC4. It is almost the same as RC3 but with the Traits and Monticello fixes. There are also much more green tests. > > We are very very near to release Pharo 1.1 so please report any shot stopper problem you find. > > The link is https://gforge.inria.fr/frs/download.php/27254/Pharo-1.1-11409-rc4dev10.07.… > > Cheers > > Mariano > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

July 5, 2010

[BetaTesting] [ANN] Pharo-1.1-11409-rc4dev10.07.2

by Mariano Martinez Peck

Hi folks. This is Pharo 1.1 RC4. It is almost the same as RC3 but with the Traits and Monticello fixes. There are also much more green tests. We are very very near to release Pharo 1.1 so please report any shot stopper problem you find. The link is https://gforge.inria.fr/frs/download.php/27254/Pharo-1.1-11409-rc4dev10.07.… Cheers Mariano

July 5, 2010