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

Re: [Pharo-project] Gofer issue

by Miguel CobÃ¡

El vie, 21-01-2011 a las 13:55 -0600, Miguel CobÃ¡ escribiÃ³: > Yes we understand, but that only applies to centralized SCM like > subversion. > In a distributed SCM like git and monticello the number means nothing. > e.g. there could be two branches yours and mine, and both have 345 > commits in it. Supposing that we don't skip any number and did nothing > weird, there would be exactly 690 versions and bot > Package-MiguelCoba.345.mcz and Package-IgorStasenko.345.mcz. If you did > those 345 versions in one day and I did mines on a year, one for day, > the only way to know which one is more "recent" is with timestamps. But > the numbers means nothing in distributed SCMs. > > Cheers See, Git don't even use a number, it uses the SHA1 of the bytes that were changed in the repository between commits. That is the most unnumbered-sequentially way to mark a commit. For all practical purposes it is a random number. Cheers

Jan. 21, 2011

Re: [Pharo-project] Gofer issue

by Miguel CobÃ¡

El vie, 21-01-2011 a las 20:50 +0100, Igor Stasenko escribiÃ³: > 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. Yes we understand, but that only applies to centralized SCM like subversion. In a distributed SCM like git and monticello the number means nothing. e.g. there could be two branches yours and mine, and both have 345 commits in it. Supposing that we don't skip any number and did nothing weird, there would be exactly 690 versions and bot Package-MiguelCoba.345.mcz and Package-IgorStasenko.345.mcz. If you did those 345 versions in one day and I did mines on a year, one for day, the only way to know which one is more "recent" is with timestamps. But the numbers means nothing in distributed SCMs. Cheers > > > 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 > >> > > > > > > > > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Jan. 21, 2011

Re: [Pharo-project] Gofer issue

by Igor Stasenko

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. > 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

+1 > What is interesting (and we might make that an option) is that the 'no display' error results in the image being saved 'headfull' so that you can start it up using a display to debug it (suspended process/debugger). >> >> That could be done.. but not as userful as simply report an error. >> Usually we (developers) knowing what we want to do, >> and what i don't want to see in my headless image is any attempts to >> access display/ui. > > Yeah, that's why I said it would better be an option. The first thing to do is simply report the error (and quit, or maybe that should be an option too). But many people playing with headless images (myself included) have had blocking/locked up images: having a log would be great, but adding this option to debug the cause further would be great. > > Sven > >

Jan. 21, 2011

Re: [Pharo-project] Gofer issue

by Miguel CobÃ¡

This thing of the initial is really upsetting. I know that is old history and that even tools were made (monticello) relying on them (even without specifying an accepted format, creating more confusion) but I think that enough is enough. So, monticello hasn't a format for the filenames of the packages, at least one that avoid problems due to initials, fullnames or whatever string that the user happen to write in their image. For Igor, the problem is that he writes his name as Igor.Stasenko. That chokes monticello and gofer and whatnot. Why don't we use the git way and let the user write two things, an email and a free user name. And then sign the monticello packages with email and in a meta-info inside the mcz (or in the commit info/message) use the full name? What do you think? What it would break with a change like this? Cheers El vie, 21-01-2011 a las 20:40 +0100, StÃ©phane Ducasse escribiÃ³: > +1 > > >> 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 CobÃ¡ > > http://twitter.com/MiguelCobaMtz > > http://miguel.leugim.com.mx > > > > > > > > > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Jan. 21, 2011

Re: [Pharo-project] Instruments for headless images

by StÃ©phane Ducasse

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. Stef

Jan. 21, 2011

Re: [Pharo-project] Instruments for headless images

by Igor Stasenko

