About Famix-Core-GuillermoSchwarz.12
Locked
About Famix-Core-GuillermoSchwarz.12
 
|
Hi Guillermo
I saw your commit and especially your comment "saving locally first, then remotelly, doesn't simply copy the changes like Mercurial does..." The way it works with Monticello, compared to Git/Mercurial (remember that Monticello was conceived before/in parallel with such systems...) - the save command in MC always creates a new version of your package in the repository you selected - saving a version on a remote repository also saves a local copy - if you want to save a version first locally, then want to copy it later to another repository, use the "copy" command from the MC browser Alternatively, the Gofer API provides commands which are closes to Git/Mercurial workflows: push/fetch etc. See http://www.lukas-renggli.ch/blog/gofer BTW, is the fix complete? Your package only provides a new method FamixReference>>identityInstanceVariables -- Simon _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: About Famix-Core-GuillermoSchwarz.12
|
|
Hi Guillermo,
I checked version the 123 of Famix-Core. Why have you added the comment in the method? FAMIXUnknownVariable>>container self flag: #useless. "seems like this attribute is never set" ^ container FAMIXUnknownVariable defines container:, which has many senders Cheers, Alexandre On 11 Oct 2010, at 09:32, Simon Denier wrote: > Hi Guillermo > > I saw your commit and especially your comment > > "saving locally first, then remotelly, doesn't simply copy the changes like Mercurial does..." > > The way it works with Monticello, compared to Git/Mercurial (remember that Monticello was conceived before/in parallel with such systems...) > - the save command in MC always creates a new version of your package in the repository you selected > - saving a version on a remote repository also saves a local copy > - if you want to save a version first locally, then want to copy it later to another repository, use the "copy" command from the MC browser > > Alternatively, the Gofer API provides commands which are closes to Git/Mercurial workflows: push/fetch etc. > See http://www.lukas-renggli.ch/blog/gofer > > > BTW, is the fix complete? Your package only provides a new method FamixReference>>identityInstanceVariables > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: About Famix-Core-GuillermoSchwarz.12
|
|
In reply to this post by Simon Denier-3
On 11 oct. 2010, at 15:23, Alexandre Bergel wrote: > Hi Guillermo, > > I checked version the 123 of Famix-Core. Why have you added the comment in the method? > > FAMIXUnknownVariable>>container > self flag: #useless. "seems like this attribute is never set" > ^ container > > FAMIXUnknownVariable defines container:, which has many senders Hi Alex I think you took a look at a larger change, not the one from Guillermo. What you see is a change which has been deleted for Moose 4.1. The comment is meant to say this attribute is always nil and hence useless as the importer does not care about setting a container for unknown variables. And since nobody ever complained about a container set to nil, I assume nobody needs container on FamixUnknownVariable. We can always add it later. > > Cheers, > Alexandre > > > On 11 Oct 2010, at 09:32, Simon Denier wrote: > >> Hi Guillermo >> >> I saw your commit and especially your comment >> >> "saving locally first, then remotelly, doesn't simply copy the changes like Mercurial does..." >> >> The way it works with Monticello, compared to Git/Mercurial (remember that Monticello was conceived before/in parallel with such systems...) >> - the save command in MC always creates a new version of your package in the repository you selected >> - saving a version on a remote repository also saves a local copy >> - if you want to save a version first locally, then want to copy it later to another repository, use the "copy" command from the MC browser >> >> Alternatively, the Gofer API provides commands which are closes to Git/Mercurial workflows: push/fetch etc. >> See http://www.lukas-renggli.ch/blog/gofer >> >> >> BTW, is the fix complete? Your package only provides a new method FamixReference>>identityInstanceVariables >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: About Famix-Core-GuillermoSchwarz.12
|
|
> I think you took a look at a larger change, not the one from Guillermo. What you see is a change which has been deleted for Moose 4.1. The comment is meant to say this attribute is always nil and hence useless as the importer does not care about setting a container for unknown variables. And since nobody ever complained about a container set to nil, I assume nobody needs container on FamixUnknownVariable. We can always add it later.
Oh...sorry then... I did just a diff from the actual code and the version 123. cheers, Alexandre > > > >> >> Cheers, >> Alexandre >> >> >> On 11 Oct 2010, at 09:32, Simon Denier wrote: >> >>> Hi Guillermo >>> >>> I saw your commit and especially your comment >>> >>> "saving locally first, then remotelly, doesn't simply copy the changes like Mercurial does..." >>> >>> The way it works with Monticello, compared to Git/Mercurial (remember that Monticello was conceived before/in parallel with such systems...) >>> - the save command in MC always creates a new version of your package in the repository you selected >>> - saving a version on a remote repository also saves a local copy >>> - if you want to save a version first locally, then want to copy it later to another repository, use the "copy" command from the MC browser >>> >>> Alternatively, the Gofer API provides commands which are closes to Git/Mercurial workflows: push/fetch etc. >>> See http://www.lukas-renggli.ch/blog/gofer >>> >>> >>> BTW, is the fix complete? Your package only provides a new method FamixReference>>identityInstanceVariables >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: About Famix-Core-GuillermoSchwarz.12
|
|
In reply to this post by Simon Denier-3
Hi Simon,
Thanks for pointing this out. I understand most distributed version control engines were all done in parallel, I'm still getting used to Mercurial so whenever I find a difference I need to write it down somewhere in order to remember. I'm glad that you replied. I think my commit is incomplete, but I didn't know how to verify that. For some reason the Kernel project showed an asterisk in Monticello, so I guessed that I modified something in the Kernel project. It allowed me to check it in until the last moment when it said "you are not authorized". Following GitHub rules it could allow me fork the kernel project (clone) or allow me to send an email to the Kernel project developers with my change (as suggested in the Cathedral and the Bazaar). I don't know which would be best, but I guess "both" would be the best answer. The comment that you mentioned that I wrote is about how do I know the history in Monticello? For example in Mercurial all the changes are local and then you merge the changes locally by pulling from the remote repository. While Mercurial is not ideal in the sense that having so much dependencies can get confusing, the advantage is that when the central repository goes down, you can easily setup a new repository using a 3 day old copy and ask all committers to point to the new central repository and reapply all their commits. It is so easy because Mercurial calculates on the fly what it needs to push. Monticello on the other hand seems to allow to commit on a change by change basis to wherever I want: A local file, any remote repository, etc. And it is up to me to figure out (and remember) where I stored what. I would be really hard for me to remind any of that. Since I was uploading 2 packages, what I would like is to have a package dependency manager like Maven. Does that already exist or I would need to recreate that from scratch? Regarding how to verify the commit I did, I would expect that there would be a build machine. Since there seems to be no build machine, the process recommended in Pharo by Example is to download the code from Squeak Source into a clean image. Do I need to recreate the project in Monticello and then download the code? Cheers, Guillermo. On Mon, 2010-10-11 at 14:32 +0200, Simon Denier wrote: > Hi Guillermo > > I saw your commit and especially your comment > > "saving locally first, then remotelly, doesn't simply copy the changes like Mercurial does..." > > The way it works with Monticello, compared to Git/Mercurial (remember that Monticello was conceived before/in parallel with such systems...) > - the save command in MC always creates a new version of your package in the repository you selected > - saving a version on a remote repository also saves a local copy > - if you want to save a version first locally, then want to copy it later to another repository, use the "copy" command from the MC browser > > Alternatively, the Gofer API provides commands which are closes to Git/Mercurial workflows: push/fetch etc. > See http://www.lukas-renggli.ch/blog/gofer > > > BTW, is the fix complete? Your package only provides a new method FamixReference>>identityInstanceVariables > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simplex Veri Sigillum _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: About Famix-Core-GuillermoSchwarz.12
|
|
In reply to this post by Alexandre Bergel
Hi Alexandre,
I also have that change in my image, but I don't remember adding it, nor why would I flag anything in FAMIX. Cheers, Guillermo. On Mon, 2010-10-11 at 10:21 -0300, Alexandre Bergel wrote: > FAMIXUnknownVariable -- Simplex Veri Sigillum _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: About Famix-Core-GuillermoSchwarz.12
|
|
Hi Guillermo,
First of all, welcome to Moose :). Regarding your commit, given that changing the core packages of Moose can have a large impact, I would kindly ask you to introduce your ideas before committing. We also would typically like to see tests going hand in hand with commits. So, could you describe your context a bit? Cheers, Doru On 11 Oct 2010, at 18:49, Guillermo Schwarz wrote: > Hi Alexandre, > > I also have that change in my image, but I don't remember adding it, nor > why would I flag anything in FAMIX. > > Cheers, > Guillermo. > > On Mon, 2010-10-11 at 10:21 -0300, Alexandre Bergel wrote: >> FAMIXUnknownVariable > -- > Simplex Veri Sigillum > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Being happy is a matter of choice." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: About Famix-Core-GuillermoSchwarz.12
|
|
Hi Tudor,
Thanks I'm glad to participate in Moose. I had no idea I was commiting against Moose, I thought it was against XUnitFamix.Maybe I don't understand the Monticello's project structure. Ok, this idea is actually Alexandre's: "having Moose recognize unit tests". It doesn't seem complex given the feats Moose and Famix already have achieved, namely to be able to recognize new patterns. Well, in order to do that Alexandre created for me XUnitTest, while I'm familiar with old Smalltalk IDEs, I'm not that familiar with Squeak and Pharo, although Pharo is a lot easier to use that Squeak, no doubt about it. At first I thought it should be easy since for every class A I could easily find ATest, so for example to print tested classes in green if they pass their tests and red if they didn't. Unfortunately I've inspected a little bit how SUnit works, I still don't understand it fully, but it seems developers can follow whatever convention they want, for example a class gathers a set of classes that adhere to a protocol (and they simply are included in a list returned by something like Collection>>allCollectionClasses) and then for each class the same test is run. Obviously that requires run time analysis. Well, so far I just want to create unit tests for the XUnitTest project that will discover unit test classes in a Smalltalk image, import them into FAMIX and then display it in Mondrian, not necessarily in that order ;-) Is there any document that explains how to use FAMIX? Cheers, Guillermo. On Mon, 2010-10-11 at 23:28 +0200, Tudor Girba wrote: > Hi Guillermo, > > First of all, welcome to Moose :). > > Regarding your commit, given that changing the core packages of Moose can have a large impact, I would kindly ask you to introduce your ideas before committing. We also would typically like to see tests going hand in hand with commits. > > So, could you describe your context a bit? > > Cheers, > Doru > > > > On 11 Oct 2010, at 18:49, Guillermo Schwarz wrote: > > > Hi Alexandre, > > > > I also have that change in my image, but I don't remember adding it, nor > > why would I flag anything in FAMIX. > > > > Cheers, > > Guillermo. > > > > On Mon, 2010-10-11 at 10:21 -0300, Alexandre Bergel wrote: > >> FAMIXUnknownVariable > > -- > > Simplex Veri Sigillum > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Being happy is a matter of choice." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simplex Veri Sigillum _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: About Famix-Core-GuillermoSchwarz.12
|
|
In reply to this post by Tudor Girba
> So, could you describe your context a bit?
Guillermo is working on introducing the notion of unit test in Moose. Getting static and dynamic coverage, identifying duplication, proposing refactoring are on the roadmap. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: About Famix-Core-GuillermoSchwarz.12
|
|
In reply to this post by Simon Denier-3
HI again Simon,
I looked at Gofer and certainly it looks like hg command line. Thanks! There is commit, update and push, but no pull? The docs in the page are a little bit like "Microsoft help" ;-)
I will take a closer look later. Cheers, Guillermo.
On Mon, Oct 11, 2010 at 9:32 AM, Simon Denier <[hidden email]> wrote: Hi Guillermo -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: About Famix-Core-GuillermoSchwarz.12
|
|
In reply to this post by Simon Denier-3
On 12 oct. 2010, at 15:26, Guillermo Schwarz wrote: HI again Simon, I think that fetch = pull. Lukas could answer precisely. I am not sure about the difference between load and update and merge.
-- Simon _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: About Famix-Core-GuillermoSchwarz.12
|
|
I thought that 'merge' looks at conflicts and warns you if there are some and 'load' just load without warnings, no?
Don't know about update nicolas On Tue, Oct 12, 2010 at 4:11 PM, Simon Denier <[hidden email]> wrote:
-- Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: About Famix-Core-GuillermoSchwarz.12
|
|
In reply to this post by Simon Denier-3
On Oct 12, 2010, at 6:09 PM, Nicolas Anquetil wrote: > I thought that 'merge' looks at conflicts and warns you if there are some and 'load' just load without warnings, no? sure merge does that. load just load a new version without taking care of the old one. erase and load > > Don't know about update > > nicolas > > On Tue, Oct 12, 2010 at 4:11 PM, Simon Denier <[hidden email]> wrote: > > On 12 oct. 2010, at 15:26, Guillermo Schwarz wrote: > >> HI again Simon, >> >> I looked at Gofer and certainly it looks like hg command line. Thanks! >> >> There is commit, update and push, but no pull? The docs in the page are a little bit like "Microsoft help" ;-) > > > I think that fetch = pull. Lukas could answer precisely. > > I am not sure about the difference between load and update and merge. > > >> >> load Load the specified packages. >> update Update the specified packages. >> merge Merge the specified packages into their working copies. >> localChanges Answer the changes between the base version and the working copy. >> browseLocalChanges Browse the changes between the base version and the working copy. >> remoteChanges Answer the changes between the working copy and the remote changes. >> browseRemoteChanges Browse the changes between the working copy and the remote changes. >> cleanup Cleans the specified packages. >> commit Commit the modified specified packages. >> commit: Commit the modified specified packages with the given commit message. >> revert Revert the specified packages to the currently loaded version. >> recompile Recompile the specified packages. >> reinitialize Call the class side initializers on the specified packages. >> unload Unload the specified packages. >> fetch Download versions from remote repositories into the local cache. >> push Upload local versions from local cache into remote repositories. >> >> I will take a closer look later. >> >> Cheers, >> Guillermo. >> >> On Mon, Oct 11, 2010 at 9:32 AM, Simon Denier <[hidden email]> wrote: >> Hi Guillermo >> >> I saw your commit and especially your comment >> >> "saving locally first, then remotelly, doesn't simply copy the changes like Mercurial does..." >> >> The way it works with Monticello, compared to Git/Mercurial (remember that Monticello was conceived before/in parallel with such systems...) >> - the save command in MC always creates a new version of your package in the repository you selected >> - saving a version on a remote repository also saves a local copy >> - if you want to save a version first locally, then want to copy it later to another repository, use the "copy" command from the MC browser >> >> Alternatively, the Gofer API provides commands which are closes to Git/Mercurial workflows: push/fetch etc. >> See http://www.lukas-renggli.ch/blog/gofer >> >> >> BTW, is the fix complete? Your package only provides a new method FamixReference>>identityInstanceVariables >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> -- >> Saludos cordiales, >> >> Guillermo Schwarz >> Sun Certified Enterprise Architect >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > -- > Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: About Famix-Core-GuillermoSchwarz.12
|
|
In reply to this post by Simon Denier-3
If you are working with Alex, I suggest that he shows you the basic tricks when working with Monticello. On 11 oct. 2010, at 18:43, Guillermo Schwarz wrote:
Did you read the stuff about Monticello in Pharo by Example? It might help you to get started. If you think you have changed something in Kernel, check "Changes" to see if it's really yours (sometimes a package such as Kernel appears dirty because of some automatic process) If you do have changes related to your fix in Kernel, then there is a good probability that such changes should be declared as class extensions from your package, not inside Kernel. Check again the Monticello section for how to do that. In most cases, you don't hack core packages such as Kernel unless you found a bug (then you should submit an issue to the Pharo project). You extend core packages with class extensions.
Now it's a question of process. If possible, always commit to the same repository (like on squeaksource). If you are offline and commit only locally, then Gofer can help you to synchronize your local cache with your distant repo. The very basic things to understand with Monticello - a Monticello package is self-contained: you can always load it anywhere - however if you need to merge something, you need all packages in the ancestry so that Monticello can compute the differences with the common ancestor.
If your dependencies are basic and within the same repository, you can use the "required package" feature of Monticello. Otherwise, you will have to use Metacello.
Not sure I understand what you mean. There is an integration server for Moose. Now if your project is not part of Moose default, you have to check by yourself that it loads ok in a new image.
-- Simon _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: About Famix-Core-GuillermoSchwarz.12
|
|
Yes, we will meet on Thursday.
Alexandre On 12 Oct 2010, at 13:56, Simon Denier wrote: > > > If you are working with Alex, I suggest that he shows you the basic tricks when working with Monticello. > > > On 11 oct. 2010, at 18:43, Guillermo Schwarz wrote: > >> Hi Simon, >> >> Thanks for pointing this out. I understand most distributed version >> control engines were all done in parallel, I'm still getting used to >> Mercurial so whenever I find a difference I need to write it down >> somewhere in order to remember. >> >> I'm glad that you replied. I think my commit is incomplete, but I didn't >> know how to verify that. For some reason the Kernel project showed an >> asterisk in Monticello, so I guessed that I modified something in the >> Kernel project. It allowed me to check it in until the last moment when >> it said "you are not authorized". Following GitHub rules it could allow >> me fork the kernel project (clone) or allow me to send an email to the >> Kernel project developers with my change (as suggested in the Cathedral >> and the Bazaar). I don't know which would be best, but I guess "both" >> would be the best answer. > > > Did you read the stuff about Monticello in Pharo by Example? > http://pharobyexample.org/ > > It might help you to get started. > > If you think you have changed something in Kernel, check "Changes" to see if it's really yours (sometimes a package such as Kernel appears dirty because of some automatic process) > > If you do have changes related to your fix in Kernel, then there is a good probability that such changes should be declared as class extensions from your package, not inside Kernel. Check again the Monticello section for how to do that. > > In most cases, you don't hack core packages such as Kernel unless you found a bug (then you should submit an issue to the Pharo project). You extend core packages with class extensions. > > >> >> The comment that you mentioned that I wrote is about how do I know the >> history in Monticello? For example in Mercurial all the changes are >> local and then you merge the changes locally by pulling from the remote >> repository. While Mercurial is not ideal in the sense that having so >> much dependencies can get confusing, the advantage is that when the >> central repository goes down, you can easily setup a new repository >> using a 3 day old copy and ask all committers to point to the new >> central repository and reapply all their commits. It is so easy because >> Mercurial calculates on the fly what it needs to push. >> >> Monticello on the other hand seems to allow to commit on a change by >> change basis to wherever I want: A local file, any remote repository, >> etc. And it is up to me to figure out (and remember) where I stored >> what. I would be really hard for me to remind any of that. > > Yep that's the weak point in Monticello. Although normally, all your history should be in your local cache. So you can always copy from your local cache to another repo. > > Now it's a question of process. If possible, always commit to the same repository (like on squeaksource). If you are offline and commit only locally, then Gofer can help you to synchronize your local cache with your distant repo. > > The very basic things to understand with Monticello > - a Monticello package is self-contained: you can always load it anywhere > - however if you need to merge something, you need all packages in the ancestry so that Monticello can compute the differences with the common ancestor. > > > >> Since I was uploading 2 packages, what I would like is to have a package >> dependency manager like Maven. Does that already exist or I would need >> to recreate that from scratch? > > If your dependencies are basic and within the same repository, you can use the "required package" feature of Monticello. Otherwise, you will have to use Metacello. > > >> >> Regarding how to verify the commit I did, I would expect that there >> would be a build machine. Since there seems to be no build machine, the >> process recommended in Pharo by Example is to download the code from >> Squeak Source into a clean image. Do I need to recreate the project in >> Monticello and then download the code? > > > Not sure I understand what you mean. There is an integration server for Moose. Now if your project is not part of Moose default, you have to check by yourself that it loads ok in a new image. > http://hudson.moosetechnology.org/ > > >> >> Cheers, >> Guillermo. >> >> On Mon, 2010-10-11 at 14:32 +0200, Simon Denier wrote: >>> Hi Guillermo >>> >>> I saw your commit and especially your comment >>> >>> "saving locally first, then remotelly, doesn't simply copy the changes like Mercurial does..." >>> >>> The way it works with Monticello, compared to Git/Mercurial (remember that Monticello was conceived before/in parallel with such systems...) >>> - the save command in MC always creates a new version of your package in the repository you selected >>> - saving a version on a remote repository also saves a local copy >>> - if you want to save a version first locally, then want to copy it later to another repository, use the "copy" command from the MC browser >>> >>> Alternatively, the Gofer API provides commands which are closes to Git/Mercurial workflows: push/fetch etc. >>> See http://www.lukas-renggli.ch/blog/gofer >>> >>> >>> BTW, is the fix complete? Your package only provides a new method FamixReference>>identityInstanceVariables >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simplex Veri Sigillum >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |