March 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Packages remodularization

by Mariano Martinez Peck

On Tue, Mar 2, 2010 at 12:13 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > We can use dashes in package names, however it's a little bit > confusing and Monticello cannot process it well if one package has > shorter name, for example Announcements and Announcements-View > Yes, I suffered that several times. In that case Announcements-View is interpreted as a subcategory in the package Announcements but not as a separate package Announcements-View > > -- Pavel > > On Tue, Mar 2, 2010 at 12:03 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > >> I only wanted to keep the the original package and don't use any dash > >> in the package name. Of course we can use your way. > > > > Aha ok, then this is fine of course. I don't care about the dashes. > > > > Lukas > > > >> > >> Cheers, > >> -- Pavel > >> > >> On Tue, Mar 2, 2010 at 11:50 AM, Lukas Renggli <renggli(a)gmail.com> > wrote: > >>>> SystemOrganization renameCategory: 'Announcements-Core' toBe: > 'Announcements'. > >>>> SystemOrganization renameCategory: 'Announcements-View' toBe: > >>>> 'AnnouncementsView'. > >>> > >>> Why can't this just be split into two packages 'Announcements-Core' > >>> and 'Announcements-View'? > >>> > >>> Furthermore, the code above looses all extension methods. For example > >>> 'Announcements-View' extends 'Announcement-Core' in the class > >>> Announcement. Maybe it would be safer to rename packages using the > >>> code we use in Seaside: > >>> > >>> renamePackage: oldPackageName to: newPackageName > >>> "self renamePackage: 'Seaside-Squeak-Development-Core' to: > >>> 'Seaside-Pharo-Development-Core'" > >>> > >>> | oldPackage newPackage oldWorkingCopy newWorkingCopy | > >>> oldPackage := PackageInfo named: oldPackageName. > >>> newPackage := PackageInfo named: newPackageName. > >>> > >>> " rename system categories " > >>> oldPackage systemCategories do: [ :oldCategory | > >>> | newCategory | > >>> newCategory := oldCategory allButFirst: oldPackage > systemCategoryPrefix size. > >>> Smalltalk organization renameCategory: oldCategory toBe: > newPackage > >>> systemCategoryPrefix , newCategory ]. > >>> > >>> " rename method categories " > >>> oldPackage extensionClasses do: [ :extensionClass | > >>> (oldPackage extensionCategoriesForClass: extensionClass) > do: [ :oldProtocol | > >>> | newProtocol | > >>> newProtocol := oldProtocol allButFirst: > oldPackage methodCategoryPrefix size. > >>> extensionClass organization renameCategory: > oldProtocol toBe: > >>> newPackage methodCategoryPrefix , newProtocol ] ]. > >>> > >>> " update monticello packages " > >>> oldWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: > oldPackageName). > >>> newWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: > newPackageName). > >>> newWorkingCopy repositoryGroup: oldWorkingCopy repositoryGroup; > modified: true. > >>> > >>> " test is all methos have been caught " > >>> oldPackage methods isEmpty > >>> ifTrue: [ oldWorkingCopy unload. PackageOrganizer > default > >>> unregisterPackage: oldPackage ] > >>> ifFalse: [ self error: 'Some code entities remain in the > old > >>> package, please migrate manually.' ] > >>> > >>> Otherwise, I completely agree with the proposed refactorings :-) > >>> > >>> 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 > >> > > > > > > > > -- > > 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 >

March 2, 2010

Re: [Pharo-project] Packages remodularization

by Pavel Krivanek

