June 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] 1.2 vision

by StÃ©phane Ducasse

I will ! Stef On Jun 30, 2010, at 4:15 PM, Pavel Krivanek wrote: > Hi, > > I added to the issue > http://code.google.com/p/pharo/issues/detail?id=2105 the > remodularization code, please look at it, it must split packages > Announcements, Graphics and Multilingual. In the mentioned example the > package named XXX cannot exist because it covers other packages. > > It would be absolutely amazing to have it integrated soon, than we > could continue on the methods level. > > Cheers, > -- Pavel > > On Tue, Jun 29, 2010 at 4:27 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> We should also clean the package naming structure >> >> XXX >> XXX-Core >> XXX-Test-Core >> XXX-Foo >> XXX-Test-Foo >> >> Stef >> >> On Jun 29, 2010, at 3:42 PM, StÃ©phane Ducasse wrote: >> >>> **Yes** I really want to come up with a pragma and to annotate tests to populate the help. >>> >>> >>> On Jun 27, 2010, at 10:45 AM, laurent laffont wrote: >>> >>>> + More HelpSystem. >>>> + MetacelloRepository GUI, newbies struggle to find a package, must be easy. >>>> >>>> Laurent >>>> >>>> On Sun, Jun 27, 2010 at 10:31 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> Hi all >>>> >>>> Of course we will integrate changes and changes and improvements.... now I believe that it would be nice to build a common >>>> vision. Here what I would like to get in 1.2. >>>> >>>> Now it does not mean that this is a definitive list and that we will have the energy to do all but like >>>> that you know that you can put energy do build this common vision :) >>>> >>>> - better infrastructure for integrating rb composite queries into the system >>>> The idea is to introduce a superclass on top of systemDictionary and to define there an API that >>>> is compatible with the one of RB (and potentially modified the one of RB) >>>> >>>> - another step towards using announcement for system notification >>>> >>>> - better tools for dev >>>> >>>> - have a look at the RB change model so that we could get a real undo and changes >>>> >>>> - clean Monticello so that package logic stays in package so that we can plug RPackage into the system. >>>> Right now this looks too brittle to do anything >>>> >>>> - make sure that we can have RPackage on the side of PakageInfo (we got really nice benchmark) >>>> >>>> - New Compiler in beta >>>> >>>> - Helvetia hooks >>>> >>>> - ROME API >>>> >>>> - Sophie Event Hierarchy >>>> >>>> - Define some architectural action to get the system more modular >>>> >>>> - Hudson infrastructure >>>> >>>> - metacello to manage core >>>> >>>> - metacelloRepository for 1.0/1.1/1.2 >>>> Gofer >>>> >>>> - squeak collection optimisation? >>>> >>>> - Alien >>>> >>>> Open points: >>>> >>>> - What do we do with ToolBuilder? Not clear to me. >>>> >>>> - What should be done at the level of polymorph? >>>> - What should be done a the level of Pluggable**** >>>> can we use the fact that we have now block closure to get it better. >>>> >>>> As you guess it will not come simply but this is important that we all head towards a common understanding >>>> >>>> >>>> Stef >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 30, 2010

Re: [Pharo-project] Annotated tests in help system

by StÃ©phane Ducasse

thanks! I will have a look. On Jun 30, 2010, at 4:11 PM, Torsten Bergmann wrote: > Stef wrote in thread "1.2 vision" >> for me this one is the key one :) > > Hi Stef, > > file in the attached file in 1.1./1.2 and then evaluate: > > HelpBrowser openOn: TestReference > > It's not perfect but I think it can serve > your example. Time is limited but you should easily get > the idea. Feel free to adopt it to your needs. > > "TestReference" is just a simple entry point > similar to existing "SystemReference". Work is done in > TestAPIHelpBuilder who queries the pragmas (#test:about:tag:) > and builds the topic structure. > > I still think written docu is better, but API help and > tests are better than nothing... > > Bye > T. > > > -- > GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. > Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl > <HelpSystem-HelpOnTests.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 30, 2010

Re: [Pharo-project] [SPAM] [ANN 1.1] pre-built RC3 Core

by StÃ©phane Ducasse

>> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > What is the development plan and timing for 1.1 ? > > I understand that there is some kind of feature freeze for 1.1 with all new stuff going into 1.2. > > How is beta testing in 1.1 supposed to happen ? The idea is that we were in beta phase over a month or a month and half. Then we went into releaseCandidates and now we are at releasecandidate3 We will only include showstoppers. > I don't see many people reporting issues on the mailing list vs 1.1 Indeed it is working (we migrated all our tools to 1.1 and it was working well). > My 1.1 (11400 rc2) image prints numbers on the transcript when doing certain editing (selection ?) operations. Yes apparently there is a Transcript show: somewhere and we should open a bug entry to chase it. The idea is to plan 1.2 for end of august or september depending on the amount of changes and apply the same alpha/beta/rc phases. Stef

