- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About 1.2

by laurent laffont

On Fri, Feb 25, 2011 at 9:50 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi guys > > 1.2 should go out. Marcus and me should spend their time on 1.3, OPAL and > the rest. > Yes Now for PharoDev we want to remove packages that are not about tools. > If you want XML, openDBX... help us using Metacello to build distributions > = something that will work in 1.2 when > we will be in Pharo 10. Right now this is not normal that a problem in XML > in 1.2 impacts the builds in 1.1. > > How can XML in 1.2 impacts 1.1 ??????? > Proposing bloated images DOES NOT HELP US. Why? Because the goal is to have > an INFRASTRUCTURE to take > a small image with a metacello description repository and load whatever we > want. In the future we want to use > metacello to manage core and not to have a distinction between core and > dev. We should be able to load all the time > RBEngine and use it all the time to fix the system. > Right now we are LOSING TIME on fixing 1.2 configs while we should invest > in the infrastructure that will enable > to be agile and load whatever configuration we/you will develop. > > Yes. For the positive side, Hudson has given us visibility, which wasn't the case in 1.1. And when you get visibility, the first thing you see is crappy stuff :) IMHO 1.2 release process is far better than 1.1 (ok slow, but visible). I've changed my mind about XML. If Pharo's goal is to be a development tool, then I agree to remove XML, it's not a dev tool. But I think Mocketry should be back at least for 1.3. Mocks are a dev tool. I want to put dependencies on Mocketry (as I know how to use it now and I like it) for my projects but some are included in Pharo (ProfStef, Autotest) and I'm waiting for a mocking library in Pharo. TDD without mocks is a pain. Writing its own mocks is a burden. So can we be focus on the infrastructure? The concept and tools that we will > make us be really powerful in the > future? > For Pharo as a dev platform, it seems infrastructure is here. The thing I don't like is that for PharoCore 1.3 more and more tests actually fails. IMHO, resolving failing tests must be the highest priority. And it's hard to work on Pharo 1.3 failing tests if tests are failing in PharoCore. This way we will improve the release process (continuous delivery in mind). Now we need to be sure that often used frameworks (XML, Seaside, OpenDBX, Magma ...) work out of the box for Pharo. So Pharo-Clients on Hudson is a good idea. We need more. It's also a good tool to evaluate future inclusion (ex: Zinc). I like the Linux project process: fixed time frame ( 2 weeks) to include new things, then resolve. They managed to get a major release every 3 months. Don't start next major version until the current is out. So if the community does not hear our call, we the board will take actions. > We do not want to do that but if this > is necessary we will do it because we want 1.2 to get out. > > Agree. Laurent. > Stef >

Feb. 27, 2011

Re: [Pharo-project] About 1.2

by StÃ©phane Ducasse

On Feb 27, 2011, at 1:06 AM, Norbert Hartl wrote: > Why do you think the break of 1.1 build is xml related? This is what marcus was saying. May be the configuration did not point to the right version. > To me it appears either a PharoSound or metacello problem. The build is unable to load Collections-Arithmetic. Either it is missing from the package-cache or erronously pulled in via dependency that is not right. ok Still this is an EXAMPLE of the kind of problems the infrastructure should fix. Let us focus on distributions based on metacello. Stef > > > Norbert > > > > Am 25.02.2011 um 21:50 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> Hi guys >> >> 1.2 should go out. Marcus and me should spend their time on 1.3, OPAL and the rest. >> >> Now for PharoDev we want to remove packages that are not about tools. >> If you want XML, openDBX... help us using Metacello to build distributions = something that will work in 1.2 when >> we will be in Pharo 10. Right now this is not normal that a problem in XML in 1.2 impacts the builds in 1.1. >> >> Proposing bloated images DOES NOT HELP US. Why? Because the goal is to have an INFRASTRUCTURE to take >> a small image with a metacello description repository and load whatever we want. In the future we want to use >> metacello to manage core and not to have a distinction between core and dev. We should be able to load all the time >> RBEngine and use it all the time to fix the system. >> >> Right now we are LOSING TIME on fixing 1.2 configs while we should invest in the infrastructure that will enable >> to be agile and load whatever configuration we/you will develop. >> >> So can we be focus on the infrastructure? The concept and tools that we will make us be really powerful in the >> future? >> >> So if the community does not hear our call, we the board will take actions. We do not want to do that but if this >> is necessary we will do it because we want 1.2 to get out. >> >> Stef >> >> >

Feb. 27, 2011

Re: [Pharo-project] About 1.2

by StÃ©phane Ducasse