We can use dashes in package names, however it's a little bit confusing and Monticello cannot process it well if one package has shorter name, for example Announcements and Announcements-View -- Pavel On Tue, Mar 2, 2010 at 12:03 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> I only wanted to keep the the original package and don't use any dash >> in the package name. Of course we can use your way. > > Aha ok, then this is fine of course. I don't care about the dashes. > > Lukas > >> >> Cheers, >> -- Pavel >> >> On Tue, Mar 2, 2010 at 11:50 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >>>> SystemOrganization renameCategory: 'Announcements-Core' toBe: 'Announcements'. >>>> SystemOrganization renameCategory: 'Announcements-View' toBe: >>>> 'AnnouncementsView'. >>> >>> Why can't this just be split into two packages 'Announcements-Core' >>> and 'Announcements-View'? >>> >>> Furthermore, the code above looses all extension methods. For example >>> 'Announcements-View' extends 'Announcement-Core' in the class >>> Announcement. Maybe it would be safer to rename packages using the >>> code we use in Seaside: >>> >>> renamePackage: oldPackageName to: newPackageName >>> Â Â Â Â "self renamePackage: 'Seaside-Squeak-Development-Core' to: >>> 'Seaside-Pharo-Development-Core'" >>> >>> Â Â Â Â | oldPackage newPackage oldWorkingCopy newWorkingCopy | >>> Â Â Â Â oldPackage := PackageInfo named: oldPackageName. >>> Â Â Â Â newPackage := PackageInfo named: newPackageName. >>> >>> Â Â Â Â " rename system categories " >>> Â Â Â Â oldPackage systemCategories do: [ :oldCategory | >>> Â Â Â Â Â Â Â Â | newCategory | >>> Â Â Â Â Â Â Â Â newCategory := oldCategory allButFirst: oldPackage systemCategoryPrefix size. >>> Â Â Â Â Â Â Â Â Smalltalk organization renameCategory: oldCategory toBe: newPackage >>> systemCategoryPrefix , newCategory ]. >>> >>> Â Â Â Â " rename method categories " >>> Â Â Â Â oldPackage extensionClasses do: [ :extensionClass | >>> Â Â Â Â Â Â Â Â (oldPackage extensionCategoriesForClass: extensionClass) do: [ :oldProtocol | >>> Â Â Â Â Â Â Â Â Â Â Â Â | newProtocol | >>> Â Â Â Â Â Â Â Â Â Â Â Â newProtocol := oldProtocol allButFirst: oldPackage methodCategoryPrefix size. >>> Â Â Â Â Â Â Â Â Â Â Â Â extensionClass organization renameCategory: oldProtocol toBe: >>> newPackage methodCategoryPrefix , newProtocol ] ]. >>> >>> Â Â Â Â " update monticello packages " >>> Â Â Â Â oldWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: oldPackageName). >>> Â Â Â Â newWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: newPackageName). >>> Â Â Â Â newWorkingCopy repositoryGroup: oldWorkingCopy repositoryGroup; modified: true. >>> >>> Â Â Â Â " test is all methos have been caught " >>> Â Â Â Â oldPackage methods isEmpty >>> Â Â Â Â Â Â Â Â ifTrue: [ oldWorkingCopy unload. PackageOrganizer default >>> unregisterPackage: oldPackage ] >>> Â Â Â Â Â Â Â Â ifFalse: [ self error: 'Some code entities remain in the old >>> package, please migrate manually.' ] >>> >>> Otherwise, I completely agree with the proposed refactorings :-) >>> >>> 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 >> > > > > -- > 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 >

March 2, 2010

Re: [Pharo-project] Packages remodularization

by Lukas Renggli

> I only wanted to keep the the original package and don't use any dash > in the package name. Of course we can use your way. Aha ok, then this is fine of course. I don't care about the dashes. Lukas > > Cheers, > -- Pavel > > On Tue, Mar 2, 2010 at 11:50 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >>> SystemOrganization renameCategory: 'Announcements-Core' toBe: 'Announcements'. >>> SystemOrganization renameCategory: 'Announcements-View' toBe: >>> 'AnnouncementsView'. >> >> Why can't this just be split into two packages 'Announcements-Core' >> and 'Announcements-View'? >> >> Furthermore, the code above looses all extension methods. For example >> 'Announcements-View' extends 'Announcement-Core' in the class >> Announcement. Maybe it would be safer to rename packages using the >> code we use in Seaside: >> >> renamePackage: oldPackageName to: newPackageName >> Â Â Â Â "self renamePackage: 'Seaside-Squeak-Development-Core' to: >> 'Seaside-Pharo-Development-Core'" >> >> Â Â Â Â | oldPackage newPackage oldWorkingCopy newWorkingCopy | >> Â Â Â Â oldPackage := PackageInfo named: oldPackageName. >> Â Â Â Â newPackage := PackageInfo named: newPackageName. >> >> Â Â Â Â " rename system categories " >> Â Â Â Â oldPackage systemCategories do: [ :oldCategory | >> Â Â Â Â Â Â Â Â | newCategory | >> Â Â Â Â Â Â Â Â newCategory := oldCategory allButFirst: oldPackage systemCategoryPrefix size. >> Â Â Â Â Â Â Â Â Smalltalk organization renameCategory: oldCategory toBe: newPackage >> systemCategoryPrefix , newCategory ]. >> >> Â Â Â Â " rename method categories " >> Â Â Â Â oldPackage extensionClasses do: [ :extensionClass | >> Â Â Â Â Â Â Â Â (oldPackage extensionCategoriesForClass: extensionClass) do: [ :oldProtocol | >> Â Â Â Â Â Â Â Â Â Â Â Â | newProtocol | >> Â Â Â Â Â Â Â Â Â Â Â Â newProtocol := oldProtocol allButFirst: oldPackage methodCategoryPrefix size. >> Â Â Â Â Â Â Â Â Â Â Â Â extensionClass organization renameCategory: oldProtocol toBe: >> newPackage methodCategoryPrefix , newProtocol ] ]. >> >> Â Â Â Â " update monticello packages " >> Â Â Â Â oldWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: oldPackageName). >> Â Â Â Â newWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: newPackageName). >> Â Â Â Â newWorkingCopy repositoryGroup: oldWorkingCopy repositoryGroup; modified: true. >> >> Â Â Â Â " test is all methos have been caught " >> Â Â Â Â oldPackage methods isEmpty >> Â Â Â Â Â Â Â Â ifTrue: [ oldWorkingCopy unload. PackageOrganizer default >> unregisterPackage: oldPackage ] >> Â Â Â Â Â Â Â Â ifFalse: [ self error: 'Some code entities remain in the old >> package, please migrate manually.' ] >> >> Otherwise, I completely agree with the proposed refactorings :-) >> >> 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 > -- Lukas Renggli http://www.lukas-renggli.ch

