- Pharo-dev - lists.pharo.org

Contact of HwaJong Oh

by stepharo

Hi guys I'm looking for the email of HwaJong Oh. Does anybody of you have it? Stef

June 28, 2014

Re: [Pharo-dev] GUI question

by stepharo

> Hi all, > > is there a rationale for the world menu on left mouse button only in > Pharo 4? (and world contents on the right mouse button) Simplifying mouseDown: following the cleaning made on Bloc by alain. It was strange to have two different ways to show the list of windows and also wht left and right should do the same. In Pharo 3.0 I get the same (see attachement) menu. So I do not understand how useful it is. This idea of meta and operate looks a bit old fashioned to me (totgther with the defaultYellowButtonPressed kind of code :) Morphic is a gigantic beast and removing complexity is the only way. Now if you have an good argument post of fix. Stef > > Mine would be: > - if I press a pull down menu (press a menu bar item or a pull down > menu), it's the left mouse button. > - If I look for a menu on a non-button thing, it's the right mouse > button, i.e. contextual menu. > > Now, should I consider that the Pharo background is a huge pull-down > menu button to understand the rationale behind having the world menu > on the left-mouse button? > > Thierry

June 28, 2014

Re: [Pharo-dev] Spec TreeModel

by stepharo

For your info, I'm slowly going all the polymorph widget examples and truning them into single example to identify what are the widgets that we should - improve - remove Having 3 versions of the same is killing us. Ben fixed a lot of problems like merging multi/single selection but there is still a lot of work to do. So I started to reorganize the packages to help us finding our way doing this analysis. Stef On 27/6/14 11:28, Yuriy Tymchuk wrote: > Hi, > > Iâd like to improve the TreeModel of Spec, but I need some help. > > Fist of all UI breaks when different theme is used: > > When you deselect checkbox and at that moment item is not highlighted. > This happens when checkbox is clicked, the item is not highlighted and > so itâs original color is not stored, but when you uncheck item it IS > unhighlighted for some reason, and as default color is not stored, > black one is used. First of all we can replace black color by theme > color, and also I think that we should handle checkbox and list clicks > in a separate manner. Now the other thing is related. I can turn on > checkbox, but can I turn off the list selection? Are the selected > items distinguished is any way, or all items with checked checkboxes > and highlights merged into one list? > > Uko >

June 28, 2014

Re: [Pharo-dev] [Pharo4] Slots: Code Generation and an Example

by stepharo

This is so cool. I remember when we played one afternoon in 2008 to see if this interplay would work. Stef On 27/6/14 10:19, Marcus Denker wrote: > Hi, > > So now Opal delegates code generation for read and write to the Slot meta objects. > The methods called are #emitValue: and #emitStore:, the parameter is an IRBuilder. > > With this the implementor of a Slot is free to generate whatever bytecode needed, it will > be inlined at the read or assignment site in the method. > > For the ivar Slot this is e.g. just > > emitStore: methodBuilder > > methodBuilder storeInstVar: index > > emitValue: methodBuilder > > methodBuilder pushInstVar: index. > > > Now the implementors of Slots should not need to be bothered about bytecode, therefore we have > in the superclass of all Slots defaults emit methods that implement a*reflective* read and write using > the MOP of the Slot itself (slower than code generation, but often enough): > > emitValue: aMethodBuilder > aMethodBuilder > pushLiteral: self; > pushReceiver; > send: #read: > > emitStore: aMethodBuilder > aMethodBuilder > pushLiteral: self; > pushReceiver; > send: #writeToSlot:of: > > > What this means is that for someone who wants to implement a slot, you do not have to deal with bytecode at all. > > Here is a simple Slot: > > Slot subclass: #TestSlot > instanceVariableNames: 'value' > classVariableNames: '' > category: 'Slot-Scopeâ > > > read: anObject > ^ value > > write: aValue to: anObject > value := aValue > > > So this is a strange kind of Slot that stores the value in itself, which means it is shared between all objects as there is only > one Slot meta object per class per slot. (not something you want to do in real world, but a nice demo) > > Now we can create a class (not yet easily as we have not yet enabled a class template, so lets use the ClassBuilder directly): > > PharoClassInstaller make: [ :builder | > builder name: #A; > slots: { TestSlot named: #iv }; > category: #Playground ]. > > > In class A we can implement accessors: > > iv > ^iv > > iv: anObject > iv := anObject > > > They look like normal ivar accesses, but in the background, the compiler delegated to the Slot the code generation, calling emit*, which leads > to the bytecode e.g. for the read: > > 21 <20> pushConstant: iv => TestSlot > 22 <70> self > 23 <E1> send: read: > 24 <7C> returnTop > > you could override the emit* methods to generate faster code, but to get something running it is not needed. > > To test, e.g. you can set the slot from one object and read it from another: > > A new iv: 6 > A new iv > > Then inspect the slot: > > (A slotNamed: #iv) inspect > > (this should all Work in 4.0 048, the example is there as TestSlot for now) > > ...next steps: > > 1) Class Definition template for classes with Slots > 2) How do we save these classes in Monticello? > 3) Virtual Slots (Boolean and PropertySlots) > > > Marcus

June 28, 2014

Re: [Pharo-dev] Do we remove infiniteForm support?

by Esteban A. Maringolo

2014-06-27 16:51 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> Double dispatching is not always an option. >> :) > And it doesn't work in this case? Absolutely does work, it screams "double dispatch me!" using FillStyle as intermediary :) Regards! -- Esteban

June 27, 2014

Re: [Pharo-dev] Do we remove infiniteForm support?

by Eliot Miranda

