November 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Patches for Pharo packages you are maintaining

by Hilaire Fernandes

Le 23/11/2013 19:05, Sean P. DeNigris a Ã©crit : > But seriously if this is not clear, how do we improve it? > Make it work. It never worked for me, I keep trying then give up, thinking about a temporary failure, then doing other business. I don't understand what the monkey really want but it is not nice with me. So I guess I miss something that should be documented. Hilaire -- Dr. Geo http://drgeo.eu

Nov. 23, 2013

Re: [Pharo-dev] Patches for Pharo packages you are maintaining

by Sean P. DeNigris

hilaire wrote > Le 23/11/2013 09:51, Camillo Bruni a Ã©crit : > In the welcome page of the bug tracker, add a page explaining how to > create by yourself an account. Like the one there now (https://pharo.fogbugz.com/default.asp?W41) ? ;) > Welcome to the Pharo issue tracker. This is the official issue tracker for > cases related to the different versions of Pharo. > > You most probably see this page because you are not logged in, or you do > not have an account on the issue tracker yet (*Register here*). But seriously if this is not clear, how do we improve it? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Fwd-Patches-for-Pharo-packages-you-are-maintaining-tp… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 23, 2013

Re: [Pharo-dev] Keyboard modifiers OSX vs Win

by Sean P. DeNigris

philippeback wrote > I was wondering why things were different on the two platforms. > * Command -> Left ALT > * Option -> Right ALT Guessing that the first is because the left alt is in windows is where the cmd key would be on a mac. For the second, probably because pressing the equivalent key position to mac's option, the windows key, brings up the start menu... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Keyboard-modifiers-OSX-vs-Win-tp4724546p4724572.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 23, 2013

Re: [Pharo-dev] Slot class builder: Anonymous class modification

by Eliot Miranda

On Fri, Nov 22, 2013 at 7:27 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 22 November 2013 16:25, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 22 November 2013 16:04, Camille Teruel <camille.teruel(a)gmail.com>wrote: >> >>> Hi everyone, >>> >>> With Esteban, we bumped into a problem with anonymous subclasses and the >>> slot class builder. >>> The problem is that once an anonymous class is created is not possible >>> to modify it. >>> Here is the problem: >>> For creating an anonymous class with the new class builder API you do >>> something like: >>> >>> myAnonymousClass := AnonymousClassInstaller make: [ :classBuilder | >>> classBuilder >>> superclass: Object; >>> name: #MyAnonymousClass; >>> .... ] >>> >>> What happens is that the class builder asks the class installer if the >>> class named #MyAnonymousClass exists or not to know if this a class to be >>> created or to be modified. >>> Here, the strategy of the anonymous class installer is to always answer >>> no. So ok, now you have you're anonymous class. >>> But what happens when you do something like: >>> >>> myAnonymousClass addInstVarNamed: #newIV >>> >>> Since the class has no clue of what class installer was used to create >>> it, it instantiate a new one, and a PharoClassInstaller ! >>> This new class installer then says to the class builder that there is no >>> class named MyAnonymousClass so it creates it! And it install it in the >>> system dictionary! >>> And myAnonymousClass is not modified. >>> >>> So there is several problem here: >>> - a class doesn't know which class installer was used to create it >>> - even if the class would know that, the anonymous class installer would >>> always say that it doesn't know it and a new class would be created >>> >>> So one possible solution for that is to have one class installer per >>> environment (so add one iv in SystemDictionary right now), like that a >>> class would know what class installer was used to create it. >>> What would happen then is that you don't create anonymous classes >>> anymore, that is to say a class not installed in any environment, but >>> instead you create a class that exist in an environment separated from the >>> system dictionary. >>> >>> What do you think? >>> >>> >>> i think that this expression: >> >> myAnonymousClass addInstVarNamed: #newIV >> >> should create and answer new original class. >> And don't take me wrong a 'new class' means just a new class object, >> which is not installed/registered anywhere, because it is done at next step >> (if its necessary). >> >> I'm not sure what this 'class installer' thingy comes from and it looks >> completely irrelevant. We must have clear separation between operations >> which creating new classes >> and installing/registering them inside environment. >> Because anonymous class is not one which has no name, it is one which is >> not registered in any public place. For the rest , it should behave in same >> way as public one. >> >> The fact that IDE tries to hide it and simulate as if you modified >> existing class is not really important here, because it is higher-level >> contracts and responsibilities. >> >> > imo, a better term to use for it would be 'private class' , because > anonymous is a bit fuzzy. > I disagree. Anonymous classes is the term that has been used for over two decades. It means, literally, a class that has no name because it is not in Smalltalk (or in a top-level environment if the dialect has namespaces). This is not at all fuzzy. Private class means something quite different, a class that is private to some environment, e.g. a class nested within another class as occurs in SmalltalkAgents or Newspeak. > > > >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Best regards, > Igor Stasenko. > -- best, Eliot

Nov. 23, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by StÃ©phane Ducasse

> How does this affect serialization / materialization engines like Fuel? Not now We will have to work to make the compiler smarter and define special Slot class. >> On 21 nov. 2013, at 13:44, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> any links why newcomers like me should be impressed ? Whats the advantages ? >> >> >> That's just cleaning. The old class builder was an incredibly complex piece >> of code that is now replaced with the Slot class builder. >> The later is based on slots and is much more understandable and thus much >> easier to maintain. >> It's been integrated some time ago thanks to Martin. >> >> Slots are the work of Toon and Camillo and enables a lot of useful features: >> http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectL… >> They are based on the reification of class layouts (variable,weak,fixed and >> co) and instance variables (slots). >> Slots are an abstraction added on top of low-level class "fields". >> It means that one will be able to create a customized slot class that define >> the logic to read and write a slot: >> >> Object subclass: #MyClass >> slots: { x => MyFancySlot } >> category: 'Playground' >> >> Then when a method read or writes x, the logic you defined in MyFancySlot is >> executed. >> All that still need to be absorbed by Opal so it's not available right now >> but it will (Pharo 4)! >> >> >> >> >> >> On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Triple impressive! This is another sample of an apparently tiny change >>> that actually has deep impact on the future of our beloved environment. >>> >>> Ladies and gentlemen, I know you are busy, but please take the time to >>> acknowledge it :) >>> >>> Doru >>> >>> >>> >>> >>> On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias(a)gmail.com> >>> wrote: >>>> >>>> wow, impressive! >>>> >>>> >>>> On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker(a)inria.fr> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Yesterday Camille did the change to finally remove the old class >>>>> builder! >>>>> (just a removal + a small change to NativeBoost to use the new class >>>>> builder to create anonymous classes). >>>>> >>>>> This means >>>>> - 1000 Loc of completely un-understandable code removed. >>>>> - we now 100% run on the new class builder from the Slot >>>>> Project. >>>>> >>>>> Next on the list (not all for Pharo3): >>>>> >>>>> - remove PackageInfo >>>>> - old Browser + CodeHolder hierarchy >>>>> - PseudoClass&Co â> Ring >>>>> - old AST+Compiler (this in Pharo4) >>>>> >>>>> We already did (all in Pharo3): >>>>> -> remove URI >>>>> -> deprecated Url for ZnUrl >>>>> -> removed HTTPSocket facade >>>>> -> MIMEType retired for ZnMimeType >>>>> -> old Debugger is removed >>>>> -> Class categories are replaced by Protocols >>>>> >>>>> I am quite sure that these cleanups will enable us to build a lot of >>>>> very interesting things >>>>> in the future. >>>>> >>>>> Marcus >>>> >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >> >> >> >

Nov. 23, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by StÃ©phane Ducasse

sweet queries :) >> Then we can now have more compact versions of > > FreeTypeSettings LabelMorph MorphTreeNodeMorph MorphTreeListManager ThemeSettings MultistateButtonMorph PharoUserPermissions SimpleHierarchicalListMorph Nautilus class SpecTreeColumn PluggableIconListMorph MorphTreeMorph Workspace CompositionScanner Paragraph MethodOveridesAction HandMorph TextComposer ScrollBar NECContext MultiByteFileStream NewValueHolder DynamicClassGroup SearchMorph NautilusHistoryEntry PluggableTextFieldMorph PluggableListMorph TableLayoutProperties DynamicGroup DropListMorph GradientFillStyle PackageTreeNautilus PluggableTextMorphWithLimits NECUntypedModel BalloonEngine MetacelloPharo30Platform SystemWindow NautilusWindow NECPreferences class EditorFindReplaceDialogWindow GoBackStringMorph NautilusHistoryEntryWithSourceCode MCCacheRepository PluggableButtonMorph AlphaImageMorph PluggableTextMorph RxMatcher MorphExtension TextMorphForFieldView MorphTreeColumn FindReplaceService CheckboxMorph TextMorphForEditView IndentingListItemMorph ControlButtonMorph CheckboxButtonMorph > > with multiple booleans mapped to one instVar > > > |set| > set := IdentitySet new. > Object allSubclasses do: [ :aClass | > |varSize coll nr candidate | > candidate := false. > varSize := aClass instSize. > coll := aClass allInstances. > nr := 10 min: coll size. > (coll first: nr) do: [ :anInstance | > |value nrBoolean| > nrBoolean := 0. > 1 to: varSize do: [ :varIndex | > value := anInstance instVarAt: varIndex. > value class = True ifTrue: [ nrBoolean := nrBoolean + 1 ]. > value class = False ifTrue: [ nrBoolean := nrBoolean + 1 ]]. > nrBoolean >1 ifTrue: [ candidate := true ] ]. > candidate ifTrue: [ set add: aClass ]]. > set. > >

Nov. 23, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by StÃ©phane Ducasse

On Nov 21, 2013, at 3:21 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > I don't fully see what are the immediate benefits. > > But as usually happen when you replace something old, limited and "not > so well designed" by something better designed from the ground up I > guess it will open Pharo to features not yet thought of. > > Does the new debugger have something "better" than the previous one? Having a real a model and a UI separated. We can script the debugger now and create different UIs. Just that should make you happy. browse the code of the Debugger in Pharo 20 or 1.4 and try to find where is the UI defined :) > > > Regards! > Esteban A. Maringolo > > > 2013/11/21 Tudor Girba <tudor(a)tudorgirba.com>: >> Triple impressive! This is another sample of an apparently tiny change that >> actually has deep impact on the future of our beloved environment. >> >> Ladies and gentlemen, I know you are busy, but please take the time to >> acknowledge it :) >> >> Doru >> >> >> >> >> On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >>> >>> wow, impressive! >>> >>> >>> On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker(a)inria.fr> >>> wrote: >>>> >>>> Hi, >>>> >>>> Yesterday Camille did the change to finally remove the old class builder! >>>> (just a removal + a small change to NativeBoost to use the new class >>>> builder to create anonymous classes). >>>> >>>> This means >>>> - 1000 Loc of completely un-understandable code removed. >>>> - we now 100% run on the new class builder from the Slot >>>> Project. >>>> >>>> Next on the list (not all for Pharo3): >>>> >>>> - remove PackageInfo >>>> - old Browser + CodeHolder hierarchy >>>> - PseudoClass&Co â> Ring >>>> - old AST+Compiler (this in Pharo4) >>>> >>>> We already did (all in Pharo3): >>>> -> remove URI >>>> -> deprecated Url for ZnUrl >>>> -> removed HTTPSocket facade >>>> -> MIMEType retired for ZnMimeType >>>> -> old Debugger is removed >>>> -> Class categories are replaced by Protocols >>>> >>>> I am quite sure that these cleanups will enable us to build a lot of very >>>> interesting things >>>> in the future. >>>> >>>> Marcus >>> >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >

Nov. 23, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by Tudor Girba

Hi Chris, The dictionary had to be added in the Morphic class by whoever developed Morphic so that you can extend it. That means that they had to predict that you will extend it. Imagine that they wouldn't have predicted that. We would simply not be able to extend Morphic. Contrast this situation with methods defined in a class. In this case, the language provides us with the ability of extending any class with extra methods. This is a powerful mechanism that we take for granted. We need to approach in the same way all constructs in the language, including instance variables and traits definitions. Slots should solve the instance variables problem. Cheers, Doru

Nov. 23, 2013

Keyboard modifiers OSX vs Win

by phil＠highoctane.be

I was wondering why things were different on the two platforms. By looking at the VM source code, I found that: * 3) The modifier keys are mapped as follows: * * Mac | Win32 * -------------------- * Shift -> Shift * Ctrl -> Ctrl * Command -> Left ALT * Option -> Right ALT Things are now clearer!

Nov. 23, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by StÃ©phane Ducasse

On Nov 21, 2013, at 2:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > And then, imagine what this will do for tools. Given that the class instance will know what kind of slots are around, the tools can help you manage them. You will be able to build your class and then simply say that you want a slot to be bidirrectional and point it to the opposite slot. Really, I am so excited :) We are in sync :) I'm curious to understand/build the API of collabation between class <-> slot and opal for such example

Nov. 23, 2013