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

Re: [Pharo-project] Fwd: about setting and preference.

by StÃ©phane Ducasse

On Aug 27, 2009, at 3:13 PM, Lukas Renggli wrote: >> - A setting with value is an instance of SettingValue or of one of >> its >> subclasses. Such a setting holds a useful global system parameter and >> is made persistent: it is stored in a class variable which is >> initialized by the method that declares the setting. > > I think the problem with this proposal is that it mixes the model (the > value of the setting) and the meta-model (the model of the setting). can you show me where? because alain payed attention that we do not have the dependency with > This is problematic because then all code depends on the settings > package and when reading/writing settings application code must be > aware of the indirection introduced through the setting. I see. Let us reply alain and we talk about that at ESUG satruday or sunday. > Why isn't a setting simply a variable local to the package, and the > setting-description a separate object (method) that can also be > packaged separately? it is. Normally alain is transforming all preferences into class variable of the package then I imagine that we should describe the setting so that a browser can browse and change the value of the setting. The flow should be local to the class and not going via a global like Preference. So probably the setting description should be class extension. But there is something I should understand deeper. > > 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

Aug. 27, 2009

Re: [Pharo-project] FW: New Pharo based on core 10418

by Damien Cassou

On Thu, Aug 27, 2009 at 3:39 PM, Schwab,Wilhelm K<bschwab(a)anest.ufl.edu> wrote: > Sorry about the delay, but first things first: does "University Parking" mean anything to anyone? Â Its right up there with congressional ethics. Â With that problem averted I started over and easily reproduced the problem. Â This is on xp: > > 1) put the vm and Pharo beta image and changes in a folder > 2) using exploder, drag the image over the vm > 3) no need to change any preferences > 4) click on the Pharo desktop, open a browser > 5) select the first category, class and method you see > 6) "right click" in the source pane; the another bug I had > Â to use the mouse wheel to get a response > 7) The promised walkback should appear instead of the menu > > Sorry if this is a false alarm, but I can't see what I could be doing wrong. Fixed in Name: OB-Standard-DaminCassou.430 Author: DaminCassou Time: 27 August 2009, 4:03:30 pm UUID: e7454654-3dad-4520-a7d1-59c87b2b2908 Ancestors: OB-Standard-DamienCassou.429 - Adds OBTextSelection>>isClassNode and #isMethodNode -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 27, 2009

Re: [Pharo-project] FW: New Pharo based on core 10418

by Schwab,Wilhelm K

Damien, Sorry about the delay, but first things first: does "University Parking" mean anything to anyone? Its right up there with congressional ethics. With that problem averted I started over and easily reproduced the problem. This is on xp: 1) put the vm and Pharo beta image and changes in a folder 2) using exploder, drag the image over the vm 3) no need to change any preferences 4) click on the Pharo desktop, open a browser 5) select the first category, class and method you see 6) "right click" in the source pane; the another bug I had to use the mouse wheel to get a response 7) The promised walkback should appear instead of the menu Sorry if this is a false alarm, but I can't see what I could be doing wrong. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Thursday, August 27, 2009 8:16 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] FW: New Pharo based on core 10418 Damien, It wasn't hard, but I wonder whether I might have changed the default browser. Is there a way to determine the current setting for that? I will try to repeat the process later this AM. Bill -----Original Message----- From: Damien Cassou [mailto:damien.cassou@gmail.com] Sent: Thursday, August 27, 2009 6:04 AM To: Schwab,Wilhelm K Subject: Re: [Pharo-project] New Pharo based on core 10418 On Wed, Aug 26, 2009 at 8:31 PM, Schwab,Wilhelm K<bschwab(a)anest.ufl.edu> wrote: > Right clicking in the browsers gives the #isClassNode and then #isMethodNode walkbacks. Hi Bill, could you please detail me the process to reproduce? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 27, 2009

[Pharo-project] FW: New Pharo based on core 10418