June 30, 2010

Re: [Pharo-project] 1.2 vision

by Pavel Krivanek

Hi, I added to the issue http://code.google.com/p/pharo/issues/detail?id=2105 the remodularization code, please look at it, it must split packages Announcements, Graphics and Multilingual. In the mentioned example the package named XXX cannot exist because it covers other packages. It would be absolutely amazing to have it integrated soon, than we could continue on the methods level. Cheers, -- Pavel On Tue, Jun 29, 2010 at 4:27 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > We should also clean the package naming structure > > Â Â Â Â XXX > Â Â Â Â XXX-Core > Â Â Â Â XXX-Test-Core > Â Â Â Â XXX-Foo > Â Â Â Â XXX-Test-Foo > > Stef > > On Jun 29, 2010, at 3:42 PM, StÃ©phane Ducasse wrote: > >> **Yes** I really want to come up with a pragma and to annotate tests to populate the help. >> >> >> On Jun 27, 2010, at 10:45 AM, laurent laffont wrote: >> >>> + More HelpSystem. >>> + MetacelloRepository GUI, newbies struggle to find a package, must be easy. >>> >>> Laurent >>> >>> On Sun, Jun 27, 2010 at 10:31 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Hi all >>> >>> Of course we will integrate changes and changes and improvements.... now I believe that it would be nice to build a common >>> vision. Here what I would like to get in 1.2. >>> >>> Now it does not mean that this is a definitive list and that we will have the energy to do all but like >>> that you know that you can put energy do build this common vision :) >>> >>> Â Â Â - better infrastructure for integrating rb composite queries into the system >>> Â Â Â Â Â Â Â The idea is to introduce a superclass on top of systemDictionary and to define there an API that >>> Â Â Â Â Â Â Â is compatible with the one of RB (and potentially modified the one of RB) >>> >>> Â Â Â - another step towards using announcement for system notification >>> >>> Â Â Â - better tools for dev >>> >>> Â Â Â - have a look at the RB change model so that we could get a real undo and changes >>> >>> Â Â Â - clean Monticello so that package logic stays in package so that we can plug RPackage into the system. >>> Â Â Â Right now this looks too brittle to do anything >>> >>> Â Â Â - make sure that we can have RPackage on the side of PakageInfo (we got really nice benchmark) >>> >>> Â Â Â - New Compiler in beta >>> >>> Â Â Â - Helvetia hooks >>> >>> Â Â Â - ROME API >>> >>> Â Â Â - Sophie Event Hierarchy >>> >>> Â Â Â - Define some architectural action to get the system more modular >>> >>> Â Â Â - Hudson infrastructure >>> >>> Â Â Â - metacello to manage core >>> >>> Â Â Â - metacelloRepository for 1.0/1.1/1.2 >>> Â Â Â Â Â Â Â Gofer >>> >>> Â Â Â - squeak collection optimisation? >>> >>> Â Â Â - Alien >>> >>> Open points: >>> >>> Â Â Â - What do we do with ToolBuilder? Not clear to me. >>> >>> Â Â Â - What should be done at the level of polymorph? >>> Â Â Â Â Â Â Â - What should be done a the level of Pluggable**** >>> Â Â Â Â Â Â Â Â Â Â Â can we use the fact that we have now block closure to get it better. >>> >>> As you guess it will not come simply but this is important that we all head towards a common understanding >>> >>> >>> Stef >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 30, 2010

Re: [Pharo-project] CLFramework and Pharo

by laurent laffont

