December 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] feature request - undo closed tab

by btc＠openInWorld.com

Neglecting that in 6 months I might be in a position try implementing this myself, here is a feature request in case anyone likes it enough to implement it in the meantime, or who can advise why it is a bad idea. Background: For me, one of the greatest most useful features of web browsers is the "Undo Close Tab." I browse almost exclusively opening all links as new tabs since I find this the fastest to follow diversions and then return to my previous place up the stack of tabs. I can get 20 or more odd tabs in a browser window. When I'm speedily closing tabs to backtrack my position, I find my recognition of content often lags my tab closing by a split second. Being able to un-close that last tab is a lifesaver. Now that I am getting into actual programming in Pharo, I have found that from time to time I've ended up with more than a dozen tabs in the "task bar" at the bottom of World. A few times already when I've flicking through these closing them after finish a line of thought, I have accidentally closed some tabs that I wanted to keep - like the Workspace I had been using as a bit of a history log. Perhaps my workflow is bad - but I really miss being able to Undo closing that last window. Features: 1. For a window that has a tab on the "task bar" at the bottom of World, when it is closed allow it to be reopened in the same state. 2. Clicking on the "Task bar" provides a menu item "Undo Close Tab" that either: 2a. Brings back the last closed tab. 2b. Provides a "restore list" of previously closed tabs sorted by time closed, which brings back that tab. Implementation Idea: 3. When closing a tab, rather than actually closing it, the window is just minimised but is removed from the tab and placed on the "restore list". 4a. The "restore list" is a certain length and when a tab is bumped off the end it is properly closed. 4b. Alternatively tabs may remove themselves from the "restore list" after a certain timeout eg 30 minutes. I'd appreciate your thoughts... cheers, Ben

Dec. 27, 2011

Re: [Pharo-project] Enhancing Athens: about lines caps and joins

by Fernando Olivero

Nice design, Thanks for the info. Excellent that you cleaned the repo also! Do the gradients: linear and radial, will belong to the Paint object ? Fernando On Wed, Dec 21, 2011 at 2:08 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > You can check an AthensStrokePaint class > which is just a prototype for that capability. > Unfortunately , balloon engine does not supports most of these options. > But with Cairo i now can reify them nicely. > > -- > Best regards, > Igor Stasenko.

Dec. 27, 2011

Re: [Pharo-project] Destiny of changed:/update:

by Andres Valloud

