- Pharo-dev - lists.pharo.org

[Pharo-project] [TODO] Issue tracker status

by Marcus Denker

Issues all together: 439 http://code.google.com/p/pharo/issues/list?can=2 Issues tagged 1.3: 9 (3 of which are tagged 1.4, too) http://code.google.com/p/pharo/issues/list?can=2&q=Milestone%3D1.3 Issues tagged 1.4: 39 (of which 1 toInclude, 11 to review) http://code.google.com/p/pharo/issues/list?can=2&q=Milestone%3D1.3 -- Marcus Denker -- http://marcusdenker.de

March 5, 2012

[Pharo-project] [update 1.4] #14374

by Marcus Denker

14374 ----- Issue 5434: deprecated MorphicTextEditor http://code.google.com/p/pharo/issues/detail?id=5434 Issue 5432: We should remove StratifiedProxy http://code.google.com/p/pharo/issues/detail?id=5432 Issue 5433: Unload package HostMenus http://code.google.com/p/pharo/issues/detail?id=5433 -- Marcus Denker -- http://marcusdenker.de

March 5, 2012

Re: [Pharo-project] Looking for a package to do some statistics in Pharo

by Marcus Denker

O >> > Thanks. > It's funny.. > btw, Marcus, is it really needed to update fetch script every time? > i beleive this related to gforge, where you placing the base image .. > Yes, we wanted to have a snap shot evey 20 upates and at least test part of the update process by updating that. (keep in mind that *everything* not tested will break, e.g. updating 1.4000 to the current for sure broke, as it's not tested). I changed it now, we now just update the last successful build directly from jenkins. But this means we need to save the artefacts somewhere in case we break something and have to go back... (but we will have that with the S3 uploader). Marcus -- Marcus Denker -- http://marcusdenker.de

March 5, 2012

Re: [Pharo-project] [ANN] Ideas for this year GSoC wanted

by askoh

Name: Search Indexing of Smalltalk image Level: Intermediate Possible mentor: Aik-Siong Koh Possible second mentor: Ian Chai Description All Smalltalk development environments can now search for implementors, senders or strings using brute force. The results are usually just listed alphabetically. This project will use search technology to index and page rank all the packages, classes, methods and comments in the image. Search results will be returned quickly and ranked intelligently. It will be a Search Engine for Smalltalk in Smalltalk. A search browser will be created to accept search strings and return columns of hits for packages, classes, methods and comments listed according to their page ranks. Time permitting, an autocompletion capability will be implemented to suggest relevant methods for code writing. The code will be made portable to all Smalltalk dialects. Technical Details The Anatomy of a Search Engine http://infolab.stanford.edu/~backrub/google.html Benefits to the Student The student will learn the important areas of search technology and object oriented programming. The student will experience creating something that is immediately useful to all Smalltalk programmers. Benefits to the Community Fast and intelligent search of Smalltalk code will help the community advance Smalltalk development even faster. Additional programming capabilities can be built on top of the search capabillities. -- View this message in context: http://forum.world.st/ANN-Ideas-for-this-year-GSoC-wanted-tp4434402p4445245… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 5, 2012

Re: [Pharo-project] Looking for a package to do some statistics in Pharo

by GastÃ³n Dall' Oglio

