September 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] New Pharo based on core 10446 - Win32 Installer

by Torsten Bergmann

see pharo download page or go directly to: http://gforge.inria.fr/frs/download.php/23175/setup_pharo1.0-10446-BETAdev0… -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

Sept. 11, 2009

Re: [Pharo-project] getting rid of these boring questions and popup

by Michael Roberts

i would be quite happy if the "this variable is not used" was picked up by a lint rule. the "your using this variable and you haven't yet assigned a value" is sometimes nice. however, if lint/slint/slime (?) had a nice permanent UI mechanism in the browser (i haven't checked) then I would get rid the former in preference of such a framework that can point out all sorts of useful things with the code when you accept methods. could then be package / context aware etc. Mike On Fri, Sep 11, 2009 at 6:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I would like what you think of these wonderful popups that try to help > to > write cool code but just get in my way: > Â Â Â Â "this variable is not used.... > Â Â Â Â you did not store into it.... > > Could we agree that we are adults? > and this is more a pain than anything else? > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 11, 2009

Re: [Pharo-project] New Pharo based on core 10446

by Ramiro Diaz Trepat

Yes ! It's great to have the package browser working again :) On Fri, Sep 11, 2009 at 6:10 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > cool thanks! > > On Sep 11, 2009, at 4:44 PM, Damien Cassou wrote: > > > http://pharo-project.org/pharo-download > > > > with refactorings in the package browser. > > > > -- > > Damien Cassou > > http://damiencassou.seasidehosting.st > > > > "Lambdas are relegated to relative obscurity until Java makes them > > popular by not having them." James Iry > > > > _______________________________________________ > > 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 >

Sept. 11, 2009

Re: [Pharo-project] An important infrastructural question

by StÃ©phane Ducasse

yeap! the life of real project.....been backward compatible Stef On Sep 11, 2009, at 10:04 PM, Dale Henrichs wrote: > GemStone (GLASS) will be writing and reading "old-style" mcz files > for the foreseeable future, so backward compatibility is important. > > Dale > ----- "Lukas Renggli" <renggli(a)gmail.com> wrote: > > | > - idea: we keep the * notation but we hook into the > | tools to > | > create real package. In particular the user could > | either explicitly > | > add a method extension > | > to a package or use the* notation. The end result > | should be the star > | > notation in the cat > | > and the use of a real package in the background. > | > | It would be nice if old packages could be imported and new ones > | merged > | and exported without problems. If a package is named "Foo", then its > | categories would be represented in Monticello as > | "Foo-OriginalCategoryName" and its protocols as > | "*foo-OriginalProtocolName". This would allow full compatibility. > | > | > platform could be a problem. So lukas do you if VW uses the > | * > | > convention, I imagine at least when > | > saving code? > | > | Yes, they use the same convention. Categories are not really visible > | in VW, but they are the same as on the Pharo side. The package name > | could actually be cropped from the protocol, but they strangely > don't > | do that and still display the *. > | > | Cheers, > | Lukas > | > | > | -- > | Lukas Renggli > | http://www.lukas-renggli.ch > | > | _______________________________________________ > | 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

Sept. 11, 2009

Re: [Pharo-project] An important infrastructural question

by StÃ©phane Ducasse

On Sep 11, 2009, at 9:33 PM, Lukas Renggli wrote: >> - idea: we keep the * notation but we hook into the >> tools to >> create real package. In particular the user could >> either explicitly >> add a method extension >> to a package or use the* notation. The end result >> should be the star >> notation in the cat >> and the use of a real package in the background. > > It would be nice if old packages could be imported and new ones merged > and exported without problems. If a package is named "Foo", then its > categories would be represented in Monticello as > "Foo-OriginalCategoryName" and its protocols as > "*foo-OriginalProtocolName". This would allow full compatibility. yes I believe that this is the way to go. (lot of hack in tools but necessary). If we do it well we will certainly improve the tools too. Because the notification should be a good support. >> platform could be a problem. So lukas do you if VW uses the * >> convention, I imagine at least when >> saving code? > > Yes, they use the same convention. Categories are not really visible > in VW, but they are the same as on the Pharo side. The package name > could actually be cropped from the protocol, but they strangely don't > do that and still display the *. Ok this is what I thought. We will do the same. > > Cheers, > Lukas > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 11, 2009

Re: [Pharo-project] icons in pluggablelistmorph

by Tudor Girba

Thanks Lukas. Indeed, it is straightforward :). I will give it a try. Cheers, Doru On 11 Sep 2009, at 20:28, Lukas Renggli wrote: >> I would like to specify an icon in a PluggableListMorph, but I cannot >> find my way :). Can anyone tell me how to do it? > > You need to create a subclass of PluggableListMorph and LazyListMorph, > override #listMorphClass in the PluggableListMorph to return the lazy > morph class, and override the method #display:atRow:on: in the > LazyListMorph subclass to customize the low-level drawing of the list > item. > > As you imagined all pretty simple and strait-forward, have a look at > the OB-Morphic for an example :-) > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

