February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] TabbedPane Class/ Package / Workspace browsers

by S Krish

That work was an an hour's prototype over TabbedPane... Pushed it now over the last few hours: * usable set of minimal functionality embedded.. * overridden SystemWindow #openAsIn: aWorld to open all of SystemWindow type windows.. in this tab when variable #allowOpenAllInTabbedPane is true. all/ any browser/ window opens up with nearly all features intact... in the tabbed pane * Also the list of tabs open pops up to allow easier navigation if one has more than screen full of tabs open.. kind of usable now.. but will clean this out in a week.. and share the code.. but I do like the Newspeak UI, intend to have one pane of full scrollable view of class instance/ class methods (collapsible) with hyperlinked navigations for sender-implementor et als.. Kind of reminds of the dinner with Peter Deutsch back in 2003 Dec, when he said he prefers Python as it gives a wholesome view of the code, than just one method at a time.. On Thu, Feb 16, 2012 at 11:39 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi Krish, > > On Wed, Feb 15, 2012 at 10:15 PM, S Krish < > krishnamachari.sudhakar(a)gmail.com> wrote: > >> >> >> Just this quick n usable prototype.. ? >> > > I really like the look of the tabs. But can you not push the tabs up so > that they are at the same level as the open/close/collapse buttons and > replace the title? Shame to loose so much screen real-estate to the tabs. > That's why in my own hack I use a pop-up menu in the title bar. I would > use a tab containing just "+" for "add a tab", and add an "x" button to > each tab for closing it. > > >> Any comments of its utility.. I for one would rather prefer having >> everything navigable from one Tabbed Pane.. >> >> Panes capable of rendering about every window of the basic tools of >> Pharo.. workspace, Finder, ScriptManager, possibly Transcript as a console >> collapsible as reqd >> >> Akin to the eclipse but not really that intensively single windowed.. >> there are uses for spawning separate windows.. >> >> > > > -- > best, > Eliot > >

Feb. 16, 2012

Re: [Pharo-project] garbage collection

by StÃ©phane Ducasse

Tx for the bug entries!!! >>> I sort of doubt Magma uses anything registering external objects but the standard Socketsâ¦ >>> While interrupting finalization process _could_ be a culprit, I'd rather watch for something like what happened with the InputEventFetcher, where registration/deregistration ends up not being symmetric. >>> >>> Perhaps Magma tries to reuse existing Socket instances by calls to initialize:/acceptFrom: for example? >>> >>> I think changing ExternalSemaphoreTable to a weak structure would be a really bad idea btw. >>> All of a sudden, you free up slots which were previously taken for insertion of old objects. >>> >>> There is no guarantee the external user of the semaphore will stop using the index it was given just because the image no longer holds a reference to the object which used to occupy that index. >>> >>> So if you register a new object in the same slot, in the case of Sockets at least, you could potentially end up responding to signals from both the old external user, and the new one. >>> >>> TLDR; Any object registered in this table by definition needs explicit cleanup of external users before they are GC'd. Thus, making the table weak makes no sense. >>> >> >> Yes, that could happen. >> Well, then the only option is to check what code producing leaks. And >> that's not trivial, since >> you cannot trace references back to semaphore's original owner. :( >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > It's not such a big task to review the current users, there are like 5 of them in the base image. > > AFAICT: > 1) InputEventFetcher, this has been bug-fixed once already. No leaks as long as it has a single entry in startup/shutdown lists. > 2) Sockets, which, to my knowledge work OK with the weak finalization. > 3) AsyncFile, only done correctly if #close'd at EOL. No weak cleanup done it seems, could be changed to work like Sockets. > 4) StandardFileStream url opening, should be modified to use an ensure: block. Only applicable when running in a browser though, unlikely to be a large issue. > 5) NetNameResolver, never unregisters the semaphore, and leaks one whenever network needs (re)initialization. Snapshot? Image quit? Arbitrary points during execution? Reading the plugin source would tell the real cases I guess. A probable culprit in this case, I would say. > > I opened http://code.google.com/p/pharo/issues/detail?id=5310 , which contains proposed changes related to 3-5. > > I also opened 2 additional issues for things I ran into, but didn't do as it wasn't worth the effort/strictly related: > > 5311: Rewrite AsyncFile to have weak finalization for guaranteed cleanup of external objects > 5312: Move StandardFileStream browserRequest protocol functionality to a separate package, and deprecate the protocol itself. > The main purpose of the methods in this protocol has nothing to do with FileStreams, but rather performing navigation in a Browser when Pharo is run as a plugin. > > Cheers, > Henry > > >

