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

[Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting.

by Philippe Marschall

Hi With the latest cog VMs I get: can't infer base LD_LIBRARY_PATH. Aborting. Gentoo 64bit, Linux 3.1 LD_LIBRARY_PATH is not set but libtool is present. Cheers Philippe

Dec. 27, 2011

Re: [Pharo-project] Programmatic creation of classes Re: [ANN][Beta Release] DBXTools - Magritte Scaffolding - Phoseydon

by Guillermo Polito

DBXMagritteClassBuilderVisitor>>buildAccessorForAttribute: attribute inClass: aClass > could you give me a pointer to read up on what the curly-brace-numbers are? > The curly braces in the string are just for string formatting, the second one is a dynamic array: 'hello {1}! How's your {2}?' format: { 'Ben' 'metaprogramming' }. What that method does is creating the accessors, ending up in a final string like this for the mutator: 'someAccessor: aParam instVar := aParam' > > btw, Can you advise how is the compiling activated? If you had about 800 > classes that need to be created, would temporarily turning off the compile > assist the program execution time significantly? > I cannot give a good answer here. Maybe someone has better knowledge on the compiler and it's settings. Maybe creating a giant script with all the class creations is faster than 800 scripts. Or Maybe not significantly :P. Maybe disabling the UI notification enhances it a little bit. I've never worried about it a lot :P. Cheers, Guille

Dec. 27, 2011

Re: [Pharo-project] System Browser - shifting class comments into pane beneath class definition

by Ben Coman

Mariano Martinez Peck wrote: > Hi Ben. For me it would make a lot of sense. I have already argued several > times that "?" is amazingly hidden. NOBODY can see it. You must have a 5 > years Pharo degree to find it ;) > > The problem is OB, I am not sure if it is supported by OB and if it is, I > don't know how to enable it. Moreover, if you take a look to Pharo 1.4 > (where OB is not present), you will find that the System Browser in there, > has what you want. > Good to know. thanks Mariano. Pharo 1.4 is just what I was thinking, except that when the window is resized, rather than holding the split at 50%, I'd prefer the class definition pane size held fixed and let more of the class comment show. > On Tue, Dec 27, 2011 at 4:04 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> I could not find any previous discussion of this so I'll just throw this >> out there... >> >> I find that I forget to click the "?" button to read the class comments as >> I browse around the system. They are "kind of" hidden. Perhaps also I stop >> looking because they are often empty. If others do the same then it is a >> downward spiral... if it seems no one looks at them then no one values >> writing them. (Except for the good work of the COTDC) >> >> However System Browser opens by default with 16 lines. >> Most class definitions (eg [1]) use 6 lines, which leaves a lot of unused >> whitespace. >> I wonder if the class comment was to appear (in a separate pane) beneath >> the class definition then the class definition would be filled out more >> often. Bring the class comments to the fore and perhaps they'll be valued >> more. At least for me, it will ensure that I don't miss where there are >> good comments I can learn from. Also more attention may focus on the poor >> comments due to being more exposed. >> just a random thought... >> cheers, Be

Dec. 27, 2011

[Pharo-project] Programmatic creation of classes Re: [ANN][Beta Release] DBXTools - Magritte Scaffolding - Phoseydon

by Ben Coman

Guillermo Polito wrote: > *What does Phoseydon beta includes?* > By now, it reads a database schema, builds a model description from it and > then allows us to: > - write classes from that description. > I am very interested in the programmatic creation of classes. Although my application is not quite related to database schema. Instead I have a UML model stored in a database basically defined by two tables t_objects and t_connector from which I need to create Smalltalk classes, instance variables, and association & aggregate relationships. I tracked down a lot of what I want to the methods... DBXMagritteClassBuilderVisitor>>visitDBXEntity: aDBXEntity for which the answer was obvious in hindsight - just replicating the call to Object>>subclass::: DBXMagritteClassBuilderVisitor>>buildAccessorForAttribute: attribute inClass: aClass could you give me a pointer to read up on what the curly-brace-numbers are? btw, Can you advise how is the compiling activated? If you had about 800 classes that need to be created, would temporarily turning off the compile assist the program execution time significantly? regards, Ben

Dec. 27, 2011

Re: [Pharo-project] System Browser - shifting class comments into pane beneath class definition

by StÃ©phane Ducasse