To clarify... where is says "if finalization is robust enough, then it will continue finalizing", it means "if [the] finalization [process that kicks off finalization on individual weak arrays by draining the finalization queue] is robust enough [so that the hang in w's finalization doesn't bring down the whole thing], then it will continue finalizing [other objects]". On 12/27/11 3:47 , Andres Valloud wrote: > He might imply "any finalization process that runs on the weak > collection after the objects are collected must be thread safe", which > seems reasonable. You may get away with free "atomic" finalization if > you have a finalization queue... but not always. For example, what > happens if the finalization queue contains the weak array w (because the > GC nilled some of w's slots), then the image starts finalizing w but the > process has a DNU of some sort so it stops... if finalization is robust > enough, then it will continue finalizing. Then you get another GC, w > gets added to the finalization queue again because some other of its > slots got nilled, and then the finalization is kicked off on w *again* > while the first one is hung with the debugger open... > > On 12/27/11 2:39 , Igor Stasenko wrote: >> i cannot get it, how weak type containers are related to thread safety? >> A garbage collection happens instantly for language side , so there is >> no way how a weak collection can be in inconsistent state when >> it is not known yet, if object is dead or alive. >> By accessing an object in weak container, you put it's reference on >> stack, which means that if GC will happen at that stage, a >> corresponding object will not be >> collected until at least next GC phase. >> >> Now what is "thread-safe weak collections" and what they should serve for? >> WeakIdentityKeyDictionary? It is not thread-safe. And why it should, >> when you can easily make it thread-safe by wrapping it with >> appropriate container object. >> What else? >> WeakArray? it is already thread safe: reads and writes are primitives >> and size is immutable. >> >> What else? weak set? again, put a wrapper around it and you got thread-safety. >> >> And what is 'self-repairing'? Can you explain what is it? >> >> -- >> Best regards, >> Igor Stasenko. >> >

Dec. 27, 2011

Re: [Pharo-project] DBXTalk site errors

by Torsten Bergmann

Guille wrote: > Are you sure? :S I've tried > http://dbxtalk.smallworks.com.ar/pier/Documentation/creating-your-first-dbx… > I can reach the page... > The above link in your mail was also not correct due to a missing space. I think http://dbxtalk.smallworks.com.ar/pier/Documentation/creating-your-first-dbx… is the correct one and this page is accessible What I mean is that on http://dbxtalk.smallworks.com.ar/pier/news/2011-12-26 there is a section "Where is the documentation?" with two links: 1. http://dbxtalk.smallworks.com.ar/pier/Download First Phoseydon doc 2. http://dbxtalk.smallworks.com.ar/pier/Documentation/creating-your-first-dbx… First link (to a *.doc file ??) is not working. Bye T. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

Dec. 27, 2011

Re: [Pharo-project] Destiny of changed:/update:

by Andres Valloud

He might imply "any finalization process that runs on the weak collection after the objects are collected must be thread safe", which seems reasonable. You may get away with free "atomic" finalization if you have a finalization queue... but not always. For example, what happens if the finalization queue contains the weak array w (because the GC nilled some of w's slots), then the image starts finalizing w but the process has a DNU of some sort so it stops... if finalization is robust enough, then it will continue finalizing. Then you get another GC, w gets added to the finalization queue again because some other of its slots got nilled, and then the finalization is kicked off on w *again* while the first one is hung with the debugger open... On 12/27/11 2:39 , Igor Stasenko wrote: > i cannot get it, how weak type containers are related to thread safety? > A garbage collection happens instantly for language side , so there is > no way how a weak collection can be in inconsistent state when > it is not known yet, if object is dead or alive. > By accessing an object in weak container, you put it's reference on > stack, which means that if GC will happen at that stage, a > corresponding object will not be > collected until at least next GC phase. > > Now what is "thread-safe weak collections" and what they should serve for? > WeakIdentityKeyDictionary? It is not thread-safe. And why it should, > when you can easily make it thread-safe by wrapping it with > appropriate container object. > What else? > WeakArray? it is already thread safe: reads and writes are primitives > and size is immutable. > > What else? weak set? again, put a wrapper around it and you got thread-safety. > > And what is 'self-repairing'? Can you explain what is it? > > -- > Best regards, > Igor Stasenko. >

Dec. 27, 2011

Re: [Pharo-project] Destiny of changed:/update:

by Igor Stasenko

i cannot get it, how weak type containers are related to thread safety? A garbage collection happens instantly for language side , so there is no way how a weak collection can be in inconsistent state when it is not known yet, if object is dead or alive. By accessing an object in weak container, you put it's reference on stack, which means that if GC will happen at that stage, a corresponding object will not be collected until at least next GC phase. Now what is "thread-safe weak collections" and what they should serve for? WeakIdentityKeyDictionary? It is not thread-safe. And why it should, when you can easily make it thread-safe by wrapping it with appropriate container object. What else? WeakArray? it is already thread safe: reads and writes are primitives and size is immutable. What else? weak set? again, put a wrapper around it and you got thread-safety. And what is 'self-repairing'? Can you explain what is it? -- Best regards, Igor Stasenko.

Dec. 27, 2011

Re: [Pharo-project] DBXTalk site errors

by Guillermo Polito

On Tue, Dec 27, 2011 at 4:49 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > On the DBXTalk site in the download section there is an error: > > http://dbxtalk.smallworks.com.ar/pier/Download > > If you run > > (((Smalltalk at: #ConfigurationOfGlorpDBX) > perform: #project) > perform: #version with: #stable) > load > > you will get a MNU #version. > I think it should be #version: for all the load examples. > Fixed :) > > Also the page > http://dbxtalk.smallworks.com.ar/pier/Download First Phoseydon doc > referenced on the beta announcement does not exist. > Are you sure? :S I've tried http://dbxtalk.smallworks.com.ar/pier/Documentation/creating-your-first-dbx… I can reach the page... Thanks! Guille

Dec. 27, 2011

[Pharo-project] DBXTalk site errors

by Torsten Bergmann

On the DBXTalk site in the download section there is an error: http://dbxtalk.smallworks.com.ar/pier/Download If you run (((Smalltalk at: #ConfigurationOfGlorpDBX) perform: #project) perform: #version with: #stable) load you will get a MNU #version. I think it should be #version: for all the load examples. Also the page http://dbxtalk.smallworks.com.ar/pier/Download First Phoseydon doc referenced on the beta announcement does not exist. Bye Torsten -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

Dec. 27, 2011

Re: [Pharo-project] Destiny of changed:/update:

by Schwab,Wilhelm K

I did indeed write that weak collections must be thread safe and self-repairing, which is quite correct. It has everything to do with finalization, which can be applied to any object (e.g. the handle body pattern). What good are weak collections if they either prevent garbage collection of their elements (are hence not weak) or can't cope with the finalization of objects that are removed by the garbage collection that they (correctly) did not prevent (incomplete implementation)? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Levente Uzonyi [leves(a)elte.hu] Sent: Monday, December 26, 2011 9:06 PM To: Pharo-project(a)lists.gforge.inria.fr; andres.valloud(a)gmail.com Subject: Re: [Pharo-project] Destiny of changed:/update: On Mon, 26 Dec 2011, Andres Valloud wrote: > That's not how ephemerons work, and they also get finalized. Both of you may > be right... Well, yes, with ephemerons you can implement a finalization mechanism which is triggered when the object is _about to be_ garbage collected (note that the finalize() method in java is similar). But it doesn't mean that finalization has anything to do with weak collections or that weak collections should be thread safe, which is what Bill wrote. Levente > > On 12/26/11 16:49 , Levente Uzonyi wrote: >> On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote: >> >>> Levente, >> >> Not meaning to be confrontational, but finalization does not happen "in" >> any type of collection. It happens *to* elements that can be held in any >> type of weak collection. As a result, they should all be thread safe and >> self-repairing. >> >> >> I guess you're wrong. A weak collection is a collection which doesn't hold >> strong references to its elements, so they can be garbage collected when >> there are no other strong references to them. >> Finalization is a service which triggers an action when an object is >> garbage collected. >> Some finalization techniques require the use of weak collections, but >> otherwise weak collections are independent of finalization. >> >> >> Levente >> >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Levente Uzonyi >> [leves(a)elte.hu] >> Sent: Monday, December 26, 2011 3:10 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Destiny of changed:/update: >> >> On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote: >> >>> Stef, >> >> I completely agree that events/announcements are cleaner and easier to >> understand than changed/update. I don't really care whether or not the >> latter is removed, because I never (directly) use it. Others might prefer >> to have it retained?? >> >> I'm not supposed to say where<g>, but I have seen events, weak collections >> and finalization done *really* well. In fairness, my working image is old >> and I need to take another stab at building a recent image, but when I last >> reviewed them, Pharo's weak collections were lacking features. They have >> to be thread safe, and they need to clear nil entries left behind by >> finalization (which is why they must be thread safe). The better we get >> with events (#on:send:to and friends), the more the current weak >> collections will appear to be lacking. >> >> >> Finalization only happens in WeakRegistries and those are thread safe. The >> other weak collections are not subject to finalization, therefore they >> don't have to be thread safe, that's why they aren't. >> >> >> Levente >> >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse >> [stephane.ducasse(a)inria.fr] >> Sent: Monday, December 26, 2011 10:56 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Destiny of changed:/update: >> >> using on:send: instead of changed/ is a nice way to reduce extra updates. >> In Cuis juan kept only one mechanism and I like that. >> >> In VisualWorks you have to use on:send:to: this way you can select with >> facet is refreshed. >> So I would like to deprecated changed. >> >> Stef >> >>> Will changed:/update: disappear and be totally replaced by Announcements? >>> >>> I ask because I'm using ListModel and noticed that it sends a generic >>> "self >>> changed: #selectionIndex". I built a GUI that had two of them, and >>> couldn't >>> differentiate between the updates, so I was going to enhance it a little. >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> >>> . >> > >

Dec. 27, 2011

Re: [Pharo-project] Destiny of changed:/update:

by Levente Uzonyi

On Mon, 26 Dec 2011, Andres Valloud wrote: > That's not how ephemerons work, and they also get finalized. Both of you may > be right... Well, yes, with ephemerons you can implement a finalization mechanism which is triggered when the object is _about to be_ garbage collected (note that the finalize() method in java is similar). But it doesn't mean that finalization has anything to do with weak collections or that weak collections should be thread safe, which is what Bill wrote. Levente > > On 12/26/11 16:49 , Levente Uzonyi wrote: >> On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote: >> >>> Levente, >> >> Not meaning to be confrontational, but finalization does not happen "in" >> any type of collection. It happens *to* elements that can be held in any >> type of weak collection. As a result, they should all be thread safe and >> self-repairing. >> >> >> I guess you're wrong. A weak collection is a collection which doesn't hold >> strong references to its elements, so they can be garbage collected when >> there are no other strong references to them. >> Finalization is a service which triggers an action when an object is >> garbage collected. >> Some finalization techniques require the use of weak collections, but >> otherwise weak collections are independent of finalization. >> >> >> Levente >> >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Levente Uzonyi >> [leves(a)elte.hu] >> Sent: Monday, December 26, 2011 3:10 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Destiny of changed:/update: >> >> On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote: >> >>> Stef, >> >> I completely agree that events/announcements are cleaner and easier to >> understand than changed/update. I don't really care whether or not the >> latter is removed, because I never (directly) use it. Others might prefer >> to have it retained?? >> >> I'm not supposed to say where<g>, but I have seen events, weak collections >> and finalization done *really* well. In fairness, my working image is old >> and I need to take another stab at building a recent image, but when I last >> reviewed them, Pharo's weak collections were lacking features. They have >> to be thread safe, and they need to clear nil entries left behind by >> finalization (which is why they must be thread safe). The better we get >> with events (#on:send:to and friends), the more the current weak >> collections will appear to be lacking. >> >> >> Finalization only happens in WeakRegistries and those are thread safe. The >> other weak collections are not subject to finalization, therefore they >> don't have to be thread safe, that's why they aren't. >> >> >> Levente >> >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse >> [stephane.ducasse(a)inria.fr] >> Sent: Monday, December 26, 2011 10:56 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Destiny of changed:/update: >> >> using on:send: instead of changed/ is a nice way to reduce extra updates. >> In Cuis juan kept only one mechanism and I like that. >> >> In VisualWorks you have to use on:send:to: this way you can select with >> facet is refreshed. >> So I would like to deprecated changed. >> >> Stef >> >>> Will changed:/update: disappear and be totally replaced by Announcements? >>> >>> I ask because I'm using ListModel and noticed that it sends a generic >>> "self >>> changed: #selectionIndex". I built a GUI that had two of them, and >>> couldn't >>> differentiate between the updates, so I was going to enhance it a little. >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> >>> . >> > >

Dec. 27, 2011