Feb. 16, 2012

Re: [Pharo-project] Is the plan to replace FileStream by FSStream?

by StÃ©phane Ducasse

Henrik I'm sure that if we would be in face of a browser together I would get 100% what you are saying now I hate mail but I'm not 100% clear about what you say. :) Could you make a list of the steps that we could follow? I will sit and discuss with camillo next week. I would like to have a todo so that I can do item after itemâ¦ Because I want to get rid of the old code. Stef On Feb 16, 2012, at 8:25 PM, Henrik Johansen wrote: > > On Feb 16, 2012, at 8:07 PM, Henrik Johansen wrote: > >> >> On Feb 16, 2012, at 6:45 PM, Luc Fabresse wrote: >> >>> Hi, >>> >>> reading this: http://code.google.com/p/pharo/issues/detail?id=5303 >>> I wonder if the plan is to replace FileStream by FSStream? >>> >>> #Luc >>> >> My vote would be no. >> http://forum.world.st/pharo-vision-tp4340345p4342871.html >> http://forum.world.st/pharo-vision-tp4340345p4341445.html >> >> You'd be stuck chasing bugs trying to bring FSFileStreams up to pair with the normal FileStreams for many, many releases. >> I'd rather try one of the approaches mentioned in the 2nd link, setting StandardFileStream as the default plugged-in stream implementation, so you could rewrite the path API manipulation in your code independent of the stream/file reading/writing. >> >> Cheers, >> Henry > > Let me put it another way: > FS is a really good, no, compared to what we have now, - excellent - API for specifying paths. > > 1) If we *ever* want people to start using it with existing code though, we need to decouple the task of rewriting path creation from that of also rewriting the code using streams opened on said paths. > > 2) By making the stream implementation used by FS pluggable you: > - Reduce the size of FS core, making it more focused on the actual FileSystem manipulation/querying part of the framework. > - Can still provide an ANSI stream implementation for people writing new, portable code. > - Solve #1, by letting existing users continue to use their, however flawed, existing stream implementations. > > Cheers, > Henry >

Feb. 16, 2012

Re: [Pharo-project] Is the plan to replace FileStream by FSStream?

by Henrik Johansen

On Feb 16, 2012, at 8:07 PM, Henrik Johansen wrote: > > On Feb 16, 2012, at 6:45 PM, Luc Fabresse wrote: > >> Hi, >> >> reading this: http://code.google.com/p/pharo/issues/detail?id=5303 >> I wonder if the plan is to replace FileStream by FSStream? >> >> #Luc >> > My vote would be no. > http://forum.world.st/pharo-vision-tp4340345p4342871.html > http://forum.world.st/pharo-vision-tp4340345p4341445.html > > You'd be stuck chasing bugs trying to bring FSFileStreams up to pair with the normal FileStreams for many, many releases. > I'd rather try one of the approaches mentioned in the 2nd link, setting StandardFileStream as the default plugged-in stream implementation, so you could rewrite the path API manipulation in your code independent of the stream/file reading/writing. > > Cheers, > Henry Let me put it another way: FS is a really good, no, compared to what we have now, - excellent - API for specifying paths. 1) If we *ever* want people to start using it with existing code though, we need to decouple the task of rewriting path creation from that of also rewriting the code using streams opened on said paths. 2) By making the stream implementation used by FS pluggable you: - Reduce the size of FS core, making it more focused on the actual FileSystem manipulation/querying part of the framework. - Can still provide an ANSI stream implementation for people writing new, portable code. - Solve #1, by letting existing users continue to use their, however flawed, existing stream implementations. Cheers, Henry

Feb. 16, 2012

Re: [Pharo-project] Is the plan to replace FileStream by FSStream?

by Camillo Bruni

ok, I guess we should take an action towards that direction... I already had trouble enough getting it somehow compatible :), which should be fairly easy... best cami On 2012-02-16, at 20:07, Henrik Johansen wrote: > On Feb 16, 2012, at 6:45 PM, Luc Fabresse wrote: > >> Hi, >> >> reading this: http://code.google.com/p/pharo/issues/detail?id=5303 >> I wonder if the plan is to replace FileStream by FSStream? >> >> #Luc >> > My vote would be no. > http://forum.world.st/pharo-vision-tp4340345p4342871.html > http://forum.world.st/pharo-vision-tp4340345p4341445.html > > You'd be stuck chasing bugs trying to bring FSFileStreams up to pair with the normal FileStreams for many, many releases. > I'd rather try one of the approaches mentioned in the 2nd link, setting StandardFileStream as the default plugged-in stream implementation, so you could rewrite the path API manipulation in your code independent of the stream/file reading/writing. > > Cheers, > Henry

