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

[Pharo-project] Fonts in Pharo

by Alexandre Bergel

Dear Gary and his team, I am truly delighted to see that a native font may be installed. This is really cool! Very snappy as well. I have a suggestion. Probably you though about it, but let me try :-) Each time I open an image, the cache is checked. I guess this is to prevent a change in the host OS. However, could the cache be checked only if the font saved in the image does not exist at startup? The cache could be explicitly checked when opening the font browser. I guess you though about it already, but just to make sure. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 10, 2009

Re: [Pharo-project] Tests are back to dark red :(

by Damien Cassou

On Tue, Feb 10, 2009 at 9:39 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > You can change this in "Administer", "Issue Tracking" by moving the > "Closed Issue Status Values" up to "Open Issue Status Values". Done, thank you Lukas -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 10, 2009

Re: [Pharo-project] Plugin organization

by Michael Rueger

nonono ;-) See earlier mails in this thread, this way you end up with the tests stored in the core package because e.g. Collections-Kernel also matches Collections-Kernel-Tests. michael On Tue, Feb 10, 2009 at 7:43 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> > > When I mentioned Seaside I was not thinking explicitly in terms of Top- > Purpose... > > What I like is that you have package but you have a kind of modules = > object-oriented > I would like to have > > Collections-Kernel > Collections-Kernel-Tests > Collections-Arrayed > Collections-Arrayed-Tests > > Network-Kernel > Network-Kernel-Tests > ... > > So that I can get all the packages with their tests if I want. > Also when I browse the package I see the tests and the other points > grouped togethe > > >> >> (Purpose-)Rest >> >> where >> >> Purpose = Tests, Examples, .. >> Rest = Kernel, Collections, Network, ... >> >> Note that this is the *package* structure (what you see in MC), not >> the class category structure. The latter could be more fine grained at >> the lower level (e.g., Tools-Debugger, Tools-Inspector, ... as it is >> structured now). >> >> The consequence would be that we have packages like >> >> Kernel >> Collections >> Tools >> ... >> Tests-Kernel >> Tests-Collections >> Tests-Tools >> >> I'm not convinced that this is the right structure, though, as we end >> up with lots of Test-xyz packages. >> >> As an alternative, I can imagine the package scheme >> >> Top-Rest >> >> where we have a very coarse grained Top level. For instance, we would >> have the following Top items: >> >> Kernel >> Graphics >> Libraries >> Tools >> Tests >> >> This means, we would have packages like >> >> Kernel-Numbers >> Kernel-Traits >> Kernel-Compiler >> ... >> Libraries-Collections >> Libraries-Regex >> Libraries-Network >> ... >> Tests-Kernel >> Tests-Libraries >> ... >> >> I'm curious if there are other ideas around. One way or the other, we >> need to clean this up. Right now it is a mess. E.g., there is a top >> level package MethodFinder, while all other tools are in the Tools >> package. > > > INdEeD > > :) > >> >> >> Cheers, >> Adrian >> >> >>> >>> >>> stef >>> >>> On Jan 31, 2009, at 10:51 AM, StÃ©phane Ducasse wrote: >>> >>>> I like the seaside organization >>>> >>>> Top-(Purpose-)(Platform-)Rest >>>> >>>> * Seaside-Canvas contains he canvas implementation. >>>> * Seaside-Squeak-Canvas contains the platform specific code of >>>> the canvas implementation. >>>> * Seaside-Examples-Canvas contains example code showing off the >>>> canvas implementation. >>>> * Seaside-Tests-Canvas contains the tests for the canvas >>>> implementation. >>>> * Seaside-Tests-Squeak-Canvas contains the platform specific >>>> tests of the canvas implementation. >>>> >>>> On Jan 30, 2009, at 3:54 PM, Adrian Lienhard wrote: >>>> >>>>> >>>>> On Jan 30, 2009, at 15:33 , Michael Rueger wrote: >>>>> >>>>>> StÃ©phane Ducasse wrote: >>>>>> >>>>>>> so what are the organizations we can use? >>>>>>> Ideally I would like to have the test associated with their >>>>>>> packages. >>>>>>> >>>>>>> XXX >>>>>>> XXXTests >>>>>> >>>>>> The problem with that naming scheme is that then the tests would >>>>>> always >>>>>> be loaded together with their tests because of the simple string >>>>>> matching Monticello does. >>>>>> Which isn't something you want when doing application/runtime >>>>>> builds. >>>>>> >>>>>> That's why I proposed the Plugin-* and Tests-* naming schemes. >>>>> >>>>> +1 >>>>> >>>>> Adrian >>>>> _______________________________________________ >>>>> 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 >

