January 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Anonymous classes should be browseable

by Nicolai Hess

2015-01-26 7:44 GMT+01:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > I want to discuss case 14789 ( > https://pharo.fogbugz.com/f/cases/14789/Nautilus-assumes-a-class-always-und…) > because a class should be browseable even without a definition. Anonymous > classes are still classes. > > If Nautilus project cannot deal with the whole Smalltalk power then it is > poorly designed and I wonder what's the advantage over the old > OmniBrowser... > > HernÃ¡n > > Can you show what the old OmniBrowser is displaying for Behavior new new browse I can not check this in Pharo, as I could not find a way to load OmniBrowser in that image. nicolai

Jan. 26, 2015

Re: [Pharo-dev] Anonymous classes should be browseable

by HernÃ¡n Morales Durand

No problem, I will try to fix so you can review if you find time. Cheers, HernÃ¡n 2015-01-26 3:55 GMT-03:00 Marcus Denker <marcus.denker(a)inria.fr>: > > On 26 Jan 2015, at 07:52, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > wrote: > > Marcus, I don't see it. > Why an UI tool defect should impact Behavior? > > > my problem is a bit that I have so much to do (there are 672 other open > issuesâ¦) that I canât even think about this, > so I will ignore it for now. > > > 2015-01-26 3:49 GMT-03:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> >> On 26 Jan 2015, at 07:44, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> >> wrote: >> >> I want to discuss case 14789 ( >> https://pharo.fogbugz.com/f/cases/14789/Nautilus-assumes-a-class-always-und…) >> because a class should be browseable even without a definition. Anonymous >> classes are still classes. >> >> If Nautilus project cannot deal with the whole Smalltalk power then it is >> poorly designed and I wonder what's the advantage over the old >> OmniBrowser... >> >> It means pushing a lot of API down to Behaviour. Do we want that? >> >> Marcus >> >> > >

Jan. 26, 2015

Re: [Pharo-dev] Anonymous classes should be browseable

by Marcus Denker

> On 26 Jan 2015, at 07:52, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > Marcus, I don't see it. > Why an UI tool defect should impact Behavior? my problem is a bit that I have so much to do (there are 672 other open issuesâ¦) that I canât even think about this, so I will ignore it for now. > > 2015-01-26 3:49 GMT-03:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > >> On 26 Jan 2015, at 07:44, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>> wrote: >> >> I want to discuss case 14789 (https://pharo.fogbugz.com/f/cases/14789/Nautilus-assumes-a-class-always-und… <https://pharo.fogbugz.com/f/cases/14789/Nautilus-assumes-a-class-always-und…>) because a class should be browseable even without a definition. Anonymous classes are still classes. >> >> If Nautilus project cannot deal with the whole Smalltalk power then it is poorly designed and I wonder what's the advantage over the old OmniBrowser... >> > It means pushing a lot of API down to Behaviour. Do we want that? > > Marcus > >

Jan. 26, 2015

Re: [Pharo-dev] Anonymous classes should be browseable

by HernÃ¡n Morales Durand

Marcus, I don't see it. Why an UI tool defect should impact Behavior? 2015-01-26 3:49 GMT-03:00 Marcus Denker <marcus.denker(a)inria.fr>: > > On 26 Jan 2015, at 07:44, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > wrote: > > I want to discuss case 14789 ( > https://pharo.fogbugz.com/f/cases/14789/Nautilus-assumes-a-class-always-und…) > because a class should be browseable even without a definition. Anonymous > classes are still classes. > > If Nautilus project cannot deal with the whole Smalltalk power then it is > poorly designed and I wonder what's the advantage over the old > OmniBrowser... > > It means pushing a lot of API down to Behaviour. Do we want that? > > Marcus > >

Jan. 26, 2015

Re: [Pharo-dev] Anonymous classes should be browseable

by Marcus Denker

> On 26 Jan 2015, at 07:44, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > I want to discuss case 14789 (https://pharo.fogbugz.com/f/cases/14789/Nautilus-assumes-a-class-always-und… <https://pharo.fogbugz.com/f/cases/14789/Nautilus-assumes-a-class-always-und…>) because a class should be browseable even without a definition. Anonymous classes are still classes. > > If Nautilus project cannot deal with the whole Smalltalk power then it is poorly designed and I wonder what's the advantage over the old OmniBrowser... > It means pushing a lot of API down to Behaviour. Do we want that? Marcus

Jan. 26, 2015

Anonymous classes should be browseable

by HernÃ¡n Morales Durand

I want to discuss case 14789 ( https://pharo.fogbugz.com/f/cases/14789/Nautilus-assumes-a-class-always-und…) because a class should be browseable even without a definition. Anonymous classes are still classes. If Nautilus project cannot deal with the whole Smalltalk power then it is poorly designed and I wonder what's the advantage over the old OmniBrowser... HernÃ¡n

Jan. 26, 2015

Any way to avoid the filmification effect in GTInspector?

by HernÃ¡n Morales Durand

For example Process allInstances inspect. I am using #40460, and I want to select an item in a list and continue to see the list. I have tried to set the "Number of inspector panes" to 1, but that only shift the selected object sub-window. HernÃ¡n

Jan. 26, 2015

Re: [Pharo-dev] GTInspector does not refresh printString

by HernÃ¡n Morales Durand

Is this fixed? I couldn't find an entry case in fogbugz. I remember the UpdatingStringMorph used a #stepTime: method, which I suppose you could borrow to implement the timer. It would be cool to have a configurable step time for refreshing contents. Cheers, HernÃ¡n 2015-01-13 9:26 GMT-03:00 stepharo <stepharo(a)free.fr>: > > >> I was doing a lecture and this is really sad to get all features gone. >> > > I think this is not so fair :). > > > indeed but reopening an inspector is a pain. > > > >> So I had to reinspect again. >> > > Yes. As Andrei said, it is a bug that will be fixed. > > >> In addition GTInspector bubble is a pain because sometimes you really >> want to keep the result and not inpect it. >> > Did you see my request to get that enter put the bubble contents into >> the text pane? >> > > Did you see the reply? :) > > > No where it is? > > > >> I'm sorry but I cannot use GT as it is now. >> > > That's a pity. > > > but this is a reality. > > > > And I'm working on the new version of Pharo by example and it would be >> good to >> have something full working. >> > > Besides these two problems, do you have others? > > > I got confused with the inspector of arrays because we have to click on an > extra pane to see them if I recall. > It was so painfull with all the other problems that I stop to use GT to > avoid a huge frustration and get my job done. > > > > Cheers, > Doru > > > > >> Stef >> >> >> Cheers, >> Andrei >> >> On Mon, Jan 12, 2015 at 12:14 PM, stepharo <stepharo(a)free.fr> wrote: >> >>> Hi >>> >>> GTInspector does not change the printString representation when we >>> change the printOn:. >>> Am I the only one to see this behavior? >>> >>> Stef >>> >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > >

Jan. 26, 2015

Re: [Pharo-dev] Why this hangs the VM?

by HernÃ¡n Morales Durand

Yes, apparently one has to debug the primitive to get what's really happening. Thanks Ben, HernÃ¡n 2015-01-25 13:08 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > > > On Sun, Jan 25, 2015 at 8:16 AM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> Behavior basicNew basicNew. >> > > I guess philosophically, #basicNew creates an incomplete object, so > sending it messages is in the hands of the gods. Now the following works > okay... > Behavior new basicNew > > So something in its #initialize makes it not crash. Rolling out > Behanior>>initialize and commenting out a line at a time to get the minimum > statements to prevent crashing results in the following... > > behavior := Behavior basicNew. > > "behavior superclass: Object." > "behavior methodDict: behavior emptyMethodDictionary." > > behavior setFormat: Object format. > > "behavior traitComposition: nil." > "behavior users: IdentitySet new." > > behavior basicNew. > > So the VM will crash if you fail to #setFormat. That is as far as mu > understanding goes. > cheers -ben > > >> Class basicNew basicNew. >> >> No .log is generated >> Applies to Pharo4 #40460 and Pharo 3.0 (Windows 8.1) >> >> Cheers, >> >> HernÃ¡n >> >> >

Jan. 26, 2015

Re: [Pharo-dev] [Pharo-users] [ANN] OS Project with initial support for Ubuntu and Unix

by Torsten Bergmann

> i am not running ubuntu at all. and you wonder why an ubuntu specific project is not working - funny ;) > pharo4 is a few weeks old, i'll update that. > > i see no reason why opening a terminal should be ubuntu specific. in any case > though, it should just fail and not hang. Check class side methods UbuntuShell. It only calls "gnome-terminal" which might not be available. Bye T

Jan. 26, 2015