Yes we should do that. Now the problem with the xml package is not even that. If we include package like that then for example each time a project like moose which use it wants to use the latest version (it will happen during at least 6 months) then they/we will have a problem because the system may have problem to load (we got that situation in Moose). So the SOLUTION is let people decide what they want to use. Keep PharoDev for tools not framework. Stef On Feb 26, 2011, at 10:16 PM, Tudor Girba wrote: > Hi Stef, > > I think this is the right approach. I would suggest in the future to set a hard deadline a month before, and only include what works at that time. Like this people have time to react, and if they do not, you can safely remove things without anyone telling you that you did not warn them :) > > Cheers, > Doru > > > On 25 Feb 2011, at 21:50, StÃ©phane Ducasse wrote: > >> Hi guys >> >> 1.2 should go out. Marcus and me should spend their time on 1.3, OPAL and the rest. >> >> Now for PharoDev we want to remove packages that are not about tools. >> If you want XML, openDBX... help us using Metacello to build distributions = something that will work in 1.2 when >> we will be in Pharo 10. Right now this is not normal that a problem in XML in 1.2 impacts the builds in 1.1. >> >> Proposing bloated images DOES NOT HELP US. Why? Because the goal is to have an INFRASTRUCTURE to take >> a small image with a metacello description repository and load whatever we want. In the future we want to use >> metacello to manage core and not to have a distinction between core and dev. We should be able to load all the time >> RBEngine and use it all the time to fix the system. >> >> Right now we are LOSING TIME on fixing 1.2 configs while we should invest in the infrastructure that will enable >> to be agile and load whatever configuration we/you will develop. >> >> So can we be focus on the infrastructure? The concept and tools that we will make us be really powerful in the >> future? >> >> So if the community does not hear our call, we the board will take actions. We do not want to do that but if this >> is necessary we will do it because we want 1.2 to get out. >> >> Stef >> >> > > -- > www.tudorgirba.com > > "What is more important: To be happy, or to make happy?" > >

Feb. 27, 2011

Re: [Pharo-project] Fwd: [ANN] pharo focused sprint - bern, feb 26

by StÃ©phane Ducasse