Feb. 10, 2009

[Pharo-project] 519: Can't pass a script to the VM

by Damien Cassou

http://code.google.com/p/pharo/issues/detail?id=519 -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 10, 2009

Re: [Pharo-project] Swazoo 2.2beta3 with class variable patch

by Hilaire Fernandes

It will be helpful to have small section at http://www.aidaweb.si/download.html explaining the steps needed to install on Pharo. Can I just take the AIDA package in Universe to do that now? Hilaire 2009/2/9 Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: > Hi Hilaire, > > Hilaire Fernandes pravi: > >> I am not sure to understand. Are you talking about something specific >> to use Swazoo on Pharo? > > Yes, there is a loading problem we discussed in this list a while ago > and it was caused by having one class variable mistakenly declared as > class instance variable. And because it is named uppercase, the > automatic code check before loading in Pharo failed (did I described > correctly?) > > Best regards > Janko > > > >> 2009/2/9 Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: >>> Hello, >>> >>> I just released new beta of Swazoo which has a problem with Singleton >>> class variable solved. >>> >>> Note also that two classes are renamed: Site to SwazooSite and Resource >>> to SwazooResource. I recommend to rename them manually before loading >>> this new beta over. Just in case. >>> >>> New beta is published to http://www.swazoosource.com/Swazoo.html . >>> >>> This beta is the last before final 2.2. release. If it will prove >>> reliable it will be released in few day. >>> >>> Best regards >>> Janko >>> >>> >>> -- >>> Janko MivÅ¡ek >>> AIDA/Web >>> Smalltalk Web Application Server >>> http://www.aidaweb.si >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > > -- > Janko MivÅ¡ek > Svetovalec za informatiko > Eranova d.o.o. > Ljubljana, Slovenija > www.eranova.si > tel: 01 514 22 55 > faks: 01 514 22 56 > gsm: 031 674 565 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://blog.ofset.org/hilaire

Feb. 10, 2009