March 2, 2010

Re: [Pharo-project] Packages remodularization

by Pavel Krivanek

Hi Lukas, I only wanted to keep the the original package and don't use any dash in the package name. Of course we can use your way. Cheers, -- Pavel On Tue, Mar 2, 2010 at 11:50 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >> SystemOrganization renameCategory: 'Announcements-Core' toBe: 'Announcements'. >> SystemOrganization renameCategory: 'Announcements-View' toBe: >> 'AnnouncementsView'. > > Why can't this just be split into two packages 'Announcements-Core' > and 'Announcements-View'? > > Furthermore, the code above looses all extension methods. For example > 'Announcements-View' extends 'Announcement-Core' in the class > Announcement. Maybe it would be safer to rename packages using the > code we use in Seaside: > > renamePackage: oldPackageName to: newPackageName > Â Â Â Â "self renamePackage: 'Seaside-Squeak-Development-Core' to: > 'Seaside-Pharo-Development-Core'" > > Â Â Â Â | oldPackage newPackage oldWorkingCopy newWorkingCopy | > Â Â Â Â oldPackage := PackageInfo named: oldPackageName. > Â Â Â Â newPackage := PackageInfo named: newPackageName. > > Â Â Â Â " rename system categories " > Â Â Â Â oldPackage systemCategories do: [ :oldCategory | > Â Â Â Â Â Â Â Â | newCategory | > Â Â Â Â Â Â Â Â newCategory := oldCategory allButFirst: oldPackage systemCategoryPrefix size. > Â Â Â Â Â Â Â Â Smalltalk organization renameCategory: oldCategory toBe: newPackage > systemCategoryPrefix , newCategory ]. > > Â Â Â Â " rename method categories " > Â Â Â Â oldPackage extensionClasses do: [ :extensionClass | > Â Â Â Â Â Â Â Â (oldPackage extensionCategoriesForClass: extensionClass) do: [ :oldProtocol | > Â Â Â Â Â Â Â Â Â Â Â Â | newProtocol | > Â Â Â Â Â Â Â Â Â Â Â Â newProtocol := oldProtocol allButFirst: oldPackage methodCategoryPrefix size. > Â Â Â Â Â Â Â Â Â Â Â Â extensionClass organization renameCategory: oldProtocol toBe: > newPackage methodCategoryPrefix , newProtocol ] ]. > > Â Â Â Â " update monticello packages " > Â Â Â Â oldWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: oldPackageName). > Â Â Â Â newWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: newPackageName). > Â Â Â Â newWorkingCopy repositoryGroup: oldWorkingCopy repositoryGroup; modified: true. > > Â Â Â Â " test is all methos have been caught " > Â Â Â Â oldPackage methods isEmpty > Â Â Â Â Â Â Â Â ifTrue: [ oldWorkingCopy unload. PackageOrganizer default > unregisterPackage: oldPackage ] > Â Â Â Â Â Â Â Â ifFalse: [ self error: 'Some code entities remain in the old > package, please migrate manually.' ] > > Otherwise, I completely agree with the proposed refactorings :-) > > 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 >

March 2, 2010

Re: [Pharo-project] Packages remodularization