by Schwab,Wilhelm K

Damien, It wasn't hard, but I wonder whether I might have changed the default browser. Is there a way to determine the current setting for that? I will try to repeat the process later this AM. Bill -----Original Message----- From: Damien Cassou [mailto:damien.cassou@gmail.com] Sent: Thursday, August 27, 2009 6:04 AM To: Schwab,Wilhelm K Subject: Re: [Pharo-project] New Pharo based on core 10418 On Wed, Aug 26, 2009 at 8:31 PM, Schwab,Wilhelm K<bschwab(a)anest.ufl.edu> wrote: > Right clicking in the browsers gives the #isClassNode and then #isMethodNode walkbacks. Hi Bill, could you please detail me the process to reproduce? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 27, 2009

Re: [Pharo-project] Fwd: about setting and preference.

by Lukas Renggli

> - A setting with value is an instance of SettingValue or of one of its > subclasses. Such a setting holds a useful global system parameter and > is made persistent: it is stored in a class variable which is > initialized by the method that declares the setting. I think the problem with this proposal is that it mixes the model (the value of the setting) and the meta-model (the model of the setting). This is problematic because then all code depends on the settings package and when reading/writing settings application code must be aware of the indirection introduced through the setting. Why isn't a setting simply a variable local to the package, and the setting-description a separate object (method) that can also be packaged separately? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Aug. 27, 2009

[Pharo-project] Fwd: about setting and preference.

by StÃ©phane Ducasse