El 4 de marzo de 2012 22:38, Igor Stasenko <siguctua(a)gmail.com> escribiÃ³: > 2012/3/5 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com>: > > :) yes it's funny. Maybe in this video is not apreciated, but in projects > > where there are many developers, this presentation of a repository log > give > > a quick view of the dinamic of work. > > > I can say more. It make me feels like i given a birth to something, > which is then started to grow and bloom, > tended and honed by others. > This is very inspiring. My sincere thanks to you. > Thanks to you and the others developers of Pharo for your hard work :) > > But besides of sentiments, i don't think that such kind of > presentation is very informative to those who did not participated > directly. > Yes sure. > It serves to give an impression, but impression is not knowledge. Less > sentimental people need numbers :) > yes I agree. Regards. > > > > Regards. > > > > El 4 de marzo de 2012 19:11, Igor Stasenko <siguctua(a)gmail.com> > escribiÃ³: > > > >> 2012/3/3 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com>: > >> > > >> > > >> > El 3 de marzo de 2012 03:24, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > >> > escribiÃ³: > >> > > >> >> Stef, > >> >> > >> >> I think our banned troll is back :( > >> > > >> > > >> > hehe, no no, I lack the intelligence to be a good troll :) > >> > > >> > I misunderstood what Stef said, I understood that he wanted to make > >> > statistics about Pharo, more specifically on the development of Pharo. > >> > > >> > Anyway, if you're interested, this tool allows you to create funny > >> > animations log from a source repository. I made a simple animation > with > >> > the > >> > repository build pharo, with those commands: > >> > > >> > $ git clone git://gitorious.org/pharo-build/pharo-build.git > >> > $ gource -800x600 pharo-build > >> > > >> > and this is the generated video: > >> > > >> > http://vimeo.com/37856284 > >> > > >> Thanks. > >> It's funny.. > >> btw, Marcus, is it really needed to update fetch script every time? > >> i beleive this related to gforge, where you placing the base image .. > >> > >> > > >> > Regards. > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > > > > -- > Best regards, > Igor Stasenko. > >

March 5, 2012

Re: [Pharo-project] MVP

by Igor Stasenko

Bill, since you working on it, please consider following. Models & widgets: - all widgets which require a model/state, should require a specific protocol for communicating with them. - a "real" model object may not support given protocol directly, and for adapting it, there should be a model/value adaptors. >From design point of view, it means that widget implementation should be free of things like we see in PluggableXYZMorph, which turned into a storage of bunch of selectors and code into spahetti of UI logic and model logic. All widgets should just send messages to model in a form: model doSomething or model askSomething but not: model perform: myOnClickBigButtonSelector If there is not possible to connect widget and model directly, we should provide a model wrappers, which then could carry those numerous 'myOnClickBigButtonSelector' or block closures, connectors, whatever. Like that, a widget designer can clearly tell , what he wants from widget's model, what inputs his widget expects and rest is not of his concern. No any onClickSelector ifNil: [ yadda yadda ] ifNotNil: [ (model undestands: onClickSelector ) ifTrue: [ model perform: onClickSelector ] ].... this should be replaced by appropriate model adaptors, value holders etc , so widget may keep own code clean. We had discussions before, like why don't use blocks instead of selectors. And the answer was that it is easier to find implementors/navigate connections with symbols than blocks.. Which is true. Unless model(s) could have a built-in support for navigating and finding real guy behind the scenes, who responsible for taking actions etc. And i think this is much more appropriate than manually traverse through the hashes of selectors from a button nested into multiple levels of widgets, and models connected /nested in hierarchy too.. About layouts and layouts managers. It's kind of fine to have proportional layouts, but it doesn't solves all needs. Sometimes we want to "put it here" and "i don't give a shit about layouts". I dealt with nested layout since Delphi, and while they serve well most of the times, sometimes it is very hard to convince designed that his design is not really fits into out technical world, simply because you cannout "put it here" and designer "don't give a shit about layouts". :) So, people invented workarounds, like in modern browsers we have absolute/fixed/relative positioning and z-levels aka layers. Another approach is to control layout via anchors. I did some experiments with it not long ago, and i think it is quite promising, except that more thought needed how to organically merge this with traditional layouts. Anyways, here the link to original discussion: http://lists.gforge.inria.fr/pipermail/pharo-project/2011-April/046473.html (and somewhere there must be the code) On 5 February 2012 04:25, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > I'm still a little overwhelmed, but I see attention to layout; this has been > a BIG stumbling block for me in my efforts to bring MVP to Pharo.Â I > recommend using nested composite view/presenter pairs for most layout. > First, it lends itself well to an eventual view editor, and second, can be > surprisingly easy to code directly. > > Each composite view has a layout manager.Â Layouts include constrained > table-like elements, but the real workhorses are proportional layouts, which > can be set either horizontal or vertical.Â By nesting them, very complicate > behavior can be achieved. > > There, said "nesting," and that has been where I have fallen into trouble. > Pharo/morphic layout works great for children of the top level, but after > that, I can't get reliable results. > > Sleep calls... > > 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: Saturday, February 04, 2012 6:36 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] MVP > > Hello all, > > I have been to busy to read today, but I like seeing any discussion of > MVP.Â Â I am **slowly** working onÂ a framework for it, but wouldÂ be glad to > be beaten to it. > > Default models are key; they must be replaceable, but (sub)triads should > work "out of the box."Â Models can include value holders, value adapters, > converters, and contexts, depending on how they are wired. > > I have something of a start on the adapters and converters, which I can try > to package and make available.Â If nothing else, they will have value in > seeding discussion if not be directly usable.Â Â More to come. > > Bill > > > > -- Best regards, Igor Stasenko.