On Fri, Jun 27, 2014 at 12:38 PM, Esteban A. Maringolo <emaringolo(a)gmail.com > wrote: > 2014-06-27 16:31 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > On Fri, Jun 27, 2014 at 11:58 AM, Esteban A. Maringolo > > <emaringolo(a)gmail.com> wrote: > > >> Because Smalltalk lacks a "switch/case" control flow structure? :) > > and of course it has one that works just fine. > > Really? Which one? > > Or are you referring to this code pattern? > (a = 1) ifTrue: [^...]. > (a = 2) ifTrue: [^...]. > (a = 3) ifTrue: [^...]. > > Double dispatching is not always an option. > :) > And it doesn't work in this case? -- best, Eliot

June 27, 2014

Re: [Pharo-dev] Do we remove infiniteForm support?

by Sven Van Caekenberghe

he is referring to #caseOf: and #caseOf:otherwise: which are a bit controversial ;-) On 27 Jun 2014, at 21:38, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-06-27 16:31 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> On Fri, Jun 27, 2014 at 11:58 AM, Esteban A. Maringolo >> <emaringolo(a)gmail.com> wrote: > >>> Because Smalltalk lacks a "switch/case" control flow structure? :) >> and of course it has one that works just fine. > > Really? Which one? > > Or are you referring to this code pattern? > (a = 1) ifTrue: [^...]. > (a = 2) ifTrue: [^...]. > (a = 3) ifTrue: [^...]. > > Double dispatching is not always an option. > :) > > > Esteban A. Maringolo >

June 27, 2014

Re: [Pharo-dev] Do we remove infiniteForm support?

by Esteban A. Maringolo

2014-06-27 16:31 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > On Fri, Jun 27, 2014 at 11:58 AM, Esteban A. Maringolo > <emaringolo(a)gmail.com> wrote: >> Because Smalltalk lacks a "switch/case" control flow structure? :) > and of course it has one that works just fine. Really? Which one? Or are you referring to this code pattern? (a = 1) ifTrue: [^...]. (a = 2) ifTrue: [^...]. (a = 3) ifTrue: [^...]. Double dispatching is not always an option. :) Esteban A. Maringolo

June 27, 2014

Re: [Pharo-dev] Do we remove infiniteForm support?

by Eliot Miranda

On Fri, Jun 27, 2014 at 11:58 AM, Esteban A. Maringolo <emaringolo(a)gmail.com > wrote: > Because Smalltalk lacks a "switch/case" control flow structure? :) > and of course it has one that works just fine. Esteban A. Maringolo > > > 2014-06-27 15:42 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > I always wondering how anybody can write such code with smalltalk > > > > > > 2014-06-26 0:43 GMT+04:00 stepharo <stepharo(a)free.fr>: > Steph, it begs for double-dispatching. So why shoot InfiniteForm instead of fixing the code/ It makes no sense to me. Double-dispatching is a pattern you know well. Apply it here. > > > >> because when I see code like that, it makes me sick! > >> I wonder also when we migrate to Athens if we will not rewrite all that > >> anyway. > >> > >> fillRectangle: aRectangle basicFillStyle: aFillStyle > >> "Fill the given rectangle with the given, non-composite, fill > style." > >> > >> | pattern | > >> > >> (aFillStyle isKindOf: InfiniteForm) ifTrue: [ > >> ^self infiniteFillRectangle: aRectangle fillStyle: aFillStyle > >> ]. > >> > >> (aFillStyle isSolidFill) > >> ifTrue:[^self fillRectangle: aRectangle color: aFillStyle > >> asColor]. > >> > >> "We have a very special case for filling with infinite forms" > >> (aFillStyle isBitmapFill and:[aFillStyle origin = (0@0)]) ifTrue:[ > >> pattern := aFillStyle form. > >> (aFillStyle direction = (pattern width @ 0) > >> and:[aFillStyle normal = (0@pattern height)]) ifTrue:[ > >> "Can use an InfiniteForm" > >> ^self fillRectangle: aRectangle color: (InfiniteForm > with: > >> pattern)]. > >> ]. > >> "Use a BalloonCanvas instead" > >> self balloonFillRectangle: aRectangle fillStyle: aFillStyle. > >> > > > > -- best, Eliot

June 27, 2014

Re: [Pharo-dev] Do we remove infiniteForm support?

by Esteban A. Maringolo

Because Smalltalk lacks a "switch/case" control flow structure? :) Esteban A. Maringolo 2014-06-27 15:42 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > I always wondering how anybody can write such code with smalltalk > > > 2014-06-26 0:43 GMT+04:00 stepharo <stepharo(a)free.fr>: > >> because when I see code like that, it makes me sick! >> I wonder also when we migrate to Athens if we will not rewrite all that >> anyway. >> >> fillRectangle: aRectangle basicFillStyle: aFillStyle >> "Fill the given rectangle with the given, non-composite, fill style." >> >> | pattern | >> >> (aFillStyle isKindOf: InfiniteForm) ifTrue: [ >> ^self infiniteFillRectangle: aRectangle fillStyle: aFillStyle >> ]. >> >> (aFillStyle isSolidFill) >> ifTrue:[^self fillRectangle: aRectangle color: aFillStyle >> asColor]. >> >> "We have a very special case for filling with infinite forms" >> (aFillStyle isBitmapFill and:[aFillStyle origin = (0@0)]) ifTrue:[ >> pattern := aFillStyle form. >> (aFillStyle direction = (pattern width @ 0) >> and:[aFillStyle normal = (0@pattern height)]) ifTrue:[ >> "Can use an InfiniteForm" >> ^self fillRectangle: aRectangle color: (InfiniteForm with: >> pattern)]. >> ]. >> "Use a BalloonCanvas instead" >> self balloonFillRectangle: aRectangle fillStyle: aFillStyle. >> >

June 27, 2014