Hi guys I was reading the comment of the SettingManager (may be should be called a preference manager). But this is impressive. We should start in 1.1 to use setting. Stef System settings are used to manage useful global parameters. A system setting is an instance of SystemSettingNode or of one of its subclasses. SettingManager is a facade for system setting instanciation. A setting is declared by a class method with a simple pragma. The pragma allows the SystemSettingBrowser to dynamically discover current settings. The default system setting pragma is <setting>. The important point is that a setting must be package specific. It means that each package is responsible for the declaring of its own settings. For a particular package, specific settings are declared by one or several of its classes. The consequence is that when the package is loaded, then its settings are automatically loaded and that when a package is unloaded, then its settings are automatically unloaded. Basically, settings are of two main kinds: setting nodes and settings with value. - A setting node don't hold any value. Such a setting is declared by a method which simply returns a SystemSettingNode instance. Any setting can declare any setting node as its parent. - A setting with value is an instance of SettingValue or of one of its subclasses. Such a setting holds a useful global system parameter and is made persistent: it is stored in a class variable which is initialized by the method that declares the setting. 1 DECLARING A SETTING NODE All System settings are organized in trees. Each tree root is a setting with no parent (parent set to nil). Whatever setting can be a root. If a root doesn't need to keep any value, then it can be an instance of SystemSettingNode. Such a setting is instanciated with: #SettingManager class>>newNode:. The argument is the name of the node. A setting node is mostly useful for the grouping of several related settings. The dialog instance variable can be set to the name of a dialog class. Then, the SystemSettingBrowser shows a button for this dialog: when pressed, the class which name is the dialog instance variable value receives the #open message. It can be useful in order to open a complex or handy dialog for the input of some settings. The example below shows a root node named 'System' declared in a SystemSettings class. ------------------ SystemSettings class>>systemSettingNode <setting> ^ (SettingManager newNode: 'System') description: 'All standard system settings' ------------------ The example below shows a the declaration of a subnode of systemSettingNode, it is declared in a UISettings class: ------------------ UISettings class>>UINode <setting> ^ (SettingManager newNode: 'User interface') description: 'Paramaters for the user interface'; parent: #systemSettingNode ------------------ 2 DECLARING SIMPLE VALUE SETTINGS 2.1 PRESENTATION A simple value setting is a setting which value is a Boolean, a String, a Symbol, a Number, a Font or a Color. Such a setting is hold by a SettingValue which is instanciated with #SettingManager class>>newSetting:. The argument is the name of the setting. If the setting has a default value, then, the setting is declared with the default value as below: ------------------ MyPackageSettings class>>mySetting <setting> ^ MySetting ifNil: [MySetting := (SettingManager newSetting: 'My setting name') description: 'A useful description'; default: aDefaultValue] ------------------ where: - MyPackageSettings is a class of MyPackage package (a system setting is declared class side) - mySetting is the getter for the setting - MySetting is the name of the class variable which value is the setting (instance of SettingValue) - 'My setting label' and 'A useful description' are respectively, the name and the description shown by the SystemSettingBrowser. - aDefaultValue is the default value for the setting If the setting doesn't have any default value (or if its default value is nil): ------------------ MyPackageSettings class>>mySetting <setting> ^ MySetting ifNil: [MySetting := (SettingManager newSetting: 'My setting name') description: 'A useful description'; type: aTypeSymbol] ------------------ aTypeSymbol is a symbol used by the setting browser in order to know how to build the input widget. By default, possible values are #Boolean, #String, #Symbol, #Integer, #Float, #Font or #Color. It can be of another value but in that case, the class which name is the type value should understand the #settingInputWidgetForNode: message. Classically, a SettingValue is not a root: it is declared as a child of one or several nodes in order to ease its managing. ------------------ MyPackageSettings class>>mySetting <setting> ^ MySetting ifNil: [MySetting := (SettingManager newSetting: 'My setting name') description: 'A useful description'; parent: aParentNodeSelector; type: aTypeSymbol] ------------------ aParentNodeSelector is a symbol which is the parent node method selector. A setting node may have several parents: ------------------ MyPackageSettings class>>mySetting <setting> ^ MySetting ifNil: [MySetting := (SettingManager newSetting: 'My setting name') description: 'A useful description'; parent: firstParentNodeSelector; parent: secondParentNodeSelector; type: aTypeSymbol] ------------------ or ------------------ MyPackageSettings class>>mySetting <setting> ^ MySetting ifNil: [MySetting := (SettingManager newSetting: 'My setting name') description: 'A useful description'; parents: #(firstParentNodeSelector secondParentNodeSelector); type: aTypeSymbol] ------------------ 2.2 SIMPLE VALUE SETTING EXAMPLES 2.2.1 Boolean settings Definition of the boolean setting "newbyMode" with only a label and a default value: ------------------ MyClass class>>newbyMode <setting> ^ NewbyMode ifNil: [NewbyMode := (SettingManager newSetting: 'Newby mode') default: false]. ------------------ A description could be very helpful when using the SystemSettingBrowser: ------------------ MyClass class>>newbyMode <setting> ^ NewbyMode ifNil: [NewbyMode := (SettingManager newSetting: 'Newby mode') default: false; description: 'the useful description goes here...']. ------------------ The default value is optional. If not present, the declaration must explicitly initialize the setting type: ------------------ MyClass class>>newbyMode <setting> ^ NewbyMode ifNil: [NewbyMode := (SettingManager newSetting: 'Newby mode') type: #Boolean; description: 'the useful description goes here...']. ------------------ 2.2.4 Color setting Note that the default can be a valuable. Here, the default is given by a MessageSend instance: ------------------ MyClass class>>desktopColor <setting> ^ DesktopColor ifNil: [DesktopColor := (SettingManager newSetting: 'Desktop color') parent: #uiColors; description: 'The color used for the desktop background'; default: (MessageSend receiver: Color selector: #green)] ------------------ You can also use a block for the default: ------------------ MyClass class>>desktopColor <setting> ^ DesktopColor ifNil: [DesktopColor := (SettingManager newSetting: 'Desktop color') parent: #uiColors; description: 'The color used for the desktop background'; default: [Color green]] ------------------ 2.2.5 Font setting Here the default is an instance of LogicalFont: ------------------ MyClass class>>codeFont <setting> ^ CodeFont ifNil: [CodeFont := (SettingManager newSetting: 'Code') description: 'The code font'; parent: #fontSettingNode; default: (LogicalFont familyName: 'DejaVu Sans' fallbackFamilyNames: nil pointSize: 12 stretchValue: 5 weightValue: 400 slantValue: 0)] ------------------ The default can also be set with a MessageSend instance: ------------------ MyClass class>>codeFont <setting> ^ CodeFont ifNil: [CodeFont := (SettingManager newSetting: 'Code') description: 'The code font'; parent: #fontSettingNode; default: (MessageSend receiver: self selector: #defaultStandardFont)] MyClass class>>defaultStandardFont ^ LogicalFont familyName: 'DejaVu Sans' fallbackFamilyNames: nil pointSize: 12 stretchValue: 5 weightValue: 400 slantValue: 0 ------------------ 3 DECLARING A SETTING WITH FINITE SET OF VALUES 3.1 PRESENTATION A setting can be defined so that its value is get from a restricted set of values. The setting is an instance of MultipleSettingValue. It is instanciated with #SettingManager class>>newMultiple:. The argument is the name of the setting. The collection of values from which a multiple setting takes its value is always a set of FixedSettingValue. A FixedSettingValue is created with #SettingManager class>>newFixed:. Such a setting can be of two different kinds : - if the valid value list is known at declaration time and is constant, then the list of values is set by sending the #domainValues: message to the setting. The argument is an array of fixed values. Such a setting can be declared as below: ------------------ MyPackageSettings class>>mySetting <setting> ^ MySetting ifNil: [MySetting := (SettingManager newMultiple: 'My setting name') description: 'A useful description'; default: aDefaultValue; domainValues: aListOfFixedSettingValues] ------------------ The default should be one of the valid values: a real value which is token from the list of possible values. - if the valid value list is not known at declaration time, then the list of possible values is dynamically computed by the SystemSettingBrowser by evaluating the block or the MessageSend stored as the getter instance variable value. The getter instance variable is set by sending the #domainValuesGetter: message to the setting. Such a setting can be declared as below: ------------------ MyPackageSettings class>>mySetting <setting> ^ MySetting ifNil: [MySetting := (SettingManager newMultiple:'My setting name') description: 'A useful description'; default: aDefaultValue; domainValuesGetter: aBlockOrAMessageSend] ------------------ The argument of #domainValuesGetter: can be a block or a instance of MessageSend. This valuable takes no argument. 3.2 EXAMPLES The declaration gives all possibles values for the setting. Each possible domain value is a fixed setting (read-only setting). Here is the example of #hintingSetting which value can be #Light, #Normal, #Full or #None: ------------------ MyClass class>>hintingSetting <setting> ^ HintingSetting ifNil: [HintingSetting := (SettingManager newMultiple: 'Hinting') description: 'Defines the glyph shapes' translated; parent: #freeTypeSettingNode; domainValues: { SettingManager newFixed value: #Light. SettingManager newFixed value: #Normal. SettingManager newFixed value: #Full. SettingManager newFixed value: #None }]. ------------------ In the case where domain values are of simple type, as Symbol for example, the shorter declaration given below can be used: ------------------ MyClass class>>hintingSetting <setting> ^ HintingSetting ifNil: [HintingSetting := (SettingManager newMultiple: 'Hinting') description: 'Defines the glyph shapes' translated; parent: #freeTypeSettingNode; domainValues: {#Light. #Normal. #Full. #None}] ------------------ The value domain can also be made of a set of complex objects. The example below shows #themeSetting setting. The value domain is an array with two fixed settings, for UIThemeStandardSqueak and for UIThemeWatery2: ------------------ MyClass class>>themeSetting <setting> ^ ThemeSetting ifNil: [ThemeSetting := (SettingManager newMultiple: 'UITheme') description: 'The theme to use for UI look and feel'; parent: #uiSettingNode; type: #UITheme; default: UIThemeWatery2; domainValues: { (SettingManager newFixed: 'Standard Squeak') value: UIThemeStandardSqueak. (SettingManager newFixed: 'Watery 2') description: 'Similar to a nice OS'; value: UIThemeWatery2}] ------------------ The shorter declaration given below can also be used. The domain values is a list of association. Each association key is used as the name of the fixed setting, and the corresponding association value is used as the value of the fixed setting: ------------------ MyClass class>>themeSetting <setting> ^ ThemeSetting ifNil: [ThemeSetting := (SettingManager newMultiple: 'UI theme') description: 'The theme to use for UI look and feel'; parent: #uiSettingNode; type: #UITheme; default: UIThemeWatery2; domainValues: {'Standard' -> UIThemeStandardSqueak. 'Watery 2' - > UIThemeWatery2}] ------------------ Previous version has a serious drawback: the list of possible values is fixed, then the first time the setting is read, the list is definitively built. After its building, there is no way to update the list except by the reinitializing of the corresponding class variable (hard reset). Regarding the themeSetting example, the problem is that new instances of UITheme can be added in the system after the setting has been created and initialized. In order be able to take into account system dependent domain values, you can makes the list dynamically computed. A getter instance variable can be set to a block or to an instance of a MessageSend. Such a valuable is dynamically evaluated by the SystemSettingBrowser in order to get current and up-to-date list of valid values. Here is the themeSetting example revisited: ------------------ MyClass class>>themeSetting <setting> ^ ThemeSetting ifNil: [ThemeSetting := (SettingManager newMultiple:'UI theme') parent: #uiSettingNode; default: UIThemeWatery2; domainValuesGetter: [UITheme allSubclasses collect: [:cls | SettingManager newFixed value: cls]]] ------------------ or with a much simpler version ------------------ MyClass class>>themeSetting <setting> ^ ThemeSetting ifNil: [ThemeSetting := (SettingManager newMultiple:'UI theme') parent: #uiSettingNode; default: UIThemeWatery2; domainValuesGetter: [UITheme allSubclasses]] ------------------ 4 DECLARING RANGE SETTING 4.1 PRESENTATION A setting for which all possible values are given by a range is an instance of RangeSettingValue. Such a setting is instanciated with #SettingManager class>>newRange:. The argument is the name of the setting. The range is set by sending a #range: message to a setting. The argument is an Interval instance. Such a setting can be declared as below: ------------------ MyPackageSettings class>>mySetting <setting> ^ MySetting ifNil: [MySetting := (SettingManager newRange: 'My setting name') description: 'A useful description'; default: aDefaultValue; range: anInterval] ------------------ The range is an instance of Interval. It is set by the #range: message and is evaluated by the SystemSettingBrowser when choosing a new value. Note that the SystemSettingBrowser presents an input field and a slider. 4.2 EXAMPLE ------------------ FontSettings class>>glyphContrast <setting> ^ GlyphContrast ifNil: [GlyphContrast := (SettingManager newRange: 'Glyph contrast') description: 'Change the contrast level for glyphs. This is an integer between 1 and 100'; parent: #freeTypeSettingNode; default: 50; range: (1 to: 100)] ------------------ 5 USING SPECIFIC DIALOG For setting browsing and editing, it could be useful to use a specific dialog instead of SystemSettingBrowser simple input widgets. For that purpose, the dialog attribute can be set with the name of a dialog class. While browsing a setting with a dialog, the SystemSettingBrowser presents a button for the dialog opening. The only constraint is that the dialog class must understand the #open message. For a node with children, it can be very useful in order to be able to use a cool dialog for the input of all children instead of being forced to input them one by one as it is the case with the SystemSettingrowser. Here is an example of a setting node with its dialog instance variable set to the value #FontSettingDialog. In the case of fonts, it could be useful in order to allow the using of a specific cool dialog for font preferences settings. ------------------ FontSettings class>>fontSettingNode <setting> ^ (SettingManager newNode: 'Fonts') description: 'System fonts settings'; dialog: #FontSettingDialog; parent: #uiSettingNode ------------------ The dialog instance variable can be set for a setting value too. Then, neither the default value nor the type is needed: ------------------ UISettings class>>uiStyle <setting> ^ UIStyle ifNil: [UIStyle := (SettingManager newSetting: 'UI style') dialog: #UIStyleChooserDialog; description: 'System style']. ------------------ 6 SIMPLE SETTING WITH CHILDREN A setting value can be a parent for another setting value. As an example, #gradientButtonLook can be a child of a boolean setting #advancedGUISetting: ------------------ MyClass class>>advancedGUISetting <setting> ^ AdvancedGUISetting ifNil: [AdvancedGUISetting := (SettingManager newSetting: 'Advanced GUI settings') parent: #uiSettingNode; default: true] MyClass class>>gradientButtonLook <setting> ^ GradientButtonLook ifNil: [GradientButtonLook := (SettingManager newSetting: 'Gradient look for buttons') parent: #advancedGUISetting; default: true] ------------------ 7 MANAGING SETTING VALUES 7.1 GETTING AND CHANGING A SETTING VALUE Let's use the following example of a boolean setting declaration: ------------------ MyPackageSettings class>>mySetting <setting> ^ MySetting ifNil: [MySetting := (SettingManager newSetting: 'My setting label') default: true] ------------------ The following two expressions are used in order to, respectively, get and set the value of the setting: ------------------ MyPackageSettings mySetting value. "get the value of the setting" MyPackageSettings mySetting value: false. "change the value of the setting" ------------------ 7.2 SETTING VALUE CHANGE NOTIFICATION 7.2.1 REGISTERING A LISTENER Whatever object can be declared as a change listener for a particular setting: each time the setting value is changed, each listener is aware of the change by receiving a particular message. In order to declare a listener, a client object must send the #whenChangedSend:to: message to a setting. The first argument is a message selector and the second argument it a receiver for the message. Then, the receiver becomes a listener for the setting. The message selector can take zero or one argument. In the case of one argument, the changed setting value is passed as argument to the message send. Note that an object can be declared as a listener several times, each time with a different message selector. As an example, lets take the example of the desktopColor setting: ------------------ DesktopSettings class>>desktopColor <setting> ^ DesktopColor ifNil: [DesktopColor := (SettingManager newSetting: 'Desktop color') parent: #uiColors; description: 'The color used for the desktop background'; default: (MessageSend receiver: Color selector: #white)] ------------------ Each time the desktop color setting is changed, the World color should be changed according to the new setting value. A solution could be to declare the World as a listener for the desktopColor setting changes and make it change its color according to the desktopColor setting each time the desktopColor setting value is changed. This can be achieved from the class initialize method as below: ------------------ DesktopSettings class>>initialize self desktopColor whenChangedSend: #color: to: World. ------------------ 7.2.2 UNREGISTERING A LISTENER There is two ways to unregister a listener for a particular setting changes. - The first way is to globally unregister a listener whatever the message selector. After the listener is unregistered, it is totally ignored when the concerned setting is changed. This is achieved by sending a #forget: message to the setting with the listener as argument. Concerning the desktopColor setting example, the World can be unregistered as shown below: ------------------ DesktopSettings desktopColor forget: World. "no more notification at all" ------------------ - The second way is to unregister a listener for only a specific selector. This is achieved by sending a #forget:selector: message to the setting. The first argument is the listener and the second is a selector. Concerning the desktopColor setting example, the World can be unregistered for only the #color: selector as shown below: ------------------ DesktopSettings desktopColor forget: World selector: #color:. "The World can still be notified using another selector" ------------------