Sept. 11, 2009

Re: [Pharo-project] icons in pluggablelistmorph

by Tudor Girba

Hi Stef, The MorphTreeMorph widget of Alain follows a different design and already provides a straightforward way to deal with icons. I already use it for displaying trees in Glamour. But, that tree widget appears to be significantly slower for displaying simple lists. That is why I want to try with PluggableListMorph to see what can be done and with what performance. Cheers, Doru On 11 Sep 2009, at 20:40, StÃ©phane Ducasse wrote: > doru > > do you also need to do what lukas suggested with the tree of alain? > Is there a reason not to use it? > > Stef > On Sep 11, 2009, at 8:13 PM, Tudor Girba wrote: > >> Hi, >> >> I would like to specify an icon in a PluggableListMorph, but I cannot >> find my way :). Can anyone tell me how to do it? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "Problem solving efficiency grows with the abstractness level of >> problem understanding." >> >> >> >> >> _______________________________________________ >> 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 -- www.tudorgirba.com "Being happy is a matter of choice."

Sept. 11, 2009

Re: [Pharo-project] An important infrastructural question

by Dale Henrichs

GemStone (GLASS) will be writing and reading "old-style" mcz files for the foreseeable future, so backward compatibility is important. Dale ----- "Lukas Renggli" <renggli(a)gmail.com> wrote: | > Â Â Â Â Â Â Â Â - idea: we keep the * notation but we hook into the | tools to | > Â Â Â Â Â Â Â Â create real package. In particular the user could | either explicitly | > add a method extension | > Â Â Â Â Â Â Â Â to a package or use the* notation. The end result | should be the star | > notation in the cat | > Â Â Â Â Â Â Â Â and the use of a real package in the background. | | It would be nice if old packages could be imported and new ones | merged | and exported without problems. If a package is named "Foo", then its | categories would be represented in Monticello as | "Foo-OriginalCategoryName" and its protocols as | "*foo-OriginalProtocolName". This would allow full compatibility. | | > Â Â Â Â platform could be a problem. So lukas do you if VW uses the | * | > convention, I imagine at least when | > Â Â Â Â saving code? | | Yes, they use the same convention. Categories are not really visible | in VW, but they are the same as on the Pharo side. The package name | could actually be cropped from the protocol, but they strangely don't | do that and still display the *. | | Cheers, | Lukas | | | -- | Lukas Renggli | http://www.lukas-renggli.ch | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 11, 2009

Re: [Pharo-project] May be some problems with MC history

by Lukas Renggli

>> I don't understand what this has to do with change-sets? > > there is a menu item: 'add to changeset' and I wanted to generate a cs > for each of the commit > because I wanted to be able to reload the work in another image to test. Sorry, never used (or even encountered) that menu item before. > So thanks lukas. No problem ;-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 11, 2009

Re: [Pharo-project] An important infrastructural question

by Lukas Renggli

> Â Â Â Â Â Â Â Â - idea: we keep the * notation but we hook into the tools to > Â Â Â Â Â Â Â Â create real package. In particular the user could either explicitly > add a method extension > Â Â Â Â Â Â Â Â to a package or use the* notation. The end result should be the star > notation in the cat > Â Â Â Â Â Â Â Â and the use of a real package in the background. It would be nice if old packages could be imported and new ones merged and exported without problems. If a package is named "Foo", then its categories would be represented in Monticello as "Foo-OriginalCategoryName" and its protocols as "*foo-OriginalProtocolName". This would allow full compatibility. > Â Â Â Â platform could be a problem. So lukas do you if VW uses the * > convention, I imagine at least when > Â Â Â Â saving code? Yes, they use the same convention. Categories are not really visible in VW, but they are the same as on the Pharo side. The package name could actually be cropped from the protocol, but they strangely don't do that and still display the *. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 11, 2009