Feb. 16, 2012

Re: [Pharo-project] Traits in PHP

by Hernan Wilkinson

It looks interesting, but how this relates to the state issue? On Thu, Feb 16, 2012 at 12:35 PM, Nicolas Passerini <npasserini(a)gmail.com>wrote: > I think it would be very nice to be able to apply a trait directly to an > object, without having to create a new class. > This is possible for example in scala: > > val myObject = new MyClass with MyTrait > > I have programmed a simple implementation in Pharo which allows you to do: > > myObject := (MyClass with: MyTrait) new. > > The implementation is only a proof of concept and has some issues that > should be addressed before being able to use it in a real program, but I > can make it available if someone is interested. > > What do you think about this? > > > > On Thu, Feb 16, 2012 at 11:04 AM, Hernan Wilkinson < > hernan.wilkinson(a)10pines.com> wrote: > >> I have an idea about the state issue in traits, maybe you thought about >> it too... I was thinking that the definition of representing something as >> state or not should be responsibility of the implementation, that is the >> class (nothing new here), so we delay that decision until the trait is >> used. >> So, maybe what we need is a way to indicate that a message send in a >> trait is not really that in a class... For example: >> >> TraitA>>m1 >> >> ^self name first >> >> Object subclass: #ClassA >> uses: #TraitA >> mapping: (MessageSendToInstanceVariable from: #name to: 'firstName') >> ... bla bla. >> >> So, #m1 in ClassA would look like: >> >> ClassA>>m1 >> >> ^firstName first >> >> Of course this implies some complexity when copying the behavior from the >> trait to the class (we can not use the same compiled method), also >> maintaining the relationship with changes on the trait (what happens if #m1 >> is changed in TraitA and does not send #name anymore), etc. >> First class slot (a la Self) would be a nicer solution, but I feel that >> that implies a more radical change on the object model, vm, etc. and also >> has the disadvantages of making all state public (unless something is done >> to avoid that). >> >> At the same time, I would like to point out that having subclassing and >> traits at the same time as sharing mechanism is kind of confusing, >> programmers do not know which one is better to use, should I subclass or >> use a trait? how I'm sure which one is better? etc. We talk about this when >> you came to Argentina, do you remember? A student did his tesis about >> removing subclassing and using only traits as sharing tool, but the results >> were not as good as I expected (sadly, the thesis is written in Spanish...) >> >> Anyway, my two cents >> Hernan. >> >> >> On Thu, Feb 16, 2012 at 4:56 AM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> >>> On Feb 15, 2012, at 11:30 PM, Hernan Wilkinson wrote: >>> >>> > what is the difference with the current trait implementation in pharo? >>> I could not see the differenceâ¦ >>> >>> Stefan replied but what I wanted to say is that I would like to have the >>> time to see how we can introduce more nicely traits. >>> Right now there are edges where this is ugly and also rethink the >>> system. I think that if we would have first class slots we could have >>> traits with state in a much better fashion. >>> >>> Stef >>> >>> > On Wed, Feb 15, 2012 at 7:45 AM, StÃ©phane Ducasse < >>> stephane.ducasse(a)inria.fr> wrote: >>> > Indeed. Now I would love that we rethink our trait implementation and >>> tool support but no time. >>> > >>> > On Feb 15, 2012, at 6:40 AM, blake wrote: >>> > >>> > > This is kinda cool: >>> > > >>> > > http://phpmaster.com/using-traits-in-php-5-4/ >>> > > >>> > >>> > >>> > >>> > >>> > >>> > -- >>> > HernÃ¡n Wilkinson >>> > Agile Software Development, Teaching & Coaching >>> > Mobile: +54 - 911 - 4470 - 7207 >>> > email: hernan.wilkinson(a)10Pines.com >>> > site: http://www.10Pines.com >>> > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina >>> > >>> >>> >>> >> >> >> -- >> *HernÃ¡n Wilkinson >> Agile Software Development, Teaching & Coaching >> Mobile: +54 - 911 - 4470 - 7207 >> email: hernan.wilkinson(a)10Pines.com >> site: http://www.10Pines.com <http://www.10pines.com/>* >> Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina >> >> > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

Feb. 16, 2012

Re: [Pharo-project] Traits in PHP

by Hernan Wilkinson