March 5, 2012

Re: [Pharo-project] Looking for a package to do some statistics in Pharo

by Igor Stasenko

2012/3/5 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com>: > :) yes it's funny. Maybe in this video is not apreciated, but in projects > where there are many developers, this presentation of a repository log give > a quick view of the dinamic of work. > I can say more. It make me feels like i given a birth to something, which is then started to grow and bloom, tended and honed by others. This is very inspiring. My sincere thanks to you. But besides of sentiments, i don't think that such kind of presentation is very informative to those who did not participated directly. It serves to give an impression, but impression is not knowledge. Less sentimental people need numbers :) > Regards. > > El 4 de marzo de 2012 19:11, Igor Stasenko <siguctua(a)gmail.com> escribiÃ³: > >> 2012/3/3 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com>: >> > >> > >> > El 3 de marzo de 2012 03:24, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >> > escribiÃ³: >> > >> >> Stef, >> >> >> >> Â I think our banned troll is back :( >> > >> > >> > hehe, no no, I lack the intelligence to be a good troll :) >> > >> > I misunderstood what Stef said, I understood that he wanted to make >> > statistics about Pharo, more specifically on the development of Pharo. >> > >> > Anyway, if you're interested, this tool allows you to create funny >> > animations log from a source repository. I made a simple animation with >> > the >> > repository build pharo, with those commands: >> > >> > $ git clone git://gitorious.org/pharo-build/pharo-build.git >> > $ gource -800x600 pharo-build >> > >> > and this is the generated video: >> > >> > http://vimeo.com/37856284 >> > >> Thanks. >> It's funny.. >> btw, Marcus, is it really needed to update fetch script every time? >> i beleive this related to gforge, where you placing the base image .. >> >> > >> > Regards. >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

March 5, 2012

Re: [Pharo-project] MVP

by Schwab,Wilhelm K

