- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3506 in pharo: TextMorph's #autoFit: and #wrapFlag: are confusing

by pharo＠googlecode.com

Comment #4 on issue 3506 by sean.p.d...(a)gmail.com: TextMorph's #autoFit: and #wrapFlag: are confusing http://code.google.com/p/pharo/issues/detail?id=3506 Okay, I'll look for the files

Jan. 22, 2011

Re: [Pharo-project] Some important news

by S Krish

Great News.. On Sat, Jan 22, 2011 at 12:56 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Hi guys > > some important news today, we decided that we will set up a pharo > association > so that we can promote pharo. We would like to be able to collect money and > create bounties to improve pharo. > > Stef >

Jan. 22, 2011

[Pharo-project] collapsing panes

by Tudor Girba

Hi, I have a question about how to obtain an effect similar to minimizing a pane in Eclipse. Let's consider the example from below. I have a ProportionalLayout because I want to fill the entire space and be able to resize the inside panes. Now, I would also like to have some way of collapsing one of the panes and have the rest resize to fill the rest of the space. It's a bit like I would need some part of a behavior from the TableLayout. Can anyone provide me with some hints in this direction? Do I need to create a new Layout? | container morph1 morph2 morph3 window | container := PanelMorph new. morph1 := PanelMorph new fillStyle: (SolidFillStyle color: Color red). morph2 := PanelMorph new fillStyle: (SolidFillStyle color: Color blue). morph3 := PanelMorph new fillStyle: (SolidFillStyle color: Color yellow). container changeProportionalLayout. container addMorph: morph1 fullFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 0.33)). container addMorph: morph2 fullFrame: (LayoutFrame fractions: (0 @ 0.33 corner: 1 @ 0.66)). container addMorph: morph3 fullFrame: (LayoutFrame fractions: (0 @ 0.66 corner: 1 @ 1)). container addPaneSplitters. container fillStyle: (SolidFillStyle color: Color yellow). container extent: 400@400. container openInWindow. Cheers, Doru -- www.tudorgirba.com "Be rather willing to give than demanding to get."

Jan. 21, 2011

Re: [Pharo-project] Instruments for headless images

by Eliot Miranda

On Fri, Jan 21, 2011 at 1:35 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Eliot > > it is possible with the current vms? > I think not, but I think its really really close. Basically instead of the VM responding to -headless you'd have the image respond to -headless and arrange that all the code that starts-up the GUI window is called from a new primitive, say, openDisplay. Right now (I think) the VM decides whether to open up the main display or not, and does so by looking for a -headless argument, and if not found, opening the GUI window which remains blank. Ask Igor to trace through the startup code on each platform, looking for "headless" in the source and I'm sure he'll find it. best Eliot > Stef > On Jan 21, 2011, at 9:15 PM, Eliot Miranda wrote: > > > > > > > On Fri, Jan 21, 2011 at 11:44 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > Eliot > > > > does it mean that we could run headless and that if specified on the > command line we could for example get a debugger open on bugs? Because I > would love that for coral. > > > > Exactly. In fact I think one mode is that one can get the system to > snapshot when the error happens, one can then send the snapshot to a > developer, and the snapshot comes up headful with the debugger. > > > > > > Stef > > > > >

Jan. 21, 2011

[Pharo-project] Fwd: Thanks !!!

by StÃ©phane Ducasse

Hi lille/douai/bruxelles pharo sprinters Thanks for all this good energy. Yesterday I went to a javascript conference and my energy was low to see how we (smalltalkers) would better organized and pushing. Now today it was good energy. Thanks again. Stef

Jan. 21, 2011

Re: [Pharo-project] Issue 3568 in pharo: Remove SelectorBrowser

by pharo＠googlecode.com

Comment #2 on issue 3568 by marianopeck: Remove SelectorBrowser http://code.google.com/p/pharo/issues/detail?id=3568 sorry, and the old recent changes too

Jan. 21, 2011

Re: [Pharo-project] Gofer issue

by Dale Henrichs

On 01/21/2011 01:28 PM, Miguel CobÃ¡ wrote: > El vie, 21-01-2011 a las 13:10 -0800, Dale Henrichs escribiÃ³: >> Miguel, >> >> A timestamp isn't sufficient in the presence of branching. How do other >> SCMs identify branches? > > I am not an expert, for sure :), but the way Git works AFAICT is by > storing in files the SHA1 hash of all the branches heads reachable. > That is, if you don't have a pointer to the head of a branch you can't > reach the branch, even if the commit is there. > Git also stores a history of the last n branches you have visited in > case you by accident delete the file containing the pointer to a branch > head. > So the metadata of git (.git/ folder) has all this information. > when rebuilding branches histories (and for merging) git traverses the > list of parents of two branches until find two commits with the same id > (SHA1) and from there it can do the merge. But as I said, this is > metadata and the commit has no way of knowing to which branch it > belongs. The commit only know the blog of changes, the author, timestamp > and parent(s) commits (if was a merge). > This is different that monticello where, appears to me, the commit (.mcz > file) encodes the author, branch, version number and package name. > In git, there are only blobs that have a defined structure and are named > just with the SHA1 hash of the bytes changed in that commit. > > For more info (very readable) check: > > http://progit.org/book/ch3-1.html > http://progit.org/book/ch9-0.html Thanks Miguel, Thats interesting. Actually, the mcz file itself has all of the meta data embedded in it...full history, including UUIDs for each of the versions...the meta information has been encoded into the mcz file name to make it easy for humans and tools to guess what the meta data is (and 99% of the time the mcz file name and meta data match:) Without info encoded in the mcz file name, the tools have to crack open every one of the mcz files in a repository in order to build the real version structure... Presumably a new version of SqueakSource could maintain separate metadata files and then in-image tools could use that metadata to present the mcz files in a coherent manner ... then there would be no need to care what the mcz file was named, the UUID would probably be sufficient... Dale

Jan. 21, 2011

Re: [Pharo-project] Issue 3568 in pharo: Remove SelectorBrowser

by pharo＠googlecode.com

Comment #1 on issue 3568 by marianopeck: Remove SelectorBrowser http://code.google.com/p/pharo/issues/detail?id=3568 Stef, there are 2 things to remove: MessagesSend and MethodFInder I think SelectorBrowser is the UI of MessageSend. Anyway, both guys should be removed (model and UI in case they are spitted)

Jan. 21, 2011

Re: [Pharo-project] Issue 3461 in pharo: [Failing Test] Tests.Release.ReleaseTest.testObsoleteClasses

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3461 by marianopeck: [Failing Test] Tests.Release.ReleaseTest.testObsoleteClasses http://code.google.com/p/pharo/issues/detail?id=3461 yes, so I close this one and I opened this one: http://code.google.com/p/pharo/issues/detail?id=3571

Jan. 21, 2011

[Pharo-project] Issue 3571 in pharo: [Failing Test] Tests.Release.ReleaseTest.testUndeclared

by pharo＠googlecode.com

Status: Accepted Owner: marianopeck Labels: Milestone-1.2-DevImage New issue 3571 by marianopeck: [Failing Test] Tests.Release.ReleaseTest.testUndeclared http://code.google.com/p/pharo/issues/detail?id=3571 Tests.Release.ReleaseTest.testUndeclared is failing

Jan. 21, 2011