by Lukas Renggli

> SystemOrganization renameCategory: 'Announcements-Core' toBe: 'Announcements'. > SystemOrganization renameCategory: 'Announcements-View' toBe: > 'AnnouncementsView'. Why can't this just be split into two packages 'Announcements-Core' and 'Announcements-View'? Furthermore, the code above looses all extension methods. For example 'Announcements-View' extends 'Announcement-Core' in the class Announcement. Maybe it would be safer to rename packages using the code we use in Seaside: renamePackage: oldPackageName to: newPackageName "self renamePackage: 'Seaside-Squeak-Development-Core' to: 'Seaside-Pharo-Development-Core'" | oldPackage newPackage oldWorkingCopy newWorkingCopy | oldPackage := PackageInfo named: oldPackageName. newPackage := PackageInfo named: newPackageName. " rename system categories " oldPackage systemCategories do: [ :oldCategory | | newCategory | newCategory := oldCategory allButFirst: oldPackage systemCategoryPrefix size. Smalltalk organization renameCategory: oldCategory toBe: newPackage systemCategoryPrefix , newCategory ]. " rename method categories " oldPackage extensionClasses do: [ :extensionClass | (oldPackage extensionCategoriesForClass: extensionClass) do: [ :oldProtocol | | newProtocol | newProtocol := oldProtocol allButFirst: oldPackage methodCategoryPrefix size. extensionClass organization renameCategory: oldProtocol toBe: newPackage methodCategoryPrefix , newProtocol ] ]. " update monticello packages " oldWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: oldPackageName). newWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: newPackageName). newWorkingCopy repositoryGroup: oldWorkingCopy repositoryGroup; modified: true. " test is all methos have been caught " oldPackage methods isEmpty ifTrue: [ oldWorkingCopy unload. PackageOrganizer default unregisterPackage: oldPackage ] ifFalse: [ self error: 'Some code entities remain in the old package, please migrate manually.' ] Otherwise, I completely agree with the proposed refactorings :-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 2, 2010

Re: [Pharo-project] Packages remodularization

by Pavel Krivanek

