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

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by StÃ©phane Ducasse

Ok I understand now and I agree. >>> An installer script or an mcm is not an option because that would >>> always load one fixed configuration. >> >> But this is not what you want when you do not use a Universe? > > Not not? I am confused ;-) > >>>> but this is not what we want when we do not use a universe. >>> >>> To be able to properly load Seaside a system that can handle >>> dependencies is a requirement. >> >> so I'm confused I thought that exactly mcm allow to specify exact >> version. > > mcm is a fixed, ordered set of exact package versions. If we wanted to > provide mcm files, we needed to create one for every combination of > swazoo/kom (2), tests yes/no (2), development tools yes/no (2), > scriptaculous yes/no (2), comet yes/no (2), rsrss yes/no (2), ... > Imagine, if we wanted to add Magritte and Pier to that. We would soon > end up with an infinite number of possible combinations, each encoded > in a different mcm file. > >> But Universe do not have the granularity for following all the small >> changes. I thought that for the people developing seaside daily >> you wanted either the latest or been able to go back to exactly one >> version >> of a set of components and there the exact version number is a must >> I do not see the numbering in dependency in Universe. > > Exactly, but Seaside users usually don't follow small changes. We > expect developers to know about the dependencies and be able to load > the packages manually. Furthermore, as soon as a version of the > packages is loaded, doing small updates through Monticello is usually > no big deal. > > There will be a universe for every release (including alpha and beta > releases). Seaside users have the possibility to update from one > release to the next. > >> So tell me because I do not understand. >> I also thought that Mcm was offering a fixed versions and could be >> used a >> fixed configmap >> We could extend it to support **load latest for this component** > > We tried to use mcm in the beginning. Unfortunately not even the > developers want a fixed set of packages, but have different focuses > and therefore different packages loaded. For example, I focus on > JavaScript, while Philippe on different encodings and server adapters, > ... > > So in Universe each package has a list of dependencies to other fixed > versions of packages (not strictly, but we use it like this). This > allows users to select the parts of Seaside they need (for example kom > server, no tests, development tools, scriptaculous support and pier). > And boom, Universe automatically builds an ordered list of package > versions to load. In this example the list would include the correct > versions of Magritte-Core and Magritte-Seaside, even if this was never > explicitly declared. > > Universes is easier for us, because we don't need to prepare all the > possible configurations a user wants. Users just select themselves > what they want and the system calculates the prerequisites. > > Now with MC2, the story is again completely different ... > > 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. 26, 2008

Re: [Pharo-project] Move to package from sender and implementors list

by Damien Cassou

On Thu, Sep 25, 2008 at 1:29 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > it would be great to have the senders and implementors tools > offering move to package in their menus. If you were using pharo-dev, the senders and implementors tools would be the ones of OB and you would not have these problems... Now that pharo-dev only contains a very small set of packages, I don't understand why you don't use it. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 26, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by Lukas Renggli

> > An installer script or an mcm is not an option because that would > > always load one fixed configuration. > > But this is not what you want when you do not use a Universe? Not not? I am confused ;-) > > > but this is not what we want when we do not use a universe. > > > > To be able to properly load Seaside a system that can handle > > dependencies is a requirement. > > so I'm confused I thought that exactly mcm allow to specify exact version. mcm is a fixed, ordered set of exact package versions. If we wanted to provide mcm files, we needed to create one for every combination of swazoo/kom (2), tests yes/no (2), development tools yes/no (2), scriptaculous yes/no (2), comet yes/no (2), rsrss yes/no (2), ... Imagine, if we wanted to add Magritte and Pier to that. We would soon end up with an infinite number of possible combinations, each encoded in a different mcm file. > But Universe do not have the granularity for following all the small > changes. I thought that for the people developing seaside daily > you wanted either the latest or been able to go back to exactly one version > of a set of components and there the exact version number is a must > I do not see the numbering in dependency in Universe. Exactly, but Seaside users usually don't follow small changes. We expect developers to know about the dependencies and be able to load the packages manually. Furthermore, as soon as a version of the packages is loaded, doing small updates through Monticello is usually no big deal. There will be a universe for every release (including alpha and beta releases). Seaside users have the possibility to update from one release to the next. > So tell me because I do not understand. > I also thought that Mcm was offering a fixed versions and could be used a > fixed configmap > We could extend it to support **load latest for this component** We tried to use mcm in the beginning. Unfortunately not even the developers want a fixed set of packages, but have different focuses and therefore different packages loaded. For example, I focus on JavaScript, while Philippe on different encodings and server adapters, ... So in Universe each package has a list of dependencies to other fixed versions of packages (not strictly, but we use it like this). This allows users to select the parts of Seaside they need (for example kom server, no tests, development tools, scriptaculous support and pier). And boom, Universe automatically builds an ordered list of package versions to load. In this example the list would include the correct versions of Magritte-Core and Magritte-Seaside, even if this was never explicitly declared. Universes is easier for us, because we don't need to prepare all the possible configurations a user wants. Users just select themselves what they want and the system calculates the prerequisites. Now with MC2, the story is again completely different ... Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 25, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by Keith Hodges

