- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Plugin organization

by StÃ©phane Ducasse

> > I feel the same about it. Also I don't particularly like the solution > with the space, and/or camel case labels (like "Collections- > KernelDropTests"). Michael, what would you suggest as a scheme? How > about the following solution I suggested in a previous mail? > > Kernel-Numbers > Kernel-Traits > Kernel-Compiler > ... > Libraries-Collections > Libraries-Regex > Libraries-Network > ... > Tests-Kernel > Tests-Libraries > ... > > In the class categories we could still have a fine-grained structure > for tests, like > > Tests-Kernel-Numbers > Tests-Kernel-Traits > Tests-Libraries-Collections > ... > > Like this we have sort of a "tests close to the code" since the last > part, e.g., "Libraries-Collections" would match the category structure > of the implementation. Basically it's just that we prefix the > categories with "Test-" and that we have a coarse Top level structure. > Stef, wouldn't that also (partly) satisfy your wish of organizing > tests close to the code? I do not like it but it looks like the best compromise with the tools we have right now For me it goes against OOP and encapsulation but....there is a pattern matching ugly trick. Stef

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by StÃ©phane Ducasse

> >>> >>> > > I can implement such method, but concerning integration - i'm not in > charge here :) Our motto is if code is there and people agree this is integrated :) So go :) > > > What is interesting about shadows, that by default a shadow offset is > 1 pixel wide: > shadowOffset: 1@1 > > this means that unless you using magnifying glass on you display, you > can't really tell if there shadow drawn or not. > Since visual difference is minimal, do anyone can tell, why wasting so > much CPU cycles on it? :) sounds small indeed. Stef > > > >> Thanks, >> David >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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] Plugin organization

by Michael Rueger

Adrian Lienhard wrote: > KernelDropTests"). Michael, what would you suggest as a scheme? How > about the following solution I suggested in a previous mail? IIRC that was exactly what I suggested as well :-) So I'm all for it :-) Michael > > Kernel-Numbers > Kernel-Traits > Kernel-Compiler > ... > Libraries-Collections > Libraries-Regex > Libraries-Network > ... > Tests-Kernel > Tests-Libraries > ... > > In the class categories we could still have a fine-grained structure > for tests, like > > Tests-Kernel-Numbers > Tests-Kernel-Traits > Tests-Libraries-Collections > ... > > Like this we have sort of a "tests close to the code" since the last > part, e.g., "Libraries-Collections" would match the category structure > of the implementation. Basically it's just that we prefix the > categories with "Test-" and that we have a coarse Top level structure. > Stef, wouldn't that also (partly) satisfy your wish of organizing > tests close to the code? > > Adrian > >> >> Michael >> >> _______________________________________________ >> 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

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

by Bill Schwab

Damien, Is there a Pharo-web link? Apologies if I'm missing the obvious. Thanks! Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> damien.cassou(a)gmail.com 02/10/09 5:57 AM >>> 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 _______________________________________________ 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] Plugin organization

by Adrian Lienhard

On Feb 10, 2009, at 13:26 , Michael Rueger wrote: > StÃ©phane Ducasse wrote: >> On Feb 10, 2009, at 10:33 AM, Michael Rueger 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. >> >> but if Collections-Kernel-Tests is a package then it will not be >> stored. > > Its contents will be stored in Collections-Kernel because of the way > Monticello defines package contents by name matching. > >> Then why having tests close to the code is a problem >> I could do >> >> Collections-Kernel dropTests >> et voila! > > It might be just my personal work style/habit, but if I'm "using" a > package I don't want to have the tests in my work environment. Less > stuff, less clutter, less distraction. > Also searching for senders etc is made harder because of all the > usages > in test classes show up as well. I feel the same about it. Also I don't particularly like the solution with the space, and/or camel case labels (like "Collections- KernelDropTests"). Michael, what would you suggest as a scheme? How about the following solution I suggested in a previous mail? Kernel-Numbers Kernel-Traits Kernel-Compiler ... Libraries-Collections Libraries-Regex Libraries-Network ... Tests-Kernel Tests-Libraries ... In the class categories we could still have a fine-grained structure for tests, like Tests-Kernel-Numbers Tests-Kernel-Traits Tests-Libraries-Collections ... Like this we have sort of a "tests close to the code" since the last part, e.g., "Libraries-Collections" would match the category structure of the implementation. Basically it's just that we prefix the categories with "Test-" and that we have a coarse Top level structure. Stef, wouldn't that also (partly) satisfy your wish of organizing tests close to the code? Adrian > > > Michael > > _______________________________________________ > 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] Plugin organization