On Wed, Jun 30, 2010 at 3:55 PM, nullPointer <epicfan(a)gmail.com> wrote: > > >> I believe is best create another from scratch, > >> but with WPF like model and XAML > >> as UI definition language. That is for people with best knowledges. > > > > I'm not convinced that we cannot learn from your development. > > > Because is needed change the current exposition to something like that: > > http://www.youtube.com/watch?v=4-T-yF3tXCc&feature=related > http://www.youtube.com/watch?v=RyO7v06xlWM&feature=related > > Forget for a moment that is from M$ XD The wonderful of that is the > language > for define the UI interface, XAML, where you can describe not only basic > propertys of "morph" like colors or positions, but too animations, > mouseOver > effects, timers, movies... And you can use editors of XAML, external from > environment, for create more rich UIs. > I don't think WPF/XAML/whatever is good or bad (indeed I don't care :). But I think there's lot of value in having UIBuilder with "old mechanism" *now*. Do you think we can easily get it out of experimental / alpha state ? Or is there design/architecture mistakes such as thinking of creating applications with it is harmful ? For the future, something based on Morphic 3 isn't the right way ? Cheers, Laurent > The current UIBuilder is based on old mechanism for build views, and surely > with > a lot of errors. I believe that that is the best direction for something > more > new and correct. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 30, 2010

[Pharo-project] Annotated tests in help system

by Torsten Bergmann

Stef wrote in thread "1.2 vision" >for me this one is the key one :) Hi Stef, file in the attached file in 1.1./1.2 and then evaluate: HelpBrowser openOn: TestReference It's not perfect but I think it can serve your example. Time is limited but you should easily get the idea. Feel free to adopt it to your needs. "TestReference" is just a simple entry point similar to existing "SystemReference". Work is done in TestAPIHelpBuilder who queries the pragmas (#test:about:tag:) and builds the topic structure. I still think written docu is better, but API help and tests are better than nothing... Bye T. -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl

June 30, 2010

Re: [Pharo-project] [SPAM] [ANN 1.1] pre-built RC3 Core

by Sven Van Caekenberghe

On 30 Jun 2010, at 09:37, Marcus Denker wrote: > > https://gforge.inria.fr/frs/download.php/27218/PharoCore-1.1-11406-rc3.zip > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project What is the development plan and timing for 1.1 ? I understand that there is some kind of feature freeze for 1.1 with all new stuff going into 1.2. How is beta testing in 1.1 supposed to happen ? I don't see many people reporting issues on the mailing list vs 1.1 My 1.1 (11400 rc2) image prints numbers on the transcript when doing certain editing (selection ?) operations. Sven

June 30, 2010

Re: [Pharo-project] CLFramework and Pharo

by nullPointer

>> I believe is best create another from scratch, >> but with WPF like model and XAML >> as UI definition language. That is for people with best knowledges. > > I'm not convinced that we cannot learn from your development. Because is needed change the current exposition to something like that: http://www.youtube.com/watch?v=4-T-yF3tXCc&feature=related http://www.youtube.com/watch?v=RyO7v06xlWM&feature=related Forget for a moment that is from M$ XD The wonderful of that is the language for define the UI interface, XAML, where you can describe not only basic propertys of "morph" like colors or positions, but too animations, mouseOver effects, timers, movies... And you can use editors of XAML, external from environment, for create more rich UIs. The current UIBuilder is based on old mechanism for build views, and surely with a lot of errors. I believe that that is the best direction for something more new and correct.

June 30, 2010

Re: [Pharo-project] CLFramework and Pharo

by nullPointer

> I dont understand. If you dont know the difference why did you change > from MIT to BSD for CLFramework? No idea. I donÂ´t know the change but you has warning me. The license is already changed to MIT. > Yes that would be good to know about the reasons. We know that you > were not satisfied with your own code - but who of us really is? I believe the valid model for create a UIBUilder is implement something like WPF in paint technology ( use OpenGL for paint and have 3D elements ) and XAML build the UI in design time. I donÂ´t have knowledges for implement that, and I donÂ´t know if is possible implement something like that on Pharo-Smalltalk; but I believe that is needed for create something UIBuilder modern for Pharo-Smalltalk, and not based on old systems. But that task is for people with more knowledges.

June 30, 2010

Re: [Pharo-project] CLFramework and Pharo

by StÃ©phane Ducasse

On Jun 30, 2010, at 12:53 PM, nullPointer wrote: > > Regards > >> 3. I dont understand why the license changed from MIT to BSD but >> that does not allow us to include the now released version 90 or further >> work in the MIT licensed pharo-dev. > > > DonÂ´t exists problem for change the license. What differences exists between one > and other? there are equivalent: moose is developed under BSD on top of Pharo MIT Now we prefer all the pharo code to be MIT. > I expect a day in the life of Pharo where people will demand more support > to build >> visual tools. So to create a UI Builder the community > >> - either has to start from scratch then >> - or continue with the project as a fork based on an earlier version >> ("CLFramework-nullPointer.70.mcz" was the last one released as MIT) > > > I believe is best create another from scratch, but with WPF like model and XAML > as UI definition language. That is for people with best knowledges. I'm not convinced that we cannot learn from your development. > > The current version is 90. The main difference is addition of grid control. > > PS. IÂ´m wrong before and did send the answer directly your mail, excuse me. > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 30, 2010