Hi, the new packages will be: - AnnouncementsView - EmergencyEvaluator - Kedama - Ffenestri - GraphicsSupport - UIManager - MultilingualSupport - Base64 - SystemSupport - Hashing - SerialPort - Settings here's the reorganization code. Of course you can use different package names. SystemOrganization renameCategory: 'Announcements-Core' toBe: 'Announcements'. SystemOrganization renameCategory: 'Announcements-View' toBe: 'AnnouncementsView'. Transcripter category: 'EmergencyEvaluator'. KedamaFloatArray category: 'Kedama'. SystemOrganization removeCategory: 'Exceptions-Extensions'. SystemOrganization renameCategory: 'Graphics-External-Ffenestri' toBe: 'Ffenestri'. SystemOrganization renameCategory: 'Graphics-Files' toBe: 'GraphicsSupport-Files'. SystemOrganization renameCategory: 'Graphics-Fonts' toBe: 'GraphicsSupport-Fonts'. SystemOrganization renameCategory: 'Graphics-Text' toBe: 'GraphicsSupport-Text'. Pen category: 'GraphicsSupport-Pen'. PenPointRecorder category: 'GraphicsSupport-Pen'. CornerRounder category: 'GraphicsSupport-Display Objects'. DisplayText category: 'GraphicsSupport-Display Objects'. MorphicTransform category: 'Morphic-Kernel'. BlockCannotReturn category: 'Exceptions-Kernel'. ArithmeticError category: 'Exceptions-Kernel'. FloatingPointException category: 'Exceptions-Kernel'. ProvideAnswerNotification category: 'UIManager-Support'. ProgressInitiationException category: 'UIManager-Support'. ProgressNotification category: 'UIManager-Support'. SystemOrganization renameCategory: 'Multilingual-Display' toBe: 'MultilingualSupport-Display'. SystemOrganization renameCategory: 'Multilingual-Editor' toBe: 'MultilingualSupport-Editor'. SystemOrganization renameCategory: 'Multilingual-Scanning' toBe: 'MultilingualSupport-Scanning'. MimeConverter category: 'Base64'. Base64MimeConverter category: 'Base64'. ValueHolder category: 'Kernel-ValueHolder'. StringHolder category: 'Kernel-ValueHolder'. SystemOrganization removeCategory: 'ST80-Kernel-Remnants'. SystemOrganization renameCategory: 'System-Applications' toBe: 'SystemSupport-Applications'. SystemOrganization renameCategory: 'System-Digital Signatures' toBe: 'SystemSupport-Digital Signatures'. SystemOrganization renameCategory: 'System-Download' toBe: 'SystemSupport-Download'. AbstractLauncher category: 'System-Launcher'. SystemOrganization renameCategory: 'System-Hashing-Core' toBe: 'Hashing-Core'. SystemOrganization renameCategory: 'System-Hashing-MD5' toBe: 'Hashing-MD5'. SystemOrganization renameCategory: 'System-Hashing-SHA1' toBe: 'Hashing-SHA1'. SystemOrganization renameCategory: 'System-Serial Port' toBe: 'SerialPort'. SystemOrganization renameCategory: 'Settings-Browser' toBe: 'Settings-Browser'. SystemOrganization renameCategory: 'System-Settings-Core' toBe: 'Settings-Core'. SystemOrganization renameCategory: 'System-Settings-Filter' toBe: 'Settings-Filter'. SystemOrganization renameCategory: 'System-Settings-Style' toBe: 'Settings-Style'. AbstractSoundSystem category: 'SystemSupport'. DummySoundSystem category: 'SystemSupport'. FontSubstitutionDuringLoading category: 'SystemSupport'. Imports category: 'SystemSupport'. MczInstaller category: 'SystemSupport'. RealEstateAgent category: 'SystemSupport'. SARInstaller category: 'SystemSupport'. SoundSettings category: 'SystemSupport'. SystemOrganization renameCategory: 'System-Tools' toBe: 'SystemSupport-Tools'. MethodReference category: 'System-Tools'. BreakPoint category: 'System-BreakPoints'. BreakpointManager category: 'System-BreakPoints'. UIManager category: 'UIManager'. ChangeSetCategory category: 'System-ChangeSetCategory'. ChangeSetCategoryWithParameters category: 'System-ChangeSetCategory'. ElementCategory category: 'System-ChangeSetCategory'. ObjectWithDocumentation category: 'System-ChangeSetCategory'. StaticChangeSetCategory category: 'System-ChangeSetCategory'. DebuggerMethodMap category: 'System-Debugging'. DebuggerMethodMapForBlueBookMethods category: 'System-Debugging'. DebuggerMethodMapForClosureCompiledMethods category: 'System-Debugging'. PointerFinder category: 'System-Debugging'. ThreadSafeTranscript category: 'Collections-Streams'. Cheers, -- Pavel On Tue, Mar 2, 2010 at 11:12 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Pavel > > May be we should start, you publish and I try to integrate changes one by one. > > Stef > > >> Hi, >> >> I collected information about classes present in the Pharo-Kernel and >> the result is the set of packages that are essential for Pharo. This >> is a list of this packages with some small reorganizations proposals. >> If the packages will be reorganized, the shrinking process will be >> start to be package-oriented and Pharo more modular. >> >> Announcements without Announcements-View category >> >> Collections without KedamaFloatArrayAbstract, Transcripter >> >> Compiler >> >> Exceptions (Exceptions-Extensions category is empty) >> >> Files >> >> Graphics: >> Â Â Â - Graphics-Display Objects without CornerRounder, DisplayText >> Â Â Â - Graphics-Primitives without Pen, PenPointRecorder >> Â Â Â - Graphics-Text (only class TextStyle) >> Â Â Â - Graphics-Transformations without MorphicTransform >> >> Kernel >> >> some classes should be moved to Exceptions package: >> - BlockCannotReturn >> - ArithmeticError >> - FloatingPointException >> >> some classes should be moved to a new UIManager package >> - ProvideAnswerNotification >> - ProgressInitiationException >> - ProgressNotification >> >> Multilingual: >> Â Â Â - Multilingual-Encodings >> Â Â Â - Multilingual-ImmPlugin >> Â Â Â - Multilingual-Languages >> Â Â Â - Multilingual-TextConversion >> >> some classes should be moved to a new Base64 package >> Â Â Â - MimeConverter >> Â Â Â - Base64MimeConverter >> >> ST80-Kernel-Remnants (ValueHolder, StringHolder) should have own >> package or to be part of the Kernel package >> >> System: >> Â Â Â - System-Change Notification (all classes) >> Â Â Â - System-Changes (all classes) >> Â Â Â - System-Clipboard (all classes) >> Â Â Â - System-Download (only AbstractLauncher) >> Â Â Â - System-FileRegistry (all classes) >> Â Â Â - System-Finalization (all classes) >> Â Â Â - System-Localization (all classes, at least for now ;-) >> Â Â Â - System-Object Events (all classes) >> Â Â Â - System-Object Storage (all classes) >> Â Â Â - System-Platforms (all classes) >> Â Â Â - System-Pools (all classes) >> Â Â Â - System-Support without AbstractSoundSystem, DummySoundSystem, >> FontSubstitutionDuringLoading, Imports, MczInstaller, RealEstateAgent, >> SARInstaller, SoundSettings >> Â Â Â - System-Tools only classes MethodReference, BreakPoint, BreakpointManager >> >> (better modularization of System package is welcome) >> >> ToolBuilder-Kernel: >> Â Â Â - UIManager class should be in standalone package, maybe together >> with DummyUIManager (currently not present in Pharo) >> >> Tools: >> Â Â Â - Tools-Changes >> Â Â Â Â Â Â Â - keep: ChangeSetCategory, ChangeSetCategoryWithParameters, >> ElementCategory, ObjectWithDocumentation, StaticChangeSetCategory >> Â Â Â Â Â Â Â - remove: ChangeList, ChangeListForProjects, ChangeSetBrowser, >> ChangeSorter, ClassCommentVersionsBrowser, DualChangeSorter, >> VersionsBrowser >> Â Â Â - Tools-Debugger >> Â Â Â Â Â Â Â - keep: DebuggerMethodMap, DebuggerMethodMapForBlueBookMethods, >> DebuggerMethodMapForClosureCompiledMethods, PointerFinder >> Â Â Â Â Â Â Â - remove: ContextVariablesInspector,. Debugger, MessageTally, >> PreDebugWindow, SyntaxError, TimeProfileBrowser >> Â Â Â - class ThreadSafeTranscript (could be moved to Collections-Streams, >> this class is a little bit Morphic dependent but this will be fixed) >> >> Traits >> >> >> It is very simple to change class categories however I suppose that to >> fight with MC and automatic updates will be a hell. So maybe we should >> prepare a simple reorganization script, upload new packages, prepare >> prebuild image and break update process here as several times in the >> past. The next step will be some reorganization of method categories. >> >> Cheers, >> -- Pavel >> >> _______________________________________________ >> 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 >

