- Pharo-dev - lists.pharo.org

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

Dec. 8, 2009

11081 ----- Issue 1527: Move *Freetype-override back to Graphics in CharacterScanner & co Issue 1560: ImageSegment: recategorize some methtods Issue 1556: FontTest testResetAfterEmphasis fails with StrikeFont

1 0

[Pharo-project] systemwindow grabbing fix
by Alain Plantec Dec. 8, 2009

Dec. 8, 2009

SLICE-Issue420-SystemWindowAboutToBeGrabbedBy-Try2 is in InBox ------------------- * fix the systemwindow grab problem (when the user grab a window from outside the window title bar) ------------------- Alain

2 1

[Pharo-project] Cannot update behind a proxy
by Nicolas Cellier Dec. 8, 2009

Dec. 8, 2009

The update process stops at 11070... It cannot get access to http://www.squeaksource.com/Pharo/ScriptLoader11-MarcusDenker.81.mcz 'Could not resolve the server named: www.squeaksource.com' I can perfectly access this resource via firefox though... Anything related to Preferences refactoring ? Nicolas

4 5

Re: [Pharo-project] Window drag and drop strange behavior in 1.1 latest
by alain.plantec＠free.fr Dec. 8, 2009

Dec. 8, 2009

Stephane, isn't it related to the issue 420 for which I proposed a fix ? I've found a problem with my fix and the attached .cs is supposed to fix the fix. The problem is that when you grab a window from outside the titlebar (try from the annotation pane as an example), then its position is badly set. Could you try to load the .cs and tell me. Alain Hi all I remember that I integrated a change that was supposing to fix drag and drop or shadow. I cannot look for it since I'm in the train. Now there is a problem. to see it: move slowly your mouse to a window (from outside the window). When you get an arrow press and the window will be selected but place quite far from where you click. Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

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

Dec. 8, 2009

11080 ----- Issue 1528: Transparent rendering of Line Feeds (LF) Issue 1478: ScriptLoader loadFFI fails with a dependency error (again)

1 0

[Pharo-project] linked in pharo group :)
by StÃ©phane Ducasse Dec. 8, 2009

Dec. 8, 2009

You can register :) Not sure that this is useful but may be fun :) Stef

2 1

[Pharo-project] VMMaker in Pharo.
by Mariano Martinez Peck Dec. 8, 2009

Dec. 8, 2009

Hi! I need to load VMMaker and I was reading this link: http://code.google.com/p/pharo/wiki/BuildingAVMOnPharo I tried with the gofer script but it doesn't work in new Gofer version, as I need to change add: for addPackage: There were also a problem with the ladrillos repo which was with lowcase instead of uppercase. The correct Gofer script to load VMMaker is: |gofer| "Create Gofer Object" gofer := Gofer new. "Load the FFI package" ScriptLoader loadFFI. "add the Speech packages" gofer squeaksource: 'Ladrillos'; addPackage: 'Speech-Klatt'. "add VMMaker Packages" gofer squeaksource: 'VMMaker'; addPackage:'VMMaker'. "add Alien Support Packages" gofer squeaksource: 'Alien'; addPackage:'Alien-VMMaker-Support'. " Load " gofer load. Now...the question is, can I create ScriptLoader>>loadVMMaker? If true, I create and issue and submit the code. Cheers, Mariano

5 8

[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