February 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] Pharo 1.3 - Build # 15 - Still Unstable!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Feb. 23, 2012

[Pharo-project] [Bug Tracker] All Failing Tests

by Marcus Denker

All currenty failing tests: (in 1.3Core, 1.3Full and and 1.4): http://code.google.com/p/pharo/issues/list?can=2&q=Status%3DFailingTest -- Marcus Denker -- http://marcusdenker.de

Feb. 23, 2012

[Pharo-project] Pharo Core 1.3 - Build # 14 - Still Unstable!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Feb. 23, 2012

[Pharo-project] Pharo 1.4 Tests-Unix - Build # 238 - Still Unstable!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Feb. 23, 2012

[Pharo-project] Pharo 1.4 Tests-Mac - Build # 227 - Still Unstable!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Feb. 23, 2012

Re: [Pharo-project] Ecompletion/OCompletion

by StÃ©phane Ducasse

Ok I made Ecompletion working nicely in 1.4 :). I will commit a version if I have write access to completion repository. In addition I moved completion extensions to SHRange to SHRange :). I will have to update the configurationOfShout. But spec for: #pharo do: [ spec package: 'Shout' with: 'Shout-AlainPlantec.113'; package: 'ShoutTests' with: 'ShoutTests-GuillermoPolito.13'. looks quite old when I see that I'm at Shout-StephaneDucasse.130 So I will check because may be the configuration of metacelloRepository is not up to date. Stef > Sadly we cannot have the two together. > So I started to do an analysis of the situation. > OCompletion includes physically ECompletion. > > So what I plan to do in the coming months is: > - make ECompletion working in 1.4 (Alain I need your help with caret, isCaretBehindChar, selectionPosition:, wordAtCaret) > > - analyze the extensions made by each package and move the extension that make sense into their respective packages > For example E/OCompletion extends Shout with some simple queries, String and other so I will make a list > of changes that we should move to the right places. > > - understand how we can make sure that OCompletion does not just include the code of ECompletion. > - understand how to extend Ecompletion to get OCompletion and both working. > > Stef

Feb. 23, 2012

Re: [Pharo-project] 1.4 and forward (was Netstyle experience)

by Schwab,Wilhelm K