March 2, 2010

Re: [Pharo-project] Scamper revival

by Schwab,Wilhelm K

Squeak != Pharo. We're happy to interact, but the mission statement is more than just words. With respect to marginalization, I'm not writing portable web apps, which is exactly my point: web technologies have their purposes and limitations, and attempts to use them as some type of intergalactic-fix-all is probably going to work out poorly. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Eagle Offshore Sent: Monday, March 01, 2010 9:02 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Scamper revival Squeak - Pharo - same thing. I didn't say it would wipe out Smalltalk's place in the world - I said it will fulfill its mission - which is one more level of marginalization. At this point, it is easier to write a portable desktop app in a webkit based browser than it is to write one in Pharo. On Mar 1, 2010, at 4:20 AM, Schwab,Wilhelm K wrote: > First, I'm not using Squeak. Second, this is not the first time I've heard that xyz was going to wipe out Smalltalk's place in the world, and I doubt it will be the last. > > Bill > > > -----Original Message----- > From: Eagle Offshore [mailto:eagleoffshore@mac.com] > Sent: Monday, March 01, 2010 12:09 AM > To: Schwab,Wilhelm K > Subject: Re: [Pharo-project] Scamper revival > > Then what are you doing with Squeak? :-) The browsers support offline development with local databases in HTML 5. This is here, now. They will replace squeak's mission in about another three years. Probably less. > > On Feb 28, 2010, at 12:04 PM, Schwab,Wilhelm K wrote: > >> There is the further concern about the browser. It wastes screen space (which is at a premium) and adds weight and distracting functionality. There is something to be said for the a fat client app that does what it needs to do and nothing else. >> >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> Eagle Offshore >> Sent: Sunday, February 28, 2010 2:23 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Scamper revival >> >> I wouldn't be so sure. >> >> http://html5demos.com/ >> http://jqtouch.com/ >> >> On Feb 27, 2010, at 4:41 PM, Schwab,Wilhelm K wrote: >> >>> there is no way in hell that HTML+CSS+JavaScript is going to keep up >> >> >> _______________________________________________ >> 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

March 2, 2010

Re: [Pharo-project] Packages remodularization

by StÃ©phane Ducasse