if you use an object model a la Self, there is no difference between an instance variable and a method from the "sender" point of view. So, in this code "self name", name could be implemented as a "data slot" (a slot that references an object) or a "method slot", it is up to the receiver. So, the sender always sends the message #name, no matter if name is implemented as method or "variable". At the end it is not first class slots what solves the problem but the uniformity of using only message send to represent computation (no variable assingments, etc). So, going to the trait example, if the trait says "self name", the class that uses that trait could implement "name" as a data slot or method slot, it does not matter to the trait and therefore the trait is state agnostic... at least that is what I understood from Stef comment :-), but may be he meant other thing! :-) On Thu, Feb 16, 2012 at 2:11 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Thu, Feb 16, 2012 at 3:04 PM, Hernan Wilkinson < > hernan.wilkinson(a)10pines.com> wrote: > >> I have an idea about the state issue in traits, maybe you thought about >> it too... I was thinking that the definition of representing something as >> state or not should be responsibility of the implementation, that is the >> class (nothing new here), so we delay that decision until the trait is >> used. >> So, maybe what we need is a way to indicate that a message send in a >> trait is not really that in a class... For example: >> >> TraitA>>m1 >> >> ^self name first >> >> Object subclass: #ClassA >> uses: #TraitA >> mapping: (MessageSendToInstanceVariable from: #name to: 'firstName') >> ... bla bla. >> >> So, #m1 in ClassA would look like: >> >> ClassA>>m1 >> >> ^firstName first >> >> Of course this implies some complexity when copying the behavior from the >> trait to the class (we can not use the same compiled method), also >> maintaining the relationship with changes on the trait (what happens if #m1 >> is changed in TraitA and does not send #name anymore), etc. >> First class slot (a la Self) would be a nicer solution, >> > > For the slower ones ... why would first class slots solves this? I didn't > get it. > > Thanks! > > > >> but I feel that that implies a more radical change on the object model, >> vm, etc. and also has the disadvantages of making all state public (unless >> something is done to avoid that). >> >> At the same time, I would like to point out that having subclassing and >> traits at the same time as sharing mechanism is kind of confusing, >> programmers do not know which one is better to use, should I subclass or >> use a trait? how I'm sure which one is better? etc. We talk about this when >> you came to Argentina, do you remember? A student did his tesis about >> removing subclassing and using only traits as sharing tool, but the results >> were not as good as I expected (sadly, the thesis is written in Spanish...) >> >> Anyway, my two cents >> Hernan. >> >> >> On Thu, Feb 16, 2012 at 4:56 AM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> >>> On Feb 15, 2012, at 11:30 PM, Hernan Wilkinson wrote: >>> >>> > what is the difference with the current trait implementation in pharo? >>> I could not see the differenceâ¦ >>> >>> Stefan replied but what I wanted to say is that I would like to have the >>> time to see how we can introduce more nicely traits. >>> Right now there are edges where this is ugly and also rethink the >>> system. I think that if we would have first class slots we could have >>> traits with state in a much better fashion. >>> >>> Stef >>> >>> > On Wed, Feb 15, 2012 at 7:45 AM, StÃ©phane Ducasse < >>> stephane.ducasse(a)inria.fr> wrote: >>> > Indeed. Now I would love that we rethink our trait implementation and >>> tool support but no time. >>> > >>> > On Feb 15, 2012, at 6:40 AM, blake wrote: >>> > >>> > > This is kinda cool: >>> > > >>> > > http://phpmaster.com/using-traits-in-php-5-4/ >>> > > >>> > >>> > >>> > >>> > >>> > >>> > -- >>> > HernÃ¡n Wilkinson >>> > Agile Software Development, Teaching & Coaching >>> > Mobile: +54 - 911 - 4470 - 7207 >>> > email: hernan.wilkinson(a)10Pines.com >>> > site: http://www.10Pines.com >>> > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina >>> > >>> >>> >>> >> >> >> -- >> *HernÃ¡n Wilkinson >> Agile Software Development, Teaching & Coaching >> Mobile: +54 - 911 - 4470 - 7207 >> email: hernan.wilkinson(a)10Pines.com >> site: http://www.10Pines.com <http://www.10pines.com/>* >> Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

Feb. 16, 2012

Re: [Pharo-project] Is the plan to replace FileStream by FSStream?

by Henrik Johansen

On Feb 16, 2012, at 6:45 PM, Luc Fabresse wrote: > Hi, > > reading this: http://code.google.com/p/pharo/issues/detail?id=5303 > I wonder if the plan is to replace FileStream by FSStream? > > #Luc > My vote would be no. http://forum.world.st/pharo-vision-tp4340345p4342871.html http://forum.world.st/pharo-vision-tp4340345p4341445.html You'd be stuck chasing bugs trying to bring FSFileStreams up to pair with the normal FileStreams for many, many releases. I'd rather try one of the approaches mentioned in the 2nd link, setting StandardFileStream as the default plugged-in stream implementation, so you could rewrite the path API manipulation in your code independent of the stream/file reading/writing. Cheers, Henry