On Feb 26, 2011, at 10:09 PM, Tudor Girba wrote: > Hi, > > The sprint was quite exciting. > > Here is the twitter report: > http://twitter.com/#!/search/pharosprint > > Here is a longer report: > > - Camillo looked into Keymapping. He spent several hours going through the code with the debugger. In the process he extracted more actions into keybindings (in the Keymapping-Settings). It's a commendable effort because it is quite a challenge to debug the system when playing with the keybindings :). The conclusion seems to be that Keymapping provides good functionality already, but that it needs some refactoring. In particular: > --- There should be less decisions in the TextMorph. These should be delegated to the Dispatcher > --- Some classes and methods would do with better names. For example, keyMapper / hasKeymap / Dispatcher. They should be all Keymapper > --- There are a couple of symbols around (e.g., #complete) that are not quite clear and that should be modeled explicitly. > --- Camillo, did I miss anything? > > - Lukas went over the WeakAnnouncements implementation to get the WeakMessageSend working. The code is in PharoTaskForces should we take action on this one? I mean integrating it. > - Lukas worked on getting OB work with the changes in TextMorph from Pharo 1.2. > > - Adrian, Jorge and Toon worked on implementing a Debugger on top of Glamour. They got a first version working that is able to do basic actions: step, restart, step into. The challenge was to get to understand the model, and to figure out that <primitive: 19> is used for marking that a method should not be debugged. In any case, working with Glamour seemed to work quite smoothly. The code is available in the Glamorous Toolkit. Adrian, did I get it right? :) > > - Mircea built a new widget for searching multiple categories of items in the same time, similar to spotlight where you enter one string and you get multiple hits from multiple categories. The implementation was spawned from the OBCompletionDialog / OBCompletionRequest and currently it simply provides multiple lists one below the other. The idea is to use this kind of widget to search simultaneously for classes / methods / packages. The code is available in Glamour (Glamour-Morphic-Renderer). The widget can definitely be improved visually, but Mircea already did a nice job. is the widget only for glamour because I think that a widget with search list integrated should be used everywhere? We were discussing with alain to have a look at the one in OB and push it/rewrite it as a core widget > - I showed the current prototypes available in the Glamorous Toolkit (built with Glamour). It looks like we got a consensus that we should focus on rethinking the IDEs, and that Glamour can be a promising infrastructure. For this to work, we distinguished between the work needed at the widget level (like the work of Mircea and Camillo), and the work needed at the level of playing with new metaphors for browsing. The Glamorous Toolkit already provides a number of examples for: ObjectFinder, Chaser, Playground (ex-Workspace), MessageTallyBrowser, ProfStef, and some Coders. If you want to play with the early versions of these tools, you can get them here (just keep in mind that they are intended as exercises at the moment): > Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. > (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. > > > Cheers, > Doru > > > On 26 Feb 2011, at 19:06, StÃ©phane Ducasse wrote: > >> so doru I just arrived after a trip from the nearly "westernest" town in france to nearly the "northest" one :) >> What are the results of the sprint. >> >> >> On Feb 26, 2011, at 9:42 AM, Tudor Girba wrote: >> >>> We are starting the sprint: >>> - Twitter tag: #pharosprint >>> - If someone wants to join remotely, let us know how to reach you. Gary, Alain? :) >>> >>> Cheers, >>> Doru >>> >>> >>> On 25 Feb 2011, at 20:39, Tudor Girba wrote: >>> >>>> Phenomenal :) >>>> >>>> Doru >>>> >>>> >>>> On 24 Feb 2011, at 13:03, Jorge Ressia wrote: >>>> >>>>> I will be there too. >>>>> >>>>> Cheers, >>>>> >>>>> On Wed, Feb 23, 2011 at 10:44 PM, Tudor Girba <tudor.girba(a)gmail.com> wrote: >>>>>> Excellent. >>>>>> >>>>>> Doru >>>>>> >>>>>> >>>>>> On 23 Feb 2011, at 22:29, Lukas Renggli wrote: >>>>>> >>>>>>> I am coming too. >>>>>>> >>>>>>> Lukas >>>>>>> >>>>>>> On 23 February 2011 05:27, Tudor Girba <tudor.girba(a)gmail.com> wrote: >>>>>>>> Great. >>>>>>>> >>>>>>>> Doru >>>>>>>> >>>>>>>> >>>>>>>> On 22 Feb 2011, at 19:47, Camillo Bruni wrote: >>>>>>>> >>>>>>>>> I'll be there. >>>>>>>>> >>>>>>>>> From what I have done this week so far, I would like to work on extending the IDE and reduce the amount of clicks / keystrokes to browse things... >>>>>>>>> >>>>>>>>> m(o_o)m >>>>>>>>> camillo >>>>>>>>> >>>>>>>>> On 2011-02-21, at 19:42, Tudor Girba wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I would like to remind you that this Saturday, February 26, we organize a Sprint at SCG, University of Berne, Switzerland (room 107): >>>>>>>>>> http://scg.unibe.ch/contact/maps >>>>>>>>>> >>>>>>>>>> Further details can be found below. Please let us know by mail if you plan to attend and what you would wish to work on (see below). >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Doru >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Begin forwarded message: >>>>>>>>>> >>>>>>>>>>> From: Tudor Girba <tudor.girba(a)gmail.com> >>>>>>>>>>> Date: 1 February 2011 16:38:30 CET >>>>>>>>>>> To: "Pharo-project(a)lists.gforge.inria.fr Development" <pharo-project(a)lists.gforge.inria.fr> >>>>>>>>>>> Cc: Adrian Lienhard <alienhard(a)netstyle.ch> >>>>>>>>>>> Subject: [ANN] pharo focused sprint - bern, feb 26 >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> We would like to organize a Pharo Sprint on Saturday, February 26 at SCG, University of Berne, Switzerland (room 107): >>>>>>>>>>> http://scg.unibe.ch/contact/maps >>>>>>>>>>> >>>>>>>>>>> Unlike other sprints, this would not be about fixing things from the tracker, but about building something new and reviewing the situation around one central topic. For this one, the main topic will be Morphic and the IDE. Why? Because it is time to rethink our day-to-day tools and bring them closer to this century (ok, maybe decade :)). It is Ok if you are not a specialist. It is more important to want to participate and learn. The rest will come in time. >>>>>>>>>>> >>>>>>>>>>> ***** Please let us know by mail if you plan to attend and what you would wish to work on (see below). >>>>>>>>>>> >>>>>>>>>>> Proposed tasks (other tasks are possible in the same area): >>>>>>>>>>> - Enhancements of Morphic widgets: >>>>>>>>>>> --- TabGroupMorph with lazy pages, closable tabs, overflow handling and toolbars (a start exists in Glamour) >>>>>>>>>>> --- High level support for collapsable panes (based on the input of Gary) >>>>>>>>>>> --- SearchMorph with multiple groups of items (like in Spotlight) >>>>>>>>>>> --- MorphTreeMorph integrated with GeneralScrollPane to allow for space filling >>>>>>>>>>> --- BreadcrumbMorph >>>>>>>>>>> --- Hyperlinks in TextMorphs >>>>>>>>>>> - Test and enhance the current IDE >>>>>>>>>>> - Evaluate TextMorphs: NewTextMorph, PluggableTextMorph, SMxPluggableTextMorph etc >>>>>>>>>>> - Prototype a new ToolSet solution >>>>>>>>>>> - Enhancements of Glamour and of the Glamorous Toolkit >>>>>>>>>>> --- Debugger >>>>>>>>>>> --- Coder >>>>>>>>>>> --- Multipage Workspace >>>>>>>>>>> --- CodeBubbles >>>>>>>>>>> - Develop WeakAnnouncement (start from the implementation of Lukas) >>>>>>>>>>> - Evaluate the various keybinding implementations >>>>>>>>>>> - Evaluate ToolBuilder >>>>>>>>>>> - Evaluate the path to adopt SimpleMorphic >>>>>>>>>>> >>>>>>>>>>> A second working topic is getting Monticello faster, but this will only be tackled if there are enough people for the first one. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Adrian and Doru >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> www.tudorgirba.com >>>>>>>>>>> >>>>>>>>>>> "Be rather willing to give than demanding to get." >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> www.tudorgirba.com >>>>>>>>>> >>>>>>>>>> "It's not how it is, it is how we see it." >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> www.tudorgirba.com >>>>>>>> >>>>>>>> "Value is always contextual." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Lukas Renggli >>>>>>> www.lukas-renggli.ch >>>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "There are no old things, there are only old ways of looking at them." >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Jorge Ressia >>>>> www.jorgeressia.com >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Yesterday is a fact. >>>> Tomorrow is a possibility. >>>> Today is a challenge." >>>> >>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Be rather willing to give than demanding to get." >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "Reasonable is what we are accustomed with." > >