by StÃ©phane Ducasse

On Feb 10, 2009, at 1:26 PM, Michael Rueger wrote: > StÃ©phane Ducasse wrote: >> On Feb 10, 2009, at 10:33 AM, Michael Rueger 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. >> >> but if Collections-Kernel-Tests is a package then it will not be >> stored. > > Its contents will be stored in Collections-Kernel because of the way > Monticello defines package contents by name matching. Ah yes shit. I hate this pattern matching. Now can we have the same as in Seaside. I imgaine that they have several package with non matching names. > 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. > > >> Then why having tests close to the code is a problem >> I could do >> >> Collections-Kernel dropTests >> et voila! > > It might be just my personal work style/habit, but if I'm "using" a > package I don't want to have the tests in my work environment. Less > stuff, less clutter, less distraction. > Also searching for senders etc is made harder because of all the > usages > in test classes show up as well. but then you miss the point of tests been an active documentation. Then we could really have dropTest process. Else the real pain is that we will have to synchronise tests and package and there is nothing less useful than to have tests that are not in sync with a package > > > Michael > > _______________________________________________ > 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] Plugin organization

by Michael Rueger

StÃ©phane Ducasse wrote: > On Feb 10, 2009, at 10:33 AM, Michael Rueger 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. > > but if Collections-Kernel-Tests is a package then it will not be stored. Its contents will be stored in Collections-Kernel because of the way Monticello defines package contents by name matching. > Then why having tests close to the code is a problem > I could do > > Collections-Kernel dropTests > et voila! It might be just my personal work style/habit, but if I'm "using" a package I don't want to have the tests in my work environment. Less stuff, less clutter, less distraction. Also searching for senders etc is made harder because of all the usages in test classes show up as well. Michael

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by Igor Stasenko

2009/2/10 David RÃ¶thlisberger <squeak(a)webcitas.ch>: > 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. > Great! In my patch i didn't care about correctness or whatever, it was simply to outline what possible can be done to improve rendering speed. > Can you take care of integrating the SystemWindow patch into Pharo? > you mean override of SystemWindow>>drawDropShadowOn: ? Its not really correct override. Shadow should be drawn, if it there. And by default , to draw shadow, it using Morph>>drawOn: method with special shadow canvas. For system window it means that a rectangular area with dimensions of morph is filled with shadow color, shifted by shadowOffset. To improve its speed, we could clip a shadow rectangle to not visit pixels which is covered my system window contents, only pixels which are outside of it and 'dropping' shadow. I can implement such method, but concerning integration - i'm not in charge here :) What is interesting about shadows, that by default a shadow offset is 1 pixel wide: shadowOffset: 1@1 this means that unless you using magnifying glass on you display, you can't really tell if there shadow drawn or not. Since visual difference is minimal, do anyone can tell, why wasting so much CPU cycles on it? :) > Thanks, > David > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Feb. 10, 2009

Re: [Pharo-project] Plugin organization

by StÃ©phane Ducasse

On Feb 10, 2009, at 10:33 AM, Michael Rueger 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. but if Collections-Kernel-Tests is a package then it will not be stored. Then why having tests close to the code is a problem I could do Collections-Kernel dropTests et voila! Stef > > > 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 >

Feb. 10, 2009

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

by StÃ©phane Ducasse

Tx On Feb 10, 2009, at 10:28 AM, Damien Cassou wrote: > http://code.google.com/p/pharo/issues/detail?id=519 > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > 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