- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Plugin organization

by Michael Rueger

Alexandre Bergel wrote: >> 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. > > Is it a bad thing? > > <beReadyToShot> > To that extend, I was wondering why we have the TestCase class. > Ideally, I would like to have all the test methods coming along with > the domain. As I have for documentation and comment. When I browse > Lukas' code, the complete class hierarchy in the domain is duplicated > in the tests. When we wrote the tests of the collection, we duplicated > even method categories! > With all that said, feel free to shot :-) > </beReadyToShot > For "normal" development work the test code "pollutes" the work environment IMHO. It also would make it harder to deploy applications where you want to strip out the test code (or not load it in the first place). Michael

Feb. 10, 2009

[Pharo-project] [ANN][Dev-Images] February 2009 versions

by Damien Cassou

Hi, I've just uploaded new dev and web images based on Squeak3.9.1-7075, Squeak3.10.2-7179 and Pharo0.1-10231. More information and download: http://damiencassou.seasidehosting.st/Smalltalk/squeak-dev Pharo-based images can be downloaded at: http://code.google.com/p/pharo/wiki/Downloads?tm=2 Download statistics at http://damiencassou.dabbledb.com/publish/dev-imagesdownloads Changes in this version: --------------------------- - Pharo images are based on version 10231 - Polymorph fixes (by Gary Chambers) - OmniBrowser changes (by David RÃ¶thlisberger) - Refactored auto-selection of list items to be easier extensible - Extended and improved traits integration (various new features) - Integrated OB patches done by various people - Improved compatibility to Polymorph (button colors, scrollbars) - Several defects corrected - Magritte and Pier have been updated to version 1.1 (by Lukas Renggli and Tudor Girba) Contained packages: ------------------------ This image contains the following packages (some packages are only in the squeak-web image or 3.10-based images): Aida version 5.6 Algernon version 1.2 AST version 160 AutomaticMethodCategorizer version 0.25 AutomaticMethodCategorizerOB version 0.2 DynamicBindings version 2.7 eCompletion version 0.102 eCompletion-Traits version 0.1 eCompletionOmniBrowser version 0.5 Installer version 4.3.284 KomHttpServer version 7.0.30 KomServices version 1.12 Magritte-Model version 1.1.331 Magritte-Seaside version 1.1.283 Magritte-Tests version 1.1.148 OB-Enhancements version 0.292 OmniBrowser version 0.436 OmniBrowser-Algernon version 0.5 OmniBrowser-Full version 0.27 OmniBrowser-Morphic version 0.74 OmniBrowser-Refactory version 117 OmniBrowser-Regex version 0.9.1 OmniBrowser-Standard version 0.389 Pier version current Pier-Blog version 1.1.103 Pier-Documents version 1.1.7 Pier-EditorEnh version 1.1.17 Pier-Model version 1.1.263 Pier-Seaside version 1.1.331 Pier-Security version 1.1.119 Pier-Tests version 1.1.116 Polymorph EventEnhancements version 1.1 Polymorph Geometry version 1.1 Polymorph TaskbarIcons version 1.0 Polymorph ToolBuilder version 1.2 Polymorph Tools Diff version 1.3 Polymorph Widgets version 1.3 Refactoring Core version 17 RoelTyper version 0.60 RSRSS2 version 2.8.3.11 Scriptaculous version 2.8.3.242 ScriptManager version 0.6 Seaside version 2.8.3.572 Seaside-Adapters-Core version pmm.2.mcz Seaside-Adapters-Swazoo version 9 Seaside-Squeak-Adapters version pmm.3.mcz SeasideAdaptersCompatibility version pmm.1.mcz Shout version 3.15-tween.72 ShoutWorkspace version 1-tween.4 SmaCC runtime version 13 Sport version 2.31 Squeak dev packages version 0.27 Squeak dev packages beta version 0.32 Squeak web packages version 0.2 SUnit-improved version 4.0.118 SUnitGUI-improved version 4.0.50 Swazoo version 2.1 Universes version 51 Universes OmniBrowser version 0.38 VBRegex version 1.9 YAXO version 14 -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by David RÃ¶thlisberger

Hi Igor, > OB is quite complex thing, and its hard to understand what it does for > outsider :) > > I just identified a few points, which can improve rendering speed by a > certain amount: [...] > - default. > 60 ms > > - with override in SystemWindow>>drawDropShadowOn: aCanvas to do nothing: > 51 ms > > - with override in OBMonticelloPackageNode>>classCategories to return > cached collection > 45 ms > I incorporated into OB a patch that is following your idea concerning caching of class cats in package nodes. I did it differently than you but the results are even better now. Can you take care of integrating the SystemWindow patch into Pharo? Thanks, David

Feb. 10, 2009

Re: [Pharo-project] Plugin organization

by Alexandre Bergel

> 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. Is it a bad thing? <beReadyToShot> To that extend, I was wondering why we have the TestCase class. Ideally, I would like to have all the test methods coming along with the domain. As I have for documentation and comment. When I browse Lukas' code, the complete class hierarchy in the domain is duplicated in the tests. When we wrote the tests of the collection, we duplicated even method categories! With all that said, feel free to shot :-) </beReadyToShot > Alexandre > > > 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 10, 2009

[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