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

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

Re: [Pharo-project] PharoSound

by StÃ©phane Ducasse

Thanks > 2 steps: > 1: Apply slice in Issue 3566 to 1.2 and 1.3 I will do that. > 2: Update Metacello ConfigurationOfSound to use > > http://www.squeaksource.com/PharoSound > > as repository, with: > For 1.2: > - latest versions of all packages > For 1.1/1.1.1 : > - latest version of SoundMorphicUserInterface > - version 53 of Sound > - No inclusion of Settings-Sound > > > And yes, they include all changes from NonCorePackages, plus preserve all settings so you can avoid crashing the VM if you want :) > > Cheers, > Henry >

Jan. 21, 2011

Re: [Pharo-project] Gofer issue

by StÃ©phane Ducasse

> > I can tell you more. I am specifically using this name, because: > when system asked me to enter initials, it wasn't warned me that my > name is wrong or refused to use it > and from that point, when something doesn't works because of my > initials, this is NOT my fault. This is a fault of those tools, > which put too much assumptions about what user could enter into text > field when asked. > > So, lets fix the tools, instead of arguing , what convention should > be. There should not be any convention about what i can use as my user > name. > I can choose to use Egyptian glyphs for initials. And don't force me > to follow some scheme if its not necessary. Yes this is what we started to do with the authorfullname

Jan. 21, 2011

Re: [Pharo-project] Gofer issue

by StÃ©phane Ducasse

On Jan 21, 2011, at 8:50 PM, Igor Stasenko wrote: > On 21 January 2011 20:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> So what is the convention because I would like to enforce it. >> There is no need to have more mess. >> > > i prefer to have > > {PackageName}[-{subname}]*-(.*)\.{number}\.mcz > > where in (.*) could be anything and we don't really should care. > > And i'm not agree about numbering. > Number is userful way to tell that my version is more recent than > yours _without_ checking the date of file or even worse, > checking the date(s) inside a file. but you cannot simply since the numbering is local to your repository. I could publish a more recent package with a small number and push it in your repository. > >> Stef >> >> >> On Jan 21, 2011, at 6:48 PM, Dale Henrichs wrote: >> >>> On 01/21/2011 08:11 AM, Miguel CobÃ¡ wrote: >>>> El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribiÃ³: >>>> >>>>> Okay, i found the solution. Use Installer ! >>>>> >>>>> Installer monticello http: 'http://www.squeaksource.com'; >>>>> project: 'VMMaker'; >>>>> install: 'CMakeVMMaker' >>>>> >>>>> >>>>> works well for me and loads correct *latest* version. >>>> >>>> That isn't a solution and open again a gratuitous discussion about gofer >>>> vs installer. >>>> >>>> The point is, in a distributed SCM system, like Monticello is, there >>>> isn't a latest version. At least not by the traditional (suversion for >>>> example) way of knowing the monotone numeric integer version number. As >>>> Lukas said, the only way to know something is latest is to compare >>>> timestamps, but not version numbers or commits id. They aren't not >>>> intended to be ordered respect to time. >>>> >>>> Cheers >>>> >>> >>> It seems to me that that isn't quite the issue ... for Metacello I had to change the sort algorithm that Gofer used to more closely match the algorithm used by the Monticello GUI when it sorts packages ... to minimize the surprise for developers who are used to the Monticello GUI sorting order... I also had to change the branch naming scheme that was used by Gofer, because it caused problems when package names inadvertently looked like a branch to Gofer when it wasn't...Since there has never been an enforced naming convention in Monticello, there are a whole lot of incompatible naming schemes being used... >>> >>> BTW, I made these changes so that they only applied to Metacello's use of Gofer ... >>> >>> Dale >>> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Jan. 21, 2011

Re: [Pharo-project] Instruments for headless images

by StÃ©phane Ducasse

Eliot it is possible with the current vms? 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

Re: [Pharo-project] Gofer issue

by Miguel CobÃ¡

El vie, 21-01-2011 a las 13:10 -0800, Dale Henrichs escribiÃ³: > On 01/21/2011 08:11 AM, Miguel CobÃ¡ wrote: > > El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribiÃ³: > > > >> Okay, i found the solution. Use Installer ! > >> > >> Installer monticello http: 'http://www.squeaksource.com'; > >> project: 'VMMaker'; > >> install: 'CMakeVMMaker' > >> > >> > >> works well for me and loads correct *latest* version. > > > > That isn't a solution and open again a gratuitous discussion about gofer > > vs installer. > > > > The point is, in a distributed SCM system, like Monticello is, there > > isn't a latest version. At least not by the traditional (suversion for > > example) way of knowing the monotone numeric integer version number. As > > Lukas said, the only way to know something is latest is to compare > > timestamps, but not version numbers or commits id. They aren't not > > intended to be ordered respect to time. > > > > Cheers > > > > 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 Cheers > > Dale -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Jan. 21, 2011