- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Circle is gone

by Marcus Denker

On May 18, 2011, at 8:08 PM, StÃ©phane Ducasse wrote: > What Circle? > Circle, from ST80... I think you removed it ;-) > CircleMorph? > I do not see why it would be removed? > > Stef > On May 18, 2011, at 2:54 PM, Tudor Girba wrote: > >> Hi, >> >> Circle seems to be gone from Pharo 1.3. >> >> What is now the preferred way to specify a circle? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "When people care, great things can happen." >> >> >> >> > > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 18, 2011

Re: [Pharo-project] Circle is gone

by StÃ©phane Ducasse

On May 18, 2011, at 4:59 PM, Tudor Girba wrote: > Hmm, I did not see the discussion. me neither. > > So, does it mean that we should rescue the old classes and put them in a separate package? > > Cheers, > Doru > > > On 18 May 2011, at 16:42, Alexandre Bergel wrote: > >> There is no user of these classes in a 1.2. And nobody shouted against its removal. >> This was a reason good enough to remove them :-) >> >> Alexandre >> >> >> On 18 May 2011, at 10:36, Tudor Girba wrote: >> >>> I guess there was a reason behind removing them, and I also guess that the best way would be to find what is the other preferred solution besides adding them back :). Or was there removal a mistake? >>> >>> Cheers, >>> Doru >>> >>> >>> On 18 May 2011, at 16:08, Alexandre Bergel wrote: >>> >>>> I also bumped into the same problem. For the case of Mondrian, I will copy the missing classes into Mondrian. >>>> These classes were removed quite some times ago from Pharo 1.3 >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>> On 18 May 2011, at 08:54, Tudor Girba wrote: >>>> >>>>> Hi, >>>>> >>>>> Circle seems to be gone from Pharo 1.3. >>>>> >>>>> What is now the preferred way to specify a circle? >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "When people care, great things can happen." >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "We cannot reach the flow of things unless we let go." >>> >>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > >

May 18, 2011

Re: [Pharo-project] Circle is gone

by StÃ©phane Ducasse

What Circle? CircleMorph? I do not see why it would be removed? Stef On May 18, 2011, at 2:54 PM, Tudor Girba wrote: > Hi, > > Circle seems to be gone from Pharo 1.3. > > What is now the preferred way to specify a circle? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "When people care, great things can happen." > > > >

May 18, 2011

Re: [Pharo-project] OCompletion?

by StÃ©phane Ducasse

which version? I do not like the idea to trap any Error. I prefer that we bump into the real error and fix it. >> In which Pharo? 1.3? I do not seem to bump into it. In what context do you get it? > > When I try to edit code within a debugger. It does not systematically appear. Just once in a while. > > Alexandre > > >> >> >> On 18 May 2011, at 16:19, Alexandre Bergel wrote: >> >>> Hi! >>> >>> Am I the only one to bump all the time into error raised by OCompletion? >>> >>> in OController>>handleKeystrokeBefore: kbEvent editor: theEditor >>> I just switched: >>> self isMenuOpen ifFalse: [ self openMenuFor: theEditor ]. >>> >>> into: >>> self isMenuOpen ifFalse: [ [self openMenuFor: theEditor] on: Error do: [] ]. >>> >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Next time you see your life passing by, say 'hi' and get to know her." >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

May 18, 2011

Re: [Pharo-project] The Cult of Done Manifesto

by StÃ©phane Ducasse

excellent. So I guess that we can interpret it as a call to the community to get even more in doing mode :) I love that message. Get expert by doing :) Stef On May 18, 2011, at 1:17 PM, Marcus Denker wrote: > The Cult of Done Manifesto > > - There are three states of being. Not knowing, action and completion. > > - Accept that everything is a draft. It helps to get it done. > > - There is no editing stage. > > - Pretending you know what you're doing is almost the same as knowing what you are doing, > so just accept that you know what you're doing even if you don't and do it. > > - Banish procrastination. If you wait more than a week to get an idea done, abandon it. > > - The point of being done is not to finish but to get other things done. > > - Once you're done you can throw it away. > > - Laugh at perfection. It's boring and keeps you from being done. > > - People without dirty hands are wrong. Doing something makes you right. > > - Failure counts as done. So do mistakes. > > - Destruction is a variant of done. > > - If you have an idea and publish it on the internet, that counts as a ghost of done. > > - Done is the engine of more. > > http://www.brepettis.com/blog/2009/3/3/the-cult-of-done-manifesto.html?v=1 > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

May 18, 2011

Re: [Pharo-project] A lil simplification of MorphTreeNodeMorph

by Tudor Girba

Hi, On 18 May 2011, at 18:17, Igor Stasenko wrote: > On 18 May 2011 17:57, Tudor Girba <tudor.girba(a)gmail.com> wrote: >> Hi, >> >> >> The rows with text with a gray background should span the entire horizontal space. Actually, the reason why there is the gray background is to reveal the bounds of the morphs for debugging :). >> >> Also the text morphs that are the children of the gray root items should also span the horizontal space (now you see from the border that it has a very small extent) >> > > Now i'd like to ask you , if this is a general requirement for all > morphs placed in treemorph node? > Or it should be controlled by morph which you placing? I think that having this work for any morph should be fine. But, the other would work as well. > This should be controlled by #hResizing: , but not all morphs actually > honor this. > I can mistake, but string morph which is used for labels just paints > the string and any extra width is ignored.. Aha. Ok. in any case, we should be able to get a PluggableTextMorph fill the space. > It is also, a good question what to do if you have multiple morphs > which has #spaceFill placed in a row? > > Consider following: > > <column1> | <column2> > <m1> <m2 spacefill .......> <m3 spacfill ... > | <mx ... > <my ... > < mz> I think that the best way is to require a root morph that controls the layout of the children. On a related note, Gary made the GeneralScrollPane to scroll on one dimension and stretch on another. The problem is that MorphTreeMorph inherits from ScrollPane. Alain proposed that perhaps it would be a solution to get it work with the GeneralScrollPane. Cheers, Doru >> Cheers, >> Doru >> > > > -- > Best regards, > Igor Stasenko AKA sig. > -- www.tudorgirba.com "Be rather willing to give than demanding to get."