Norbert, Dale, Thanks for taking constructive feedback as it is intended. I had some more success using a Seaside 3.0 canned image, but some stuff that was loading in 1.4 is just hanging. I need to see if the redirect is really in force, but sleep calls. This is closer than I have gotten before... Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Dale Henrichs [dhenrich(a)vmware.com] Sent: Thursday, February 23, 2012 4:30 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 and forward (was Netstyle experience) Bill, I hear and appreciate your feedback about Metacello ... when one has a ConfigurationOf class for specifications there are temptations to leverage the fact that it is a class, we can end up with a proliferation of class-side short cut methods that do all sorts of interesting things. I'm hoping that the Metacello scripting API (which I am currently working on) will provide a more uniform way to load projects and reduce the demand for class-side shortcuts on the ConfigurationOf class ... Dale ----- Original Message ----- | From: "Wilhelm K Schwab" <bschwab(a)anest.ufl.edu> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, February 22, 2012 11:49:43 PM | Subject: Re: [Pharo-project] 1.4 and forward (was Netstyle experience) | | Stef, | | Feedback, not whining (as some might claim): this snippet illustrates | my frustration with Metacello. Note that ConfigurationOfXMLSupport | (at least in the past) requires #loadDefault vs. #load. It would be | *really* nice to have ONE incantation that always gets latest stable | releases. | | I'm trying to load a LOT of stuff, so having a stable infrastructure | would be helpful. Just saying... It might be too idealistic, but | the current situation has me capturing things that *appear* correct | and might not be (or quickly turn obsolete). Ultimately, we | probably need real packages. | | Thanks for Pharo! | | Bill | | | | | ________________________________________ | From: pharo-project-bounces(a)lists.gforge.inria.fr | [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of | Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] | Sent: Thursday, February 23, 2012 2:41 AM | To: Pharo-project(a)lists.gforge.inria.fr | Subject: Re: [Pharo-project] 1.4 and forward (was Netstyle | experience) | | Stef, | | From my "throw-away" 1.4 image: | | Gofer new | squeaksource: 'XMLSupport'; | package: 'ConfigurationOfXMLSupport'; | load. | (Smalltalk at: #ConfigurationOfXMLSupport) perform: | #loadDefault. | | | #( 'SIXX-Core' 'SIXX-Examples' 'SIXX-InOut-Common' | 'SIXX-InOut-Squeak' 'SIXX-ParserAdapter' | 'SIXX-Squeak' 'SIXX-Test' | ) do:[ :each | | self loadLatestPackage:each fromSqueaksource:'SIXX'. | ]. | | The above appears to have worked, and I *almost* wiped it out with a | new attempt... Pays to look sometimes. | | Bill | | ________________________________________ | From: pharo-project-bounces(a)lists.gforge.inria.fr | [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of | Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] | Sent: Thursday, February 23, 2012 2:27 AM | To: Pharo-project(a)lists.gforge.inria.fr | Subject: Re: [Pharo-project] 1.4 and forward (was Netstyle | experience) | | Stef, | | Reading this is encouraging. I have not forgotten about 1.4, I have | simply been heavily distracted. SIXX is a concern, as I built a lot | on top of it and (I *think*) need to get it loaded in order to | evaluate Fuel vs. it. XML parsers are a big part of life for SIXX. | Regardless of any change I might make, SIXX should be in the image | to load "legacy" data (from last month<g>). | | I will try again soon. | | Bill | | | ________________________________________ | From: pharo-project-bounces(a)lists.gforge.inria.fr | [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane | Ducasse [stephane.ducasse(a)inria.fr] | Sent: Wednesday, February 22, 2012 3:50 PM | To: Pharo-project(a)lists.gforge.inria.fr | Subject: Re: [Pharo-project] Netstyle experience (was Do not feed the | trolls) | | On Feb 22, 2012, at 1:58 PM, Norbert Hartl wrote: | | > | > Am 22.02.2012 um 13:28 schrieb GermÃ¡n Arduino: | > | >> Example: xmlrpc died before to born, worked only in 1.1.1, now I | >> must find time to update it to zinc and 1.3 but with the fear | >> that again will not work in 1.4. | > | > What are your building blocks except http and xml? If you were | > working on 1.1.1 then xml parser moved quite a bit and zinc | > appeared on the scene. The changes to adopt xml parser should be | > minimal. Zinc provides a facade that mimicks backward | > compatibility. So you could have an easy start. But to be honest | > the situation is soooo much better with having zinc that you might | > save some time in development if you use zinc straight away. | > And about 1.4: Yes, it moves a lot but zinc and xml do not. Xml is | > stable since months and the change rate in zinc is also dropping. | > So you might expect them to be available until...let's say...3 | > months from now. :) Ok, just kidding, I think the will stay | > similar for quite some time. | | Exactly. | Doru got **all** the moose tools in 1.4 and some of them like glamour | rely a lot on UI changes. | I doubt that xmlrpc got any impacted on Morphic change. We do not | change XML (but the XML maintainers did) | and Zinc is just much much much better than the old system so it | should be not difficult to adapt especially if you ask. | | Stef | | | |

Feb. 23, 2012

Re: [Pharo-project] 1.4 and forward (was Netstyle experience)

by Schwab,Wilhelm K

+10 on that idea :) ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Dale Henrichs [dhenrich(a)vmware.com] Sent: Thursday, February 23, 2012 4:30 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 and forward (was Netstyle experience) Bill, I hear and appreciate your feedback about Metacello ... when one has a ConfigurationOf class for specifications there are temptations to leverage the fact that it is a class, we can end up with a proliferation of class-side short cut methods that do all sorts of interesting things. I'm hoping that the Metacello scripting API (which I am currently working on) will provide a more uniform way to load projects and reduce the demand for class-side shortcuts on the ConfigurationOf class ... Dale ----- Original Message ----- | From: "Wilhelm K Schwab" <bschwab(a)anest.ufl.edu> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, February 22, 2012 11:49:43 PM | Subject: Re: [Pharo-project] 1.4 and forward (was Netstyle experience) | | Stef, | | Feedback, not whining (as some might claim): this snippet illustrates | my frustration with Metacello. Note that ConfigurationOfXMLSupport | (at least in the past) requires #loadDefault vs. #load. It would be | *really* nice to have ONE incantation that always gets latest stable | releases. | | I'm trying to load a LOT of stuff, so having a stable infrastructure | would be helpful. Just saying... It might be too idealistic, but | the current situation has me capturing things that *appear* correct | and might not be (or quickly turn obsolete). Ultimately, we | probably need real packages. | | Thanks for Pharo! | | Bill | | | | | ________________________________________ | From: pharo-project-bounces(a)lists.gforge.inria.fr | [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of | Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] | Sent: Thursday, February 23, 2012 2:41 AM | To: Pharo-project(a)lists.gforge.inria.fr | Subject: Re: [Pharo-project] 1.4 and forward (was Netstyle | experience) | | Stef, | | From my "throw-away" 1.4 image: | | Gofer new | squeaksource: 'XMLSupport'; | package: 'ConfigurationOfXMLSupport'; | load. | (Smalltalk at: #ConfigurationOfXMLSupport) perform: | #loadDefault. | | | #( 'SIXX-Core' 'SIXX-Examples' 'SIXX-InOut-Common' | 'SIXX-InOut-Squeak' 'SIXX-ParserAdapter' | 'SIXX-Squeak' 'SIXX-Test' | ) do:[ :each | | self loadLatestPackage:each fromSqueaksource:'SIXX'. | ]. | | The above appears to have worked, and I *almost* wiped it out with a | new attempt... Pays to look sometimes. | | Bill | | ________________________________________ | From: pharo-project-bounces(a)lists.gforge.inria.fr | [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of | Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] | Sent: Thursday, February 23, 2012 2:27 AM | To: Pharo-project(a)lists.gforge.inria.fr | Subject: Re: [Pharo-project] 1.4 and forward (was Netstyle | experience) | | Stef, | | Reading this is encouraging. I have not forgotten about 1.4, I have | simply been heavily distracted. SIXX is a concern, as I built a lot | on top of it and (I *think*) need to get it loaded in order to | evaluate Fuel vs. it. XML parsers are a big part of life for SIXX. | Regardless of any change I might make, SIXX should be in the image | to load "legacy" data (from last month<g>). | | I will try again soon. | | Bill | | | ________________________________________ | From: pharo-project-bounces(a)lists.gforge.inria.fr | [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane | Ducasse [stephane.ducasse(a)inria.fr] | Sent: Wednesday, February 22, 2012 3:50 PM | To: Pharo-project(a)lists.gforge.inria.fr | Subject: Re: [Pharo-project] Netstyle experience (was Do not feed the | trolls) | | On Feb 22, 2012, at 1:58 PM, Norbert Hartl wrote: | | > | > Am 22.02.2012 um 13:28 schrieb GermÃ¡n Arduino: | > | >> Example: xmlrpc died before to born, worked only in 1.1.1, now I | >> must find time to update it to zinc and 1.3 but with the fear | >> that again will not work in 1.4. | > | > What are your building blocks except http and xml? If you were | > working on 1.1.1 then xml parser moved quite a bit and zinc | > appeared on the scene. The changes to adopt xml parser should be | > minimal. Zinc provides a facade that mimicks backward | > compatibility. So you could have an easy start. But to be honest | > the situation is soooo much better with having zinc that you might | > save some time in development if you use zinc straight away. | > And about 1.4: Yes, it moves a lot but zinc and xml do not. Xml is | > stable since months and the change rate in zinc is also dropping. | > So you might expect them to be available until...let's say...3 | > months from now. :) Ok, just kidding, I think the will stay | > similar for quite some time. | | Exactly. | Doru got **all** the moose tools in 1.4 and some of them like glamour | rely a lot on UI changes. | I doubt that xmlrpc got any impacted on Morphic change. We do not | change XML (but the XML maintainers did) | and Zinc is just much much much better than the old system so it | should be not difficult to adapt especially if you ask. | | Stef | | | |

Feb. 23, 2012

Re: [Pharo-project] Netstyle experience (was Do not feed the trolls)

by Janko MivÅ¡ek

S, Milan Mimica piÅ¡e: > > Pharo is an IDE. IDEs don't run on tablets. > > But open your eyes. Pharo is much more than an ide. > Exactly. And Squeak is even more than Pharo, but more is not better. I > think we should focus and there is still too many opinions of what Pharo > should be. Some try to pull in OpenGL interface, some would like to > improve the headless mode, some use it as a web platform. Most efforts > will go to waste. Pharo cannot possibly be that much. Agree, let we rather focus on few areas, specially in forthcoming Pharo Consortium. Is the goal of Pharo Vision document also to determine on which areas to focus? Fokus short-term and long term, and on which areas to just experiment for now ? Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Feb. 23, 2012

Re: [Pharo-project] Netstyle experience (was Do not feed the trolls)

by Christoph Wysseier

Dear Janko Am 21.02.12 13:07, schrieb Janko MivÅ¡ek: > Hi Chris, > > Thank you very much for your experience report and I think I'm not alone > to like to hear from your more about what are your wishes as a manager > from the Pharo in the future. Because you are an "enterprise" (in a > positive meaning of that word) Pharo user. Thank you for your warm welcome! I hope to not boring the list with my business gibberish. I promise to keep quiet again very soon. ;) > Maybe let me start asking you an opinion of what I'd like to see from > Pharo as a priority: > > - more stability, > - better user experience (UX), > - better version control and packaging tools > - better integration of tools > - tabbed browsing, back button etc Although stability and performance are important priorities, as far as we are concerned stability is not a large issue. With 10 years of experience operating hundreds of such applications we were able to build a framework which operates such web applications reliable. And Pharo even improved this situation a lot. We would only wish some small improvement like error handling on startup and seldomly Pharo image are freezing, but this is hard to debug. Our priority would be definitely the improvement of the IDE and source code management. Working with Smalltalk is already fun and offers a very efficient way of developing sophisticated solutions, if the IDE would further simplify the process of developing step-by-step, the work with Pharo would make more and more fun. But, working on the UX is far not the same as working on new feature or hunting bugs. It needs a clear vision for everyone working with it and changes need to be deployed carefully. This would be one of our seldom criticism. A few changes in the handling of the IDE were surprising and appeared to be without any concept (which also means that we just did not understand the idea behind). IMHO, such improvements would need a careful planning and communication with the final users. The integration of tools is not that important. We just use external software such as PostgresQL, ImageMagick, Apache FOP, etc. which can be connected using several, pretty stable interfaces. > More polishing and boring bug hunting tasks therefore and just a bit > less fundamental rewritings like compiler etc. Later are more academic > and more interesting, yes, but IMHO for us the "enterprise" users the > above priorities are much more important. I agree with Stef. Of course the above priorities are much more important for our own businesses. Nevertheless, a lively community and an innovative strategy would not exist if the Pharo board would concentrate on these priorities only. Pharo should allow to develop innovative other applications and new development concepts too. And, it is a fact that this intelligent community is driven by some academic users which is exactly why we believe it to become better and better. Regards, Chris

Feb. 23, 2012