This is good point. we should give more space to class comments. On Dec 27, 2011, at 4:04 PM, Ben Coman wrote: > > I could not find any previous discussion of this so I'll just throw this out there... > > I find that I forget to click the "?" button to read the class comments as I browse around the system. They are "kind of" hidden. Perhaps also I stop looking because they are often empty. If others do the same then it is a downward spiral... if it seems no one looks at them then no one values writing them. (Except for the good work of the COTDC) > > However System Browser opens by default with 16 lines. > Most class definitions (eg [1]) use 6 lines, which leaves a lot of unused whitespace. > I wonder if the class comment was to appear (in a separate pane) beneath the class definition then the class definition would be filled out more often. Bring the class comments to the fore and perhaps they'll be valued more. At least for me, it will ensure that I don't miss where there are good comments I can learn from. Also more attention may focus on the poor comments due to being more exposed. > just a random thought... > cheers, Ben > > [1] Object subclass: #Behavior > uses: TPureBehavior > instanceVariableNames: 'superclass methodDict format' > classVariableNames: 'ObsoleteSubclasses' > poolDictionaries: '' > category: 'Kernel-Classes' > > >

Dec. 27, 2011

Re: [Pharo-project] System Browser - shifting class comments into pane beneath class definition

by Mariano Martinez Peck

Hi Ben. For me it would make a lot of sense. I have already argued several times that "?" is amazingly hidden. NOBODY can see it. You must have a 5 years Pharo degree to find it ;) The problem is OB, I am not sure if it is supported by OB and if it is, I don't know how to enable it. Moreover, if you take a look to Pharo 1.4 (where OB is not present), you will find that the System Browser in there, has what you want. Cheers On Tue, Dec 27, 2011 at 4:04 PM, Ben Coman <btc(a)openinworld.com> wrote: > > I could not find any previous discussion of this so I'll just throw this > out there... > > I find that I forget to click the "?" button to read the class comments as > I browse around the system. They are "kind of" hidden. Perhaps also I stop > looking because they are often empty. If others do the same then it is a > downward spiral... if it seems no one looks at them then no one values > writing them. (Except for the good work of the COTDC) > > However System Browser opens by default with 16 lines. > Most class definitions (eg [1]) use 6 lines, which leaves a lot of unused > whitespace. > I wonder if the class comment was to appear (in a separate pane) beneath > the class definition then the class definition would be filled out more > often. Bring the class comments to the fore and perhaps they'll be valued > more. At least for me, it will ensure that I don't miss where there are > good comments I can learn from. Also more attention may focus on the poor > comments due to being more exposed. > just a random thought... > cheers, Ben > > [1] Object subclass: #Behavior > uses: TPureBehavior > instanceVariableNames: 'superclass methodDict format' > classVariableNames: 'ObsoleteSubclasses' > poolDictionaries: '' > category: 'Kernel-Classes' > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 27, 2011

[Pharo-project] System Browser - shifting class comments into pane beneath class definition

by Ben Coman

I could not find any previous discussion of this so I'll just throw this out there... I find that I forget to click the "?" button to read the class comments as I browse around the system. They are "kind of" hidden. Perhaps also I stop looking because they are often empty. If others do the same then it is a downward spiral... if it seems no one looks at them then no one values writing them. (Except for the good work of the COTDC) However System Browser opens by default with 16 lines. Most class definitions (eg [1]) use 6 lines, which leaves a lot of unused whitespace. I wonder if the class comment was to appear (in a separate pane) beneath the class definition then the class definition would be filled out more often. Bring the class comments to the fore and perhaps they'll be valued more. At least for me, it will ensure that I don't miss where there are good comments I can learn from. Also more attention may focus on the poor comments due to being more exposed. just a random thought... cheers, Ben [1] Object subclass: #Behavior uses: TPureBehavior instanceVariableNames: 'superclass methodDict format' classVariableNames: 'ObsoleteSubclasses' poolDictionaries: '' category: 'Kernel-Classes'

Dec. 27, 2011

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

by Levente Uzonyi

(quote fixed by hand) On Tue, 27 Dec 2011, Schwab,Wilhelm K wrote: > 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)? Weak collections are used outside of the scope of finalization, otherwise most of them wouldn't exist. For example Symbols are stored in WeakSets, so when a symbol is not used anymore, itcan be garbage collected. And this is _totally_ unrelated to 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 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 Tue, 27 Dec 2011, 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 The finalization process in Pharo (and Squeak) only handles WeakRegistries. So your example is only theoretic, because the finalization process will never touch WeakArrays. > 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... In Pharo you get a debugger when the finalization process runs into an error, in Squeak (just like in Java), the error is ignored. Levente > > 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] feature request - undo closed tab

by laurent laffont

In TWM there's the concept of world snapshots, go back and forward. I've played with keeping all states history, it can be a start. If you are interested, have a look at TWMWorldSnapshot, TWMWindowSnapshot and TWMWorldRecorder. There's a demo / video here (starting from 6'20) http://magaloma.blogspot.com/2011/06/multiple-worlds-for-twm.html Cheers, Laurent On Tue, Dec 27, 2011 at 2:33 PM, <btc(a)openinworld.com> wrote: > > 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