Feb. 16, 2012

Re: [Pharo-project] Refactoring Questions

by Eliot Miranda

Why not have a separate "edit" called e.g. eliminate common sub-expression? Preserve the true refactoring and add an edit that searches for all occurrences of the selected sub-expression, prompting for a temp var? The fact that refactorings are safe is important. That doesn't make other modifications useless, but it doesn't make them refactorings either :) On Thu, Feb 16, 2012 at 10:25 AM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > after having a look with ben at the current refactoring implementation in > Nautilus > we found that the "Extract into temporary" refactoring is most of the time > not that useful. > > I wonder wether it would make sense to loosen the requirements on > conserving behavior... > > consider the following example where we extract "self foo" into the > temporary "tmp": > =========================================== > foo > ^ self foo even > ifTrue: [ self foo * 2 ] > ifFalse: [ self foo / 2 ] > > actual result ============================= > foo > | tmp | > tmp := self foo. > ^ tmp even > ifTrue: [ self foo * 2 ] > ifFalse: [ self foo / 2 ] > > proposed result =========================== > foo > | tmp | > tmp := self foo. > ^ tmp even > ifTrue: [ tmp * 2 ] > ifFalse: [ tmp / 2 ] > =========================================== > note that the proposed solution is not side-effect free. > > However the given refactoring hardly makes ever sense, since this action > can be easily > done manually in less time. given that you first have to find the proper > menu-item. > > best > cami > -- best, Eliot

Feb. 16, 2012

Re: [Pharo-project] TabbedPane Class/ Package / Workspace browsers

by Jimmie Houchin

I agree. I value highly many of the abilities our current UI. I would not want to give up the ability to have multiple browsers open and placed in certain positions to give me view into code in multiple areas as I edit whatever I am editing. I do agree that we could make improvements and that we haven't arrived at the ultimate solution. I don't even think anyone knows what that is. I don't have a problem with having an IDE-like window featured as desired for those who want such. You could possibly have a world menu item for IDE Window, which would open up a new IDE window. You could multiple such windows. That's one thing I always wished for when developing a Python project in PyDev (Eclipse) is that I could have multiple IDE windows, one for each project I am working on. The tabbed interface just gets in my way. I would love to see the day that IDEs for other languages are or could be written in Pharo instead of Java. We could have a better Python, Ruby, ..., IDE written in Pharo than Eclipse. One thing I would find interesting with tabs is if I could have a window with tabs where I group things that I want in that window. Browsers, Workspaces, etc. I don't know TWM may provide just that. I haven't had the time to explore and learn TWM. One thing that new users of the Smalltalk IDE need to realize up front is that our ui is more operating system like than IDE like. We wouldn't want to limit our OS to a single window and tabs. When I develop in Python I have more than one window open. I have PyDev in one, a REPL in another, GitGui, ... But people unfamiliar with Smalltalk impose views which just need adjusted or educated. For me personally, I feel like I am doing an elegant, graceful dance when programming in Pharo/Smalltalk. When developing in Python, etc., it feels like me an my partners are stepping all over each others feet. Little to no integration, little to no cooperation between tools. People who love Eclipse, Emacs, and all there toolchains might feel that that is their elegant dance. But for me its two left feet. Jimmie On 2/16/2012 2:38 AM, Fernando Olivero wrote: > Hi, i wanted to comment a bit on the proposed ui. > > The problem with this single-window with tab panes, is that it forces > the user to have a single focus of attention, which produces an > overhead in navigation for those programming tasks that require > looking at more than one element at a time. > > Thats why i see more value in our current user interface, of course it > can highly improved... > > Fernando > On Thu, Feb 16, 2012 at 8:57 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Nice >> >> Stef >> >> On Feb 16, 2012, at 7:15 AM, S Krish wrote: >> >>> >>> >>> Just this quick n usable prototype.. ? >>> >>> Any comments of its utility.. I for one would rather prefer having everything navigable from one Tabbed Pane.. >>> >>> Panes capable of rendering about every window of the basic tools of Pharo.. workspace, Finder, ScriptManager, possibly Transcript as a console collapsible as reqd >>> >>> Akin to the eclipse but not really that intensively single windowed.. there are uses for spawning separate windows.. >>> >>> <PharoTabbedBrowsers.jpg> >> >> > >

Feb. 16, 2012