> > For me Universe is good when a complex program is ok for public > consumption not incremental > daily changes. > Do have a look at Sake/Packages equivalent to universes. You can define a package with non-specific versions, i.e. to load the latest seaside when keeping up with the bleeding edge. Packages beta load: 'Seaside'. Or you can define a specific definition based upon specific versions. Packages current load: 'Seaside'. Keith > So tell me because I do not understand. > I also thought that Mcm was offering a fixed versions and could be > used a fixed configmap > We could extend it to support **load latest for this component** > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 25, 2008

Re: [Pharo-project] Do you still need a Linux VM with FreeType?

by bryce＠kampjes.demon.co.uk

Igor Stasenko writes: > Hi Bryce, i'm already added platform source for linux. You can see it on > https://gforge.inria.fr/frs/?group_id=1299 > page. > I would appreciate if you help how to add dependency in linker (to > link with -lfreetype) , if plugin is compiled in. > Otherwise it require to change a makefile to complete a build. > Btw, same for B3DAcceleratorPlugin - it needs adding -lgl If you're trying to do Linux builds frequently you might want to look at VirtualBox or other virtualisation software. I'm using VirtualBox here to run Windows from Linux, according to the website, it should run Linux from Windows as well. It's free. Rebooting between OSes gets tedious fast. Bryce

Sept. 25, 2008

[Pharo-project] On Icons

by Torsten Bergmann

Matthew suggested >Perhaps OB could use composable icons Eclipse uses a similar concept, see http://www.eclipse.org/articles/Article-Decorators/decorators.html Typical icon sizes are 16x16 and 32x32 (at least on Win32 and in most icon collections on the web). The ones in OB currently look smaller and may be too small for decorators... Bye Torsten -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

Sept. 25, 2008

Re: [Pharo-project] Do you still need a Linux VM with FreeType?

by bryce＠kampjes.demon.co.uk

Marcus Denker writes: > > On 24.09.2008, at 23:16, <bryce(a)kampjes.demon.co.uk> <bryce(a)kampjes.demon.co.uk > > wrote: > > > > > I've stabilised the changes I was working on so now's a reasonable > > time for me to look at this if it's still required. Is it? > > > > > > For now, I just used the vm from the seaside package and copied all th > dll's in > from the freetype package. This seems to work... > > The recompiling gets really more important as soon as we go for > example for > Eliot's closure implementation... that I would want to have in as soon > as possible. OK, then my plan is this: 1) Build a VM dev environment with the latest mainstream source 2) Merge in Exupery 3) Add TrueType support 4) Automate the image build using Universes. (Probably starting with one of Damien's pharo-dev images) 4.5) Look at the makefiles (Igor's post) 5) Document the C setup 6) Review where I'm at 7) Review Eliot's closure impementation 8) Merge them assuming no problems My aim here is to make sure that the image used to build the VM is automatically buildable. I'll leave automating the C sources for later. This is where Exupery VM building currently is. Eliot's changes shouldn't effect build automation as I'll merge them into the Exupery VMMaker if they're acceptable. Exupery's VMMaker source is on SqueakSource Bryce P.S. Marcus, if you don't have the bitblit extensions then you'll not be getting sub-pixel aliasing. So with a re-built VM the fonts should look slightly nicer.

Sept. 25, 2008

[Pharo-project] [ANN] some cleans

by StÃ©phane Ducasse

I remove isUniClass: and clean the inspector following gary's clean. plus some leftOver related to uniclass. Stef

Sept. 25, 2008

Re: [Pharo-project] On Icons

by Matthew Fulmer

On Tue, Sep 23, 2008 at 10:54:08AM +0200, Lukas Renggli wrote: > On 9/23/08, Stï¿½phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Lukas another example: > > Here I was browsing some methods and suddenly there is cross: I said oops > > this method is an extension. > > And I did not have to click on *packageinfo-base because in the flow of my > > reading I was not looking > > for extensions per se. > > I agree, that's nice to see. However now the plus hides information > that is totally orthogonal to package extensions (inheritance). Perhaps OB could use composable icons, like MS Windows does with shortcuts: A little arrow icon representing "shortcut" superimposed on a big icon representing "content type" Many IDE's use an icon for every method or class. I think I don't like that, though. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

Sept. 25, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by StÃ©phane Ducasse

> An installer script or an mcm is not an option because that would > always load one fixed configuration. But this is not what you want when you do not use a Universe? >> but this is not what we want when we do not use a universe. > > To be able to properly load Seaside a system that can handle > dependencies is a requirement. so I'm confused I thought that exactly mcm allow to specify exact version. > To our knowledge, Universe is the only > system in Squeak/Pharo that can handle this task. > > If you do not like Universes you can always load the Monticello > packages manually following this graph: > <http://www.lukas-renggli.ch/dropbox/seaside-2.9/seaside.png>. Good > luck ;-) But Universe do not have the granularity for following all the small changes. I thought that for the people developing seaside daily you wanted either the latest or been able to go back to exactly one version of a set of components and there the exact version number is a must I do not see the numbering in dependency in Universe. For me Universe is good when a complex program is ok for public consumption not incremental daily changes. So tell me because I do not understand. I also thought that Mcm was offering a fixed versions and could be used a fixed configmap We could extend it to support **load latest for this component** Stef

Sept. 25, 2008