May 18, 2011

Re: [Pharo-project] Decompiler problem (leading to infinite loop of opening debuggers)

by Nicolas Cellier

2011/5/18 Toon Verwaest <toon.verwaest(a)gmail.com>: > On 05/18/2011 01:30 PM, Marcus Denker wrote: >> >> On May 18, 2011, at 1:26 PM, Toon Verwaest wrote: >> >>> I haven't figured out the exact decompiler bug yet, but just so you can >>> easily fix your problem: >>> >> I tested on 1.3, and it's fixed there... we synced in 1.3 with some fixes >> from the old compiler. >> >> We could backport the compiler fixes to 1.2... > > Oh ok, then I don't even look further. But that decompiler is a mess ... > moving to OPAL would be a great improvement I'd say ... Yes this code is very hard to track by just reading code... So hard to maintain too. Too many states in a single class. And you often discover that the processing you were looking for in fact was coded somewhere else (like in MessageNode). The best way to understand the old Decompiler is to debugIt. Nicolas >>> >>> just move the temp in the whileFalse: [ |newReqd| to the toplevel of the >>> method (if this is semantically equivalent; but it looks like). >>> Then it can actually decompile it ;) >>> >>> cheers, >>> Toon >>> >>> On 05/18/2011 12:16 PM, Johan Brichau wrote: >>>> >>>> Â (MetacelloMCVersionSpec compiledMethodAt: #resolveToLoadableSpecs:map:) >>>> decompileWithTemps >>> >> -- >> Marcus Denker Â -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> > > >

May 18, 2011

Re: [Pharo-project] A lil simplification of MorphTreeNodeMorph

by Igor Stasenko

On 18 May 2011 17:57, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > > The rows with text with a gray background should span the entire horizontal space. Actually, the reason why there is the gray background is to reveal the bounds of the morphs for debugging :). > > Also the text morphs that are the children of the gray root items should also span the horizontal space (now you see from the border that it has a very small extent) > Now i'd like to ask you , if this is a general requirement for all morphs placed in treemorph node? Or it should be controlled by morph which you placing? This should be controlled by #hResizing: , but not all morphs actually honor this. I can mistake, but string morph which is used for labels just paints the string and any extra width is ignored.. It is also, a good question what to do if you have multiple morphs which has #spaceFill placed in a row? Consider following: <column1> | <column2> <m1> <m2 spacefill .......> <m3 spacfill ... > | <mx ... > <my ... > < mz> > Cheers, > Doru > -- Best regards, Igor Stasenko AKA sig.

May 18, 2011

Re: [Pharo-project] Wishes for new ClassBuilder (toon?)

by Toon Verwaest

The PlayOut classbuilder indeed separates this nicely. We have the distinction between the "installer" and the "builder". The builder uses an "installer" as a client and notifies it about stuff that happens. For example we have an "anonymous subclass builder" that's implemented like that. It basically just ignores most of the notifications of the builder since it doesn't really do anything. ... but of course this means that you need PlayOut ;) You can get an image at http://pinocchio.unibe.ch/~tverwaes/PlayOut.tar.gz caveats: - At the moment that system doesn't validate everything yet like the old classbuilder (since I wanted to freely change classes with any name) - it doesn't handle obsolete subclasses yet. Oh well ;) - it's still intertwined with our slots implementation, so it relies on Helvetia. But that can/should/will be fixed without changing the API. cheers, Toon On 05/18/2011 03:18 PM, Mariano Martinez Peck wrote: > Hi guys. As part of the Fuel project, one of the things we want to do > (in fact, it is done) is to serialize classes. There want to have 3 > possibilities: > 1) Do something like DiskProxy where you only save its global name and > some selector to run when deserialing it > 2) Really searialize the whole class (following method dictionary, > compiled methods, class pools and friend, etc) so that you can > deserialize it in another image where such class is not present. > 3) Do the same as 2 but validating and installing the class in the system. > > For 2) what we want to do is just to serialize the class as any other > object. As a result, we get a Class instance. Nothing is validated, > nothing is added in Smalltalk globals, nothing is compiled. We do not > use ClassBuilder at all. > > For 3) we want to do 2) plus validating and installing the class in > the system. For validating I mean ALL the validations that the class > builder does when creating or modifying a class. And for "installing > in the system" I mean notify, put in Smalltalk globals, re compile > what is needed, etc... > > ClassBuilder seems to do 2) and 3) together. So, what I would love to > have in a new class builder is to have those two things separated. So > that I can say to an object ClassManager validate: aClass or > ClassManager installClassOnSystem: aClass. > > Do you think such thing is possible? Right now going through > ClassBuilder and understand all the validations it does is really > complicated :( > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com >

May 18, 2011

Re: [Pharo-project] [Vm-dev] Re: out of memory - cog on windows

by Levente Uzonyi

On Wed, 18 May 2011, Tudor Girba wrote: snip > > I tried with several versions of Cog including the latest ones (on both platforms) and I got the same result. I did not try with an interpreter VM because I only have Cog images around (based on Pharo 1.2) and they are not compatible. You can use this interpreter vm to open cog images: http://leves.web.elte.hu/squeak/SqueakVM-Win32-4.4.9-2358-non-official-bin.… Levente snip

May 18, 2011