Ben, Great, but I'm still getting nipped by a DNU of #addGroupForPackage:. I found that no-oped in 1.4 so added it to 1.3 and was able to loadFull. It looks like great work, but I can't get anything to run in 1.3 or 1.4. Any ideas? Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Benjamin [benjamin.vanryseghem.pharo(a)gmail.com] Sent: Sunday, March 04, 2012 6:53 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] MVP Everything has been moved in ss3.gemstone.com/ss/Spec<http://ss3.gemstone.com/ss/Spec> :) Ben On Mar 5, 2012, at 12:47 AM, Schwab,Wilhelm K wrote: Ben, Ok, but I don't see it in either dirty experiments or the mc repository. Am I missing a ConfigurationOfSpec? Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Benjamin [benjamin.vanryseghem.pharo(a)gmail.com] Sent: Sunday, March 04, 2012 6:38 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] MVP I am kind of a middle of something right now, so my advice is really to use the configuration (moreover I have added a lot of packages) Keep me in touch, Ben On Mar 5, 2012, at 12:34 AM, Schwab,Wilhelm K wrote: Stef, I skimmed the documentation and attempted to load Spec-BenjaminVanRyseghem.34.mcz<http://www.squeaksource.com/DirtyExperiments/Spec-BenjaminVanRyseghem.34.mcz> into 1.3, but got an error and backed off. Any ideas? Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Sunday, February 05, 2012 2:56 AM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] MVP if you want to have a look at what we are doing with benjamin you can have a look at Spec Yesterday benjamin added inputField support and rewrote the changeSorter. Stef On Feb 5, 2012, at 3:28 AM, Schwab,Wilhelm K wrote: > More: > > proportional layouts need to let each view have a proportion (zero makes it fixed size) and splitters should be just another view that is added to a composite, following the horizontal/vertical nature of the layout manager. > > > > > From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] > Sent: Saturday, February 04, 2012 9:25 PM > To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > Subject: Re: [Pharo-project] MVP > > I'm still a little overwhelmed, but I see attention to layout; this has been a BIG stumbling block for me in my efforts to bring MVP to Pharo. I recommend using nested composite view/presenter pairs for most layout. First, it lends itself well to an eventual view editor, and second, can be surprisingly easy to code directly. > > Each composite view has a layout manager. Layouts include constrained table-like elements, but the real workhorses are proportional layouts, which can be set either horizontal or vertical. By nesting them, very complicate behavior can be achieved. > > There, said "nesting," and that has been where I have fallen into trouble. Pharo/morphic layout works great for children of the top level, but after that, I can't get reliable results. > > Sleep calls... > > Bill > > > > From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] > Sent: Saturday, February 04, 2012 6:36 PM > To: pharo-project(a)lists.gforge.inria.fr<mailto:pharo-project@lists.gforge.inria.fr> > Subject: [Pharo-project] MVP > > Hello all, > > I have been to busy to read today, but I like seeing any discussion of MVP. I am **slowly** working on a framework for it, but would be glad to be beaten to it. > > Default models are key; they must be replaceable, but (sub)triads should work "out of the box." Models can include value holders, value adapters, converters, and contexts, depending on how they are wired. > > I have something of a start on the adapters and converters, which I can try to package and make available. If nothing else, they will have value in seeding discussion if not be directly usable. More to come. > > Bill

March 5, 2012

Re: [Pharo-project] MVP

by Benjamin

Everything has been moved in ss3.gemstone.com/ss/Spec :) Ben On Mar 5, 2012, at 12:47 AM, Schwab,Wilhelm K wrote: > Ben, > > Ok, but I don't see it in either dirty experiments or the mc repository. Am I missing a ConfigurationOfSpec? > > Bill > > > > > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Benjamin [benjamin.vanryseghem.pharo(a)gmail.com] > Sent: Sunday, March 04, 2012 6:38 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] MVP > > I am kind of a middle of something right now, so my advice is really to use the configuration (moreover I have added a lot of packages) > > > Keep me in touch, > > Ben > > On Mar 5, 2012, at 12:34 AM, Schwab,Wilhelm K wrote: > >> Stef, >> >> I skimmed the documentation and attempted to load Spec-BenjaminVanRyseghem.34.mcz into 1.3, but got an error and backed off. >> >> Any ideas? >> >> 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: Sunday, February 05, 2012 2:56 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] MVP >> >> if you want to have a look at what we are doing with benjamin you can have a look at >> Spec >> >> Yesterday benjamin added inputField support and rewrote the changeSorter. >> >> Stef >> >> >> >> On Feb 5, 2012, at 3:28 AM, Schwab,Wilhelm K wrote: >> >> > More: >> > >> > proportional layouts need to let each view have a proportion (zero makes it fixed size) and splitters should be just another view that is added to a composite, following the horizontal/vertical nature of the layout manager. >> > >> > >> > >> > >> > 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: Saturday, February 04, 2012 9:25 PM >> > To: Pharo-project(a)lists.gforge.inria.fr >> > Subject: Re: [Pharo-project] MVP >> > >> > I'm still a little overwhelmed, but I see attention to layout; this has been a BIG stumbling block for me in my efforts to bring MVP to Pharo. I recommend using nested composite view/presenter pairs for most layout. First, it lends itself well to an eventual view editor, and second, can be surprisingly easy to code directly. >> > >> > Each composite view has a layout manager. Layouts include constrained table-like elements, but the real workhorses are proportional layouts, which can be set either horizontal or vertical. By nesting them, very complicate behavior can be achieved. >> > >> > There, said "nesting," and that has been where I have fallen into trouble. Pharo/morphic layout works great for children of the top level, but after that, I can't get reliable results. >> > >> > Sleep calls... >> > >> > 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: Saturday, February 04, 2012 6:36 PM >> > To: pharo-project(a)lists.gforge.inria.fr >> > Subject: [Pharo-project] MVP >> > >> > Hello all, >> > >> > I have been to busy to read today, but I like seeing any discussion of MVP. I am **slowly** working on a framework for it, but would be glad to be beaten to it. >> > >> > Default models are key; they must be replaceable, but (sub)triads should work "out of the box." Models can include value holders, value adapters, converters, and contexts, depending on how they are wired. >> > >> > I have something of a start on the adapters and converters, which I can try to package and make available. If nothing else, they will have value in seeding discussion if not be directly usable. More to come. >> > >> > Bill >> > >