Aug. 27, 2009

Re: [Pharo-project] Preparing Pharo sprint at esug

by StÃ©phane Ducasse

On Aug 27, 2009, at 2:00 PM, Damien Cassou wrote: > On Thu, Aug 27, 2009 at 12:51 PM, StÃ©phane > Ducasse<stephane.ducasse(a)inria.fr> wrote: >>>> -- cuis fonts >>> >>> don't see why this is important because we have FreeType working >>> perfectly. >> >> because you may have system without freetype plugin and now juan did >> all the work to make sure that this >> can be integrated into pharo! > > > That may be a good thing, but not now. The sooner we release the > better. And remember: we are now in beta which means the fewer fixes > the better. Lets concentrate on the important issues that must be > fixed before releasing 1.0. yes I will give a shot this evening. the key point is that pharo is moving fast so the more we wait the less possible. now indeed there are plenty of bug fixes that we can/should close. >>>> -- pending bug fixes... >>> >>> yes >>> >>>> - checking squeak fixes >>> >>> no, too late for that in my opinion unless this fixes a bug already >>> defined in the tracker. >> >> I checked and created a list so why this would be too late. > > > because we are in beta and we need to deliver something as soon as > possible. There will be bugs you can't avoid that. Delaying forever is > not a good solution. > >> In squeak compiler sneding notification were not in the bug tracker. > > We are not Squeak :-) > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 27, 2009