Re: [Pharo-project] Tests are back to dark red :(

by Lukas Renggli

> what is bad with the google bug-tracker is that "verified" issues are not shown > anymore. One needs to explicitly search for them, wich in turn means they > are overlooked very quickly (I always forget to search for them). You can change this in "Administer", "Issue Tracking" by moving the "Closed Issue Status Values" up to "Open Issue Status Values". Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 10, 2009

Re: [Pharo-project] Tests are back to dark red :(

by StÃ©phane Ducasse

yes me too :) Stef On Feb 10, 2009, at 9:24 AM, Marcus Denker wrote: > On Tue, Feb 10, 2009 at 9:17 AM, Damien Cassou <damien.cassou(a)gmail.com > > wrote: >> On Mon, Feb 9, 2009 at 9:03 PM, Adrian Lienhard <adi(a)netstyle.ch> >> wrote: >>> An interesting test failure is [Wide]StringTest>>#testAsInteger >>> '-94' asInteger --> 94. I could trace this back to a change in >>> PositionableStream>>#back by Damien Cassous. Damien, could you >>> have a >>> look? >> >> Fixed, see: >> http://code.google.com/p/pharo/issues/detail?id=518 >> > what is bad with the google bug-tracker is that "verified" issues > are not shown > anymore. One needs to explicitly search for them, wich in turn means > they > are overlooked very quickly (I always forget to search for them). > > Marcus > > > -- > > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 10, 2009

Re: [Pharo-project] Tests are back to dark red :(

by Marcus Denker

On Tue, Feb 10, 2009 at 9:17 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Mon, Feb 9, 2009 at 9:03 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> An interesting test failure is [Wide]StringTest>>#testAsInteger >> '-94' asInteger --> 94. I could trace this back to a change in >> PositionableStream>>#back by Damien Cassous. Damien, could you have a >> look? > > Fixed, see: > http://code.google.com/p/pharo/issues/detail?id=518 > what is bad with the google bug-tracker is that "verified" issues are not shown anymore. One needs to explicitly search for them, wich in turn means they are overlooked very quickly (I always forget to search for them). Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Feb. 10, 2009

Re: [Pharo-project] Tests are back to dark red :(

by Damien Cassou

On Mon, Feb 9, 2009 at 9:03 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > An interesting test failure is [Wide]StringTest>>#testAsInteger > '-94' asInteger --> 94. I could trace this back to a change in > PositionableStream>>#back by Damien Cassous. Damien, could you have a > look? Fixed, see: http://code.google.com/p/pharo/issues/detail?id=518 -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 10, 2009

Re: [Pharo-project] Plugin organization

by StÃ©phane Ducasse

> When I mentioned Seaside I was not thinking explicitly in terms of Top- Purpose... What I like is that you have package but you have a kind of modules = object-oriented I would like to have Collections-Kernel Collections-Kernel-Tests Collections-Arrayed Collections-Arrayed-Tests Network-Kernel Network-Kernel-Tests ... So that I can get all the packages with their tests if I want. Also when I browse the package I see the tests and the other points grouped togethe > > (Purpose-)Rest > > where > > Purpose = Tests, Examples, .. > Rest = Kernel, Collections, Network, ... > > Note that this is the *package* structure (what you see in MC), not > the class category structure. The latter could be more fine grained at > the lower level (e.g., Tools-Debugger, Tools-Inspector, ... as it is > structured now). > > The consequence would be that we have packages like > > Kernel > Collections > Tools > ... > Tests-Kernel > Tests-Collections > Tests-Tools > > I'm not convinced that this is the right structure, though, as we end > up with lots of Test-xyz packages. > > As an alternative, I can imagine the package scheme > > Top-Rest > > where we have a very coarse grained Top level. For instance, we would > have the following Top items: > > Kernel > Graphics > Libraries > Tools > Tests > > This means, we would have packages like > > Kernel-Numbers > Kernel-Traits > Kernel-Compiler > ... > Libraries-Collections > Libraries-Regex > Libraries-Network > ... > Tests-Kernel > Tests-Libraries > ... > > I'm curious if there are other ideas around. One way or the other, we > need to clean this up. Right now it is a mess. E.g., there is a top > level package MethodFinder, while all other tools are in the Tools > package. INdEeD :) > > > Cheers, > Adrian > > >> >> >> stef >> >> On Jan 31, 2009, at 10:51 AM, StÃ©phane Ducasse wrote: >> >>> I like the seaside organization >>> >>> Top-(Purpose-)(Platform-)Rest >>> >>> * Seaside-Canvas contains he canvas implementation. >>> * Seaside-Squeak-Canvas contains the platform specific code of >>> the canvas implementation. >>> * Seaside-Examples-Canvas contains example code showing off the >>> canvas implementation. >>> * Seaside-Tests-Canvas contains the tests for the canvas >>> implementation. >>> * Seaside-Tests-Squeak-Canvas contains the platform specific >>> tests of the canvas implementation. >>> >>> On Jan 30, 2009, at 3:54 PM, Adrian Lienhard wrote: >>> >>>> >>>> On Jan 30, 2009, at 15:33 , Michael Rueger wrote: >>>> >>>>> StÃ©phane Ducasse wrote: >>>>> >>>>>> so what are the organizations we can use? >>>>>> Ideally I would like to have the test associated with their >>>>>> packages. >>>>>> >>>>>> XXX >>>>>> XXXTests >>>>> >>>>> The problem with that naming scheme is that then the tests would >>>>> always >>>>> be loaded together with their tests because of the simple string >>>>> matching Monticello does. >>>>> Which isn't something you want when doing application/runtime >>>>> builds. >>>>> >>>>> That's why I proposed the Plugin-* and Tests-* naming schemes. >>>> >>>> +1 >>>> >>>> Adrian >>>> _______________________________________________ >>>> 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 >

Feb. 10, 2009