March 4, 2012

Re: [Pharo-project] MVP

by Schwab,Wilhelm K

Ben, Ok, but I don't see it in either dirty experiments or the mc repository. Am I missing a ConfigurationOfSpec? Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Benjamin [benjamin.vanryseghem.pharo(a)gmail.com] Sent: Sunday, March 04, 2012 6:38 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] MVP I am kind of a middle of something right now, so my advice is really to use the configuration (moreover I have added a lot of packages) Keep me in touch, Ben On Mar 5, 2012, at 12:34 AM, Schwab,Wilhelm K wrote: Stef, I skimmed the documentation and attempted to load Spec-BenjaminVanRyseghem.34.mcz<http://www.squeaksource.com/DirtyExperiments/Spec-BenjaminVanRyseghem.34.mcz> into 1.3, but got an error and backed off. Any ideas? Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Sunday, February 05, 2012 2:56 AM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] MVP if you want to have a look at what we are doing with benjamin you can have a look at Spec Yesterday benjamin added inputField support and rewrote the changeSorter. Stef On Feb 5, 2012, at 3:28 AM, Schwab,Wilhelm K wrote: > More: > > proportional layouts need to let each view have a proportion (zero makes it fixed size) and splitters should be just another view that is added to a composite, following the horizontal/vertical nature of the layout manager. > > > > > From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] > Sent: Saturday, February 04, 2012 9:25 PM > To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > Subject: Re: [Pharo-project] MVP > > I'm still a little overwhelmed, but I see attention to layout; this has been a BIG stumbling block for me in my efforts to bring MVP to Pharo. I recommend using nested composite view/presenter pairs for most layout. First, it lends itself well to an eventual view editor, and second, can be surprisingly easy to code directly. > > Each composite view has a layout manager. Layouts include constrained table-like elements, but the real workhorses are proportional layouts, which can be set either horizontal or vertical. By nesting them, very complicate behavior can be achieved. > > There, said "nesting," and that has been where I have fallen into trouble. Pharo/morphic layout works great for children of the top level, but after that, I can't get reliable results. > > Sleep calls... > > Bill > > > > From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] > Sent: Saturday, February 04, 2012 6:36 PM > To: pharo-project(a)lists.gforge.inria.fr<mailto:pharo-project@lists.gforge.inria.fr> > Subject: [Pharo-project] MVP > > Hello all, > > I have been to busy to read today, but I like seeing any discussion of MVP. I am **slowly** working on a framework for it, but would be glad to be beaten to it. > > Default models are key; they must be replaceable, but (sub)triads should work "out of the box." Models can include value holders, value adapters, converters, and contexts, depending on how they are wired. > > I have something of a start on the adapters and converters, which I can try to package and make available. If nothing else, they will have value in seeding discussion if not be directly usable. More to come. > > Bill

March 4, 2012