Re: [Pharo-project] Preparing Pharo sprint at esug

by Damien Cassou

On Thu, Aug 27, 2009 at 12:51 PM, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> wrote: >>> Â Â Â Â Â Â Â Â Â Â Â Â -- cuis fonts >> >> don't see why this is important because we have FreeType working >> perfectly. > > because you may have system without freetype plugin and now juan did > all the work to make sure that this > can be integrated into pharo! That may be a good thing, but not now. The sooner we release the better. And remember: we are now in beta which means the fewer fixes the better. Lets concentrate on the important issues that must be fixed before releasing 1.0. > >> >>> Â Â Â Â Â Â Â Â Â Â Â Â -- pending bug fixes... >> >> yes >> >>> Â Â Â Â Â Â Â Â - checking squeak fixes >> >> no, too late for that in my opinion unless this fixes a bug already >> defined in the tracker. > > I checked and created a list so why this would be too late. because we are in beta and we need to deliver something as soon as possible. There will be bugs you can't avoid that. Delaying forever is not a good solution. > In squeak compiler sneding notification were not in the bug tracker. We are not Squeak :-) -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 27, 2009

Re: [Pharo-project] Compiler Notifications

by StÃ©phane Ducasse

Thanks lukas. This is great to have a guy like you around. On Aug 27, 2009, at 1:57 PM, Lukas Renggli wrote: > I "merged" the changes of Colin "The compiler now uses notifications > to signal that a correctable error has been found in the method > source, rather than interacting directly with the user" into the Pharo > compiler. This was a bit tricky because the compiler is quite > different and some classes are somehow called different, but it seems > to work now. Also the tests pass. Strange I did not thought we change that much :) > > http://www.squeaksource.com/PharoInbox/CompilerTests-lr.17.mcz > http://www.squeaksource.com/PharoInbox/Compiler-lr.118.mcz > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 27, 2009

Re: [Pharo-project] Fwd: Better senders/implementers UI

by StÃ©phane Ducasse

LOL Stef On Aug 27, 2009, at 1:47 PM, Lukas Renggli wrote: >>> Scott Wallace made a nice improvement to the regular senders/ >>> implementers browsers. It reuses in the same window, and adds a >>> history pane so you can see how you got to a certain point, and can >>> back track if necessary. >>> >>> This has not been updated since 3.8 I think, but if properly >>> integrated rather than as separate package it might be quite nice: >>> >>> http://www.squeaksource.com/Green.html > > This is part of OB for 3 years already. In recent versions even with > smooth scrolling. > > 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

Aug. 27, 2009