Pavel May be we should start, you publish and I try to integrate changes one by one. Stef > Hi, > > I collected information about classes present in the Pharo-Kernel and > the result is the set of packages that are essential for Pharo. This > is a list of this packages with some small reorganizations proposals. > If the packages will be reorganized, the shrinking process will be > start to be package-oriented and Pharo more modular. > > Announcements without Announcements-View category > > Collections without KedamaFloatArrayAbstract, Transcripter > > Compiler > > Exceptions (Exceptions-Extensions category is empty) > > Files > > Graphics: > - Graphics-Display Objects without CornerRounder, DisplayText > - Graphics-Primitives without Pen, PenPointRecorder > - Graphics-Text (only class TextStyle) > - Graphics-Transformations without MorphicTransform > > Kernel > > some classes should be moved to Exceptions package: > - BlockCannotReturn > - ArithmeticError > - FloatingPointException > > some classes should be moved to a new UIManager package > - ProvideAnswerNotification > - ProgressInitiationException > - ProgressNotification > > Multilingual: > - Multilingual-Encodings > - Multilingual-ImmPlugin > - Multilingual-Languages > - Multilingual-TextConversion > > some classes should be moved to a new Base64 package > - MimeConverter > - Base64MimeConverter > > ST80-Kernel-Remnants (ValueHolder, StringHolder) should have own > package or to be part of the Kernel package > > System: > - System-Change Notification (all classes) > - System-Changes (all classes) > - System-Clipboard (all classes) > - System-Download (only AbstractLauncher) > - System-FileRegistry (all classes) > - System-Finalization (all classes) > - System-Localization (all classes, at least for now ;-) > - System-Object Events (all classes) > - System-Object Storage (all classes) > - System-Platforms (all classes) > - System-Pools (all classes) > - System-Support without AbstractSoundSystem, DummySoundSystem, > FontSubstitutionDuringLoading, Imports, MczInstaller, RealEstateAgent, > SARInstaller, SoundSettings > - System-Tools only classes MethodReference, BreakPoint, BreakpointManager > > (better modularization of System package is welcome) > > ToolBuilder-Kernel: > - UIManager class should be in standalone package, maybe together > with DummyUIManager (currently not present in Pharo) > > Tools: > - Tools-Changes > - keep: ChangeSetCategory, ChangeSetCategoryWithParameters, > ElementCategory, ObjectWithDocumentation, StaticChangeSetCategory > - remove: ChangeList, ChangeListForProjects, ChangeSetBrowser, > ChangeSorter, ClassCommentVersionsBrowser, DualChangeSorter, > VersionsBrowser > - Tools-Debugger > - keep: DebuggerMethodMap, DebuggerMethodMapForBlueBookMethods, > DebuggerMethodMapForClosureCompiledMethods, PointerFinder > - remove: ContextVariablesInspector,. Debugger, MessageTally, > PreDebugWindow, SyntaxError, TimeProfileBrowser > - class ThreadSafeTranscript (could be moved to Collections-Streams, > this class is a little bit Morphic dependent but this will be fixed) > > Traits > > > It is very simple to change class categories however I suppose that to > fight with MC and automatic updates will be a hell. So maybe we should > prepare a simple reorganization script, upload new packages, prepare > prebuild image and break update process here as several times in the > past. The next step will be some reorganization of method categories. > > Cheers, > -- Pavel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 2, 2010

Re: [Pharo-project] Packages remodularization

by StÃ©phane Ducasse

