July 2010 - Pharo-users - lists.pharo.org

Re: [Pharo-users] How to make "extract method" preserve my formatting?

by Carla F. Griggio

Hi Pat, I'm sorry, I'm not answering your question because I have no idea about that :P But I'm interested in what do you consider readable code, would you give some examples contrasting to the formatting Pharo would choose? Sometimes I prefer my own formatting too. Cheers! Carla. On Thu, Jul 15, 2010 at 6:44 PM, Pat Maddox <patmaddox(a)me.com> wrote: > The extract method refactoring works great but always formats my code in a > way that I hate. It indents certain things way too much, adds parens where > I don't want them, etc. Is there a way for it to preserve my formatting? I > wrote the code to be nice and readable to me, and I'd like to keep it that > way. > > Pat > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

July 15, 2010

How to make "extract method" preserve my formatting?

by Pat Maddox

The extract method refactoring works great but always formats my code in a way that I hate. It indents certain things way too much, adds parens where I don't want them, etc. Is there a way for it to preserve my formatting? I wrote the code to be nice and readable to me, and I'd like to keep it that way. Pat

July 15, 2010

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

by Mariano Martinez Peck

I cc'ed pharo-dev 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. > > 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 > > _______________________________________________ > 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 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