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
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Being happy is a matter of choice."
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Being happy is a matter of choice."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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" ;-)
loadLoad the specified packages.updateUpdate the specified packages.mergeMerge the specified packages into their working copies.localChangesAnswer the changes between the base version and the working copy.browseLocalChangesBrowse the changes between the base version and the working copy.remoteChangesAnswer the changes between the working copy and the remote changes. browseRemoteChangesBrowse the changes between the working copy and the remote changes.cleanupCleans the specified packages.commitCommit the modified specified packages.commit:Commit the modified specified packages with the given commit message.revertRevert the specified packages to the currently loaded version.recompileRecompile the specified packages. reinitializeCall the class side initializers on the specified packages. unloadUnload the specified packages.fetchDownload versions from remote repositories into the local cache.pushUpload 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 Simon.Denier@inria.fr 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
Guillermo Schwarz -
Simon Denier -
Tudor Girba