- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.1] #11079
by Marcus Denker Dec. 8, 2009

Dec. 8, 2009

11079 ----- Issue 1558: The old preference browser should be as much functionnal as possible while migrating to the new setting system Issue 1552: Add Float>>ulp support SLICE-PreferencesMigration-Part6 in InBox ----------------- make the old preference browser fully functional again. * hacked Preference>>preferenceValue, Preference >>preferenceValue:, Preference>>rawValue: and Preference>>togglePreferenceValue. * new Preferences class method category "settings-migration": For each preference migration, it contains 2 methods for getting and setting the preference. They are implemented using the new setting system. As an example for the migration of #annotationPanes: Preferences class>>annotationPanesSetting and Preferences class>>annotationPanesSetting: are added. ----------------- Also useful to understand correspondences between old and new preference systems

1 0

[Pharo-project] Issue 1558: The old preference browser should be as much functionnal as possible while migrating to the new setting system
by alain.plantec＠free.fr Dec. 8, 2009

Dec. 8, 2009

SLICE-PreferencesMigration-Part6 in InBox ----------------- make the old preference browser fully functional again. * hacked Preference>>preferenceValue, Preference >>preferenceValue:, Preference>>rawValue: and Preference>>togglePreferenceValue. * new Preferences class method category "settings-migration": For each preference migration, it contains 2 methods for getting and setting the preference. They are implemented using the new setting system. As an example for the migration of #annotationPanes: Preferences class>>annotationPanesSetting and Preferences class>>annotationPanesSetting: are added. ----------------- Also useful to understand correspondences between old and new preference systems

1 0

[Pharo-project] Fwd: [squeak-dev] Re: On traits composition
by Igor Stasenko Dec. 8, 2009

Dec. 8, 2009

---------- Forwarded message ---------- From: Igor Stasenko <siguctua(a)gmail.com> Date: 2009/12/8 Subject: Re: [squeak-dev] Re: On traits composition To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> 2009/12/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/12/8 Andreas Raab <andreas.raab(a)gmx.de>: >> Igor Stasenko wrote: >>> >>> T1+T2 >>> should mean 'apply T1 then T2', but not 'apply combination of T1 and T2'. >>> Its much easier to implement as well as easy to understand & follow. >> >> That's what I'm thinking as well. >> >>> Also, in Pharo list i suggested extension to exclusion operator: >>> >>> in addition to: >>> T1 - selectorsArray "{ #sel1. #sel2 }" >>> >>> also have: >>> >>> T1 - T2 >>> >>> which should transparently behave as: >>> >>> T1 - (T2 selectors) >>> >>> and mean: apply all from T1 , except selectors in T2. >> >> I'll leave this as an exercise for the interested reader :) >> >>> Btw, i am curious about one thing: >>> Since traits allowed to hold method for both instance side and class side. >> >> Ah, yes. Classes and metaclasses and traits. Last time we had this >> discussion it was pretty clear that this whole area is not well-understood. >> That you can only apply a trait without class-side methods to a class for >> example, causes all sorts of irritation when you later add a class method to >> the trait, thereby making it non-applicable to compositions where it's >> already used. It's inconsistent at least (broken as far as I'm concerned >> since you can create compositions that can't be recreated). >> >>> Now, how i can specify a composition, which applies my trait, except >>> #isel1 and #csel2 ? >>> So, final class should have #isel2 method at instance side and >>> #csel2 at class side, but not #isel1 and not #csel2. >>> And what is a correct syntax for defining such composition in class >>> definition? >> >> Yes, that's just more inconsistencies resulting from the same basic problem. >> >> Cheers, >> Â - Andreas >> > > Since classInstVarNames are defined in a separate declaration, I do > not see why it couldn't be so for Traits. > This would lead to some simplications. > A possible POV is to handle #class as an ordinary message. It could > eventually return any object (squeak specific implementation apart). > So why put requirements on the protocol of object answered by #class > and not on the protocol answered by #asInteger ? It is well known the > second is a Boolean after all... If we don't put protocol requirements > on self class, we then do not need any class side Trait, do we ? (I > mean they could just be ordinary Traits). > IMO ideally, trait should NOT care where it applied to (be it class, metaclass or any other object). It should expect that object supporting a certain Behavior-based protocol (like #setTraitComposition:) but nothing more than that. Naturally, trait could be seen as a partial behavior, and so, it should Â be applicable to just behavior only, not to two behaviors at once (class/metaclass). I think this i a clear case, where we could have a much less complex implementation by sacrificing the 'class side' view of trait (ClassTrait). Because, one could always create a two separate traits (TApple , TAppleClassSide) and apply each one independently: Apple uses: TApple.. Apple class uses: TAppleClassSide. -- Best regards, Igor Stasenko AKA sig. -- Best regards, Igor Stasenko AKA sig.

1 0

[Pharo-project] FontTest>>testDisplay failing in Pharo image due to new StrikeFonts
by Adrian Lienhard Dec. 8, 2009

Dec. 8, 2009

Hi, The test FontTest>>testDisplay fails in the latest Pharo image. If somebody has a bit of time left, it would be great to get a fix. We are almost down to 0 failures/errors in the Pharo image... http://code.google.com/p/pharo/issues/detail?id=1555 Adrian ___________________ http://www.adrian-lienhard.ch/

3 2

[Pharo-project] [ANN] pre-built 1.1#11078
by Marcus Denker Dec. 8, 2009

Dec. 8, 2009

http://gforge.inria.fr/frs/download.php/24983/PharoCore-1.1-11078-alpha.zip Marcus

1 0

[Pharo-project] Scriptloader class>>loadFFI
by Schwab,Wilhelm K Dec. 8, 2009

Dec. 8, 2009

Does Scriptloader loadFFI work in RC1? It's barking at me about FFIConstants. Bill

5 10

[Pharo-project] [Fwd: Re: Cannot update behind a proxy]
by Alain Plantec Dec. 8, 2009

Dec. 8, 2009

2 3

[Pharo-project] Is there in Pharo a class with the functionality of PrintingConverter?
by csrabak＠bol.com.br Dec. 8, 2009

Dec. 8, 2009

I think it is specific in VW (I don't remember in Dolphin) but for formating numbers in strings, etc. like this class does. Tried looking for classes and methods (w/method finder) e/o success! -- Cesar Rabak

1 0

[Pharo-project] FFI not loading on squeak-dev 496
by Esteban Lorenzano Dec. 8, 2009

Dec. 8, 2009

Hi, I'm trying to load FFI on a squeak-dev image (496 09.11.04) and I'm having a DNU here: externalFunctionDeclaration "Parse the function declaration for a call to an external library." | descriptorClass callType retType externalName args argType module fn | descriptorClass := Smalltalk at: #ExternalFunction ifAbsent:[nil]. descriptorClass == nil ifTrue:[^false]. callType := descriptorClass callingConventionFor: here. ------------------------------------------------------------ ^HERE Does anybody knows what happens? Cheers, Esteban

3 4

[Pharo-project] SmallDictionary>>removeAll or >>empty?
by Simon Denier Dec. 7, 2009

Dec. 7, 2009

Stupid question: how do I remove all entities from a SmallDictionary Let's take: d := SmallDictionary new. d add: $d -> 4. d add: $e -> 5. d If I do d empty then d size = 0 and d do: behaves as if there is nothing BUT someone can still perform d at: $d -> 5 If I do d removeAll I get a MessageNotUnderstood: SmallInteger>>key because #removeAll inherited from Collection expects a different structure -- Simon

4 6