Feb. 27, 2011

Re: [Pharo-project] Good reference on time on unit testing?

by Peter Hugosson-Miller

+100 Couldn't have said it better myself! -- Cheers, Peter. On 27 feb 2011, at 08:27, laurent laffont <laurent.laffont(a)gmail.com> wrote: > On Sun, Feb 27, 2011 at 4:52 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Hello all, > > Can anyone recommend a good reference on the amount of time one should expect to spend writing tests? I will have to be the messenger (will be wearing running shoes just in case...), but I want the message to come from a solid source. > > If you develop the TDD way (which I always do at work) then I would say this question is not valid. Your production code will be there because of tests. In legacy system, new and refactored code will be there because of tests. > > IMHO the questions "how much time should I spend writing tests?" or "how many tests should I write ?" are raised when tests are written after. And sadly tests often become a burden in this case and doesn't support the pressure of releases / last minute changes / ... (I've done it this way almost 10 years ago, not good :) > > In TDD the question is "which stories / scenarios do we have to implement ?". It's more a Product owner / customer point of view. > > The best book on TDD I've read is Dave Astels TDD: a practical guide (Indeed, this one has really changed my mind on how testing should be done, and other books I've read since don't). > > Laurent > > > > Bill > > > > >

Feb. 27, 2011

Re: [Pharo-project] Good reference on time on unit testing?

by laurent laffont

On Sun, Feb 27, 2011 at 4:52 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Hello all, > > Can anyone recommend a good reference on the amount of time one should > expect to spend writing tests? I will have to be the messenger (will be > wearing running shoes just in case...), but I want the message to come from > a solid source. > If you develop the TDD way (which I always do at work) then I would say this question is not valid. Your production code will be there because of tests. In legacy system, new and refactored code will be there because of tests. IMHO the questions "how much time should I spend writing tests?" or "how many tests should I write ?" are raised when tests are written after. And sadly tests often become a burden in this case and doesn't support the pressure of releases / last minute changes / ... (I've done it this way almost 10 years ago, not good :) In TDD the question is "which stories / scenarios do we have to implement ?". It's more a Product owner / customer point of view. The best book on TDD I've read is Dave Astels TDD: a practical guide (Indeed, this one has really changed my mind on how testing should be done, and other books I've read since don't). Laurent > > Bill > > > > >

Feb. 27, 2011

[Pharo-project] Good reference on time on unit testing?

by Schwab,Wilhelm K

Hello all, Can anyone recommend a good reference on the amount of time one should expect to spend writing tests? I will have to be the messenger (will be wearing running shoes just in case...), but I want the message to come from a solid source. Bill

Feb. 27, 2011

Re: [Pharo-project] Metacello Configuration Pharo1.2 solo sprint ... status

by Dale Henrichs