Thanks :) > It is very simple to change class categories however I suppose that to > fight with MC and automatic updates will be a hell. Yes but we should succeed :) but yes if will be probably difficult. > So maybe we should > prepare a simple reorganization script, upload new packages, prepare > prebuild image and break update process here as several times in the > past. The next step will be some reorganization of method categories. Stef > Hi, > > I collected information about classes present in the Pharo-Kernel and > the result is the set of packages that are essential for Pharo. This > is a list of this packages with some small reorganizations proposals. > If the packages will be reorganized, the shrinking process will be > start to be package-oriented and Pharo more modular. > > Announcements without Announcements-View category > > Collections without KedamaFloatArrayAbstract, Transcripter > > Compiler > > Exceptions (Exceptions-Extensions category is empty) > > Files > > Graphics: > - Graphics-Display Objects without CornerRounder, DisplayText > - Graphics-Primitives without Pen, PenPointRecorder > - Graphics-Text (only class TextStyle) > - Graphics-Transformations without MorphicTransform > > Kernel > > some classes should be moved to Exceptions package: > - BlockCannotReturn > - ArithmeticError > - FloatingPointException > > some classes should be moved to a new UIManager package > - ProvideAnswerNotification > - ProgressInitiationException > - ProgressNotification > > Multilingual: > - Multilingual-Encodings > - Multilingual-ImmPlugin > - Multilingual-Languages > - Multilingual-TextConversion > > some classes should be moved to a new Base64 package > - MimeConverter > - Base64MimeConverter > > ST80-Kernel-Remnants (ValueHolder, StringHolder) should have own > package or to be part of the Kernel package > > System: > - System-Change Notification (all classes) > - System-Changes (all classes) > - System-Clipboard (all classes) > - System-Download (only AbstractLauncher) > - System-FileRegistry (all classes) > - System-Finalization (all classes) > - System-Localization (all classes, at least for now ;-) > - System-Object Events (all classes) > - System-Object Storage (all classes) > - System-Platforms (all classes) > - System-Pools (all classes) > - System-Support without AbstractSoundSystem, DummySoundSystem, > FontSubstitutionDuringLoading, Imports, MczInstaller, RealEstateAgent, > SARInstaller, SoundSettings > - System-Tools only classes MethodReference, BreakPoint, BreakpointManager > > (better modularization of System package is welcome) > > ToolBuilder-Kernel: > - UIManager class should be in standalone package, maybe together > with DummyUIManager (currently not present in Pharo) > > Tools: > - Tools-Changes > - keep: ChangeSetCategory, ChangeSetCategoryWithParameters, > ElementCategory, ObjectWithDocumentation, StaticChangeSetCategory > - remove: ChangeList, ChangeListForProjects, ChangeSetBrowser, > ChangeSorter, ClassCommentVersionsBrowser, DualChangeSorter, > VersionsBrowser > - Tools-Debugger > - keep: DebuggerMethodMap, DebuggerMethodMapForBlueBookMethods, > DebuggerMethodMapForClosureCompiledMethods, PointerFinder > - remove: ContextVariablesInspector,. Debugger, MessageTally, > PreDebugWindow, SyntaxError, TimeProfileBrowser > - class ThreadSafeTranscript (could be moved to Collections-Streams, > this class is a little bit Morphic dependent but this will be fixed) > > Traits > > > It is very simple to change class categories however I suppose that to > fight with MC and automatic updates will be a hell. So maybe we should > prepare a simple reorganization script, upload new packages, prepare > prebuild image and break update process here as several times in the > past. The next step will be some reorganization of method categories. > > Cheers, > -- Pavel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 2, 2010

Re: [Pharo-project] Q: is there a way to get the classes referenced by a class?

by Mariano Martinez Peck

I found that very useful....I need it too, O2 too....shouldn't we add this to Class protocol ? On Tue, Mar 2, 2010 at 10:50 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Look the DependencyWalker of hernan morales. Look his class side method > extensions to Behavior. There is all you need > > cheers > > mariano > > > On Mon, Mar 1, 2010 at 9:28 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > >> Thank you, Miguel and Alexandre... I'm looking into it :) >> >> Cheers, >> Esteban >> >> On 2010-03-01 16:59:23 -0300, Alexandre Bergel >> <alexandre(a)bergel.eu> said: >> >> > >> > >> > Hi Esteban, >> > >> > I made a small extension of O2 that shows external dependencies. It is >> > not perfect, but I find it useful. I attached some screenshots. >> > The second screenshot shows that the package Network-Kernel has 6 >> > methods that references the package ToolBuilder-Kernel. >> > Right clicking on the mondrian node opens a menu that enable you to >> > browse the method. I use this tool to make sure I do not have any >> > unwanted dependencies. >> > >> > It works on PharoCore 1.1. To load it: >> > >> > #('DependencyView') >> > do: [:t | >> > | name | >> > name := 'ConfigurationOf', t. >> > Gofer new >> > squeaksource: 'MetacelloRepository'; >> > package: name; >> > load. >> > ((Smalltalk at: name asSymbol) project perform: #lastVersion) load >> ]. >> > >> > Cheers, >> > Alexandre >> > >> > >> > >> > <image> >> > >> > <image> >> > >> > >> > On 1 Mar 2010, at 15:58, Esteban Lorenzano wrote: >> > >> >> Hi, >> >> I'm trying to get a "dependency map" of a certain project (playing >> >> with >> >> pavel's kernel image, I'm trying to figure out how to feed it with all >> >> needed dependences). >> >> What I'm doing now is very inneficient (usign #allCallsOn and >> >> reversing >> >> the search), and I'm sure there should be something better... >> >> >> >> Thanks, >> >> Esteban >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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 >> > >

March 2, 2010