On 21 January 2011 19:53, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Fri, Jan 21, 2011 at 10:19 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 21 January 2011 19:06, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > >> > On Fri, Jan 21, 2011 at 2:34 AM, Igor Stasenko <siguctua(a)gmail.com> >> > wrote: >> >> >> >> On 21 January 2011 11:28, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >> >> > >> >> > On 21 Jan 2011, at 11:19, Igor Stasenko wrote: >> >> > >> >> >>> What is interesting (and we might make that an option) is that the >> >> >>> 'no >> >> >>> display' error results in the image being saved 'headfull' so that >> >> >>> you can >> >> >>> start it up using a display to debug it (suspended >> >> >>> process/debugger). >> >> >> >> >> >> That could be done.. but not as userful as simply report an error. >> >> >> Usually we (developers) knowing what we want to do, >> >> >> and what i don't want to see in my headless image is any attempts to >> >> >> access display/ui. >> >> > >> >> > Yeah, that's why I said it would better be an option. The first thing >> >> > to >> >> > do is simply report the error (and quit, or maybe that should be an >> >> > option >> >> > too). But many people playing with headless images (myself included) >> >> > have >> >> > had blocking/locked up images: having a log would be great, but >> >> > adding this >> >> > option to debug the cause further would be great. >> >> > >> >> >> >> this is next step.. >> >> >> >> I think this could be set by preference system >> >> on error: >> >> Â - print error to log and quit >> >> Â - print error to log and do save & quit >> >> Â - print error to log and do save new version & quit >> >> >> >> In future , by adding support from VM side we could also have: >> >> Â - switch to interactive(headfull) mode, by creating an OS window >> >> opening debugger , showing dialog(s) etc etc >> > >> > The VW headful/headless switch requires _no_ additional VM support at >> > all. >> > Â All one needs is stdio support (which we have) and everything else can >> > be >> > done in Smalltalk. >> > >> >> err.. no additional support? you mean it already in there? >> - how to tell VM to close everything at runtime and become headless > > There's an openDisplay primitive that is used ever time the system comes up > headless. Â IFAIA one never goes directly headless from a headful state. > Â Instead one saves headless and resumes the snapshot headless. "Saving > headless" means doing a snapshot that sets a variable such that when the > saved image resumes it doesn't do an openDisplay. What one does do is > dynamically become headful, and to do that one just uses the openDisplay > primitive. Â (FYI openDisplay is primitive #960). >> >> - how to tell VM to create a new window(s) and turn from headless to >> headful mode? > > UseÂ openDisplay. > that what i meant by saying 'VM support' SqueakVMs don't have such primitive. But maybe we don't need it, because i think it would be much better to give image a full control upon creation/closing of host windows. So, image could decide by own what to do (and then you even don't need to a special handling in VM for headless mode, since it will be a decision which image does, not VM). -- Best regards, Igor Stasenko AKA sig.

Jan. 21, 2011

Re: [Pharo-project] Gofer issue

by StÃ©phane Ducasse

So what is the convention because I would like to enforce it. There is no need to have more mess. 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 >

Jan. 21, 2011

Re: [Pharo-project] [squeak-dev] Re: Instruments for headless images

by Igor Stasenko

On 21 January 2011 20:19, Chris Muller <asqueaker(a)gmail.com> wrote: > Considerations about improving headless support need to not only be > about what to do with error output. Â When "running headless," the user > is taking on a different kind of interaction with the system; it is > now an industrial interface instead of the GUI, but it *is* a > user-interface nonetheless. Â Therefore interacting with the system > this way should address *input* as well as output. > > The input in the industrial environment consists of the name of a > Smalltalk script + command-line arguments to that script. > >> this is next step.. >> >> I think this could be set by preference system >> on error: >> Â - print error to log and quit >> Â - print error to log and do save & quit >> Â - print error to log and do save new version & quit > > It's important to allow the same image to be used by multiple scripts, > some of which might want to exit without saving, some which want to > save under a new name. Â "How-to-quit" should be specific to each input > script, not a global preference in the image. > Yes, but i'm not talking about scripts which are crafted specifically to run for headless images and aware about various nuances. I am talking about scripts which are quickly coded without any precautions, because most of users can't make difference between running headless and headful and where all problems can arise from.. So for such scripts image should behave adequately and not hang in undetermined state waiting an input from potential user. It should use these settings as default ones. I just wanna make life a bit easier for people :) > Regards, > Â Chris > > -- Best regards, Igor Stasenko AKA sig.

Jan. 21, 2011

Re: [Pharo-project] Gofer issue

by StÃ©phane Ducasse

+1 >> 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 CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > >

Jan. 21, 2011