On Feb 25, 2011, at 5:27 PM, Dale Henrichs wrote: > Pharo1.2 is close and Metacello is one of the bad boys with the failing > tests sooooo, I am going to do a solo sprint this weekend: > > 1. a quick release of Metacello with expectedFailures for the tests.... released 1.0-beta.28.3.1 with expected failures defined, last night... > 2. in build #57 of Pharo1.2 I noticed some odd things that I want to > track down... tracked down the anomalies in build #157... as I suspected, the anomalies were due to configuration specification issues...the right things were loaded, but the configuration errors lead to misleading currentVersions for some of the configs... > 3. I expect that some of the #57 issues can be revealed with the > validator, so I am thinking that I will run the validator over > all of the configurations that are used in Pharo1.2 ... Yep 7 of the configurations referenced by ConfigurationOfPharo had issues that I've been able to clean up without doing anything too drastic to the configs ... I've still got to do some test loads to make sure that they load clean, etc... > 4. I'm not going to spend a lot of time reading/writing email ... ...GRUNT... > 5. While working on the above task, I will work on the > MetacelloBrowser adding menu items Added ob sunit-type validation icons to the confiugrations and versions in the MetacelloBrowser ... when you click on the icon you get the validation results ... there is still more to polish in the MetacelloBrowser, I know that Alexandre is doing more work this evening and I've got a handful of things more to add that I think will be useful ... Dale

Feb. 27, 2011

Re: [Pharo-project] Metacello Configuration Pharo1.2 solo sprint Portland, Oregon ... Saturday and Sunday

by Dale Henrichs

On Feb 26, 2011, at 5:26 AM, Mariano Martinez Peck wrote: "solo sprint" hahahaha AWESOME. Lots of us do solo sprints :) Haha, but unlike most other solo sprints I'm monkeying with "other people's" configurations:), so I thought it worth the warning:) Dale On Sat, Feb 26, 2011 at 8:20 AM, laurent laffont <laurent.laffont(a)gmail.com<mailto:laurent.laffont@gmail.com>> wrote: Thank you Dale. Laurent. On Sat, Feb 26, 2011 at 2:27 AM, Dale Henrichs <dhenrich(a)vmware.com<mailto:dhenrich@vmware.com>> wrote: Okay, okay.... I've been trying to keep a half dozen balls in the air for the last few weeks and what that means is that I don't give enough attention to any of them ... Pharo1.2 is close and Metacello is one of the bad boys with the failing tests sooooo, I am going to do a solo sprint this weekend: 1. a quick release of Metacello with expectedFailures for the tests that are failing in Pharo1.2. I have already fixed the tests (only test changes are needed), but I now need to port the Gofer changes to Squeak and GemStone which is a bigger job. A quick surgical set of expectedFailures is the best thing to do here. 2. in build #57 of Pharo1.2 I noticed some odd things that I want to track down... 3. I expect that some of the #57 issues can be revealed with the validator, so I am thinking that I will run the validator over all of the configurations that are used in Pharo1.2 and go about identify and/or fixing the meaningful issues that I find. My main goal will be to repair things that are broken, so I will be reluctant to make semantic changes without checking with the maintainers, but if the problem is really gruesome I will fix it and apologize later:) 4. I'm not going to spend a lot of time reading/writing email ... this will be a sprint not a coffee klatch. With that said, if you have a Metacello config issue that is related to Pharo1.2 drop me an email with your question/thought but don't be offended if I don't respond at all or just GRUNT in reply ... I may even take action without letting you know... 5. While working on the above task, I will work on the MetacelloBrowser adding menu items for the operations that I performso it will then be easier for other folks to perform the same types of jobs in the future. I may do something funky like hide the menu items behind a boolean so as not to pollute the menu items with a whole bunch of advanced type operations (that will be named poorly:)... I realize that I may be closing the barn door after the horse is gone - build 57 is yellow afterall - but cleaning up validation issues is long overdue. I don't plan on fixing Metacello bugs unless I find something that just begs to be fixed ... the sprint is mainly about running the validator and cleaning up the real nasty bits and track down the Metacello anomalies in #57... Dale

Feb. 27, 2011

Re: [Pharo-project] MessageNotUnderstood: LargePositiveInteger>>pixelValueForDepth:

by GermÃ¡n Arduino

Thanks Henry. 2011/2/26 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: > > GermÃ¡n Arduino wrote: >> >> mmm, may be is related with an old Cog version. >> >> Seems not happen with 2361. >> >> > > Yes, it is :) > > Cheers, > Henry > > -- > View this message in context: http://forum.world.st/MessageNotUnderstood-LargePositiveInteger-pixelValueF… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Feb. 27, 2011