11 Oct
2010
11 Oct
'10
2:32 p.m.
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
11 Oct
11 Oct
3:21 p.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
11:28 p.m.
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:
--
www.tudorgirba.com
"Being happy is a matter of choice."
FAMIXUnknownVariable
--
Simplex Veri Sigillum
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
12 Oct
12 Oct
6:55 a.m.
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:
--
Simplex Veri Sigillum
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:
--
www.tudorgirba.com
"Being happy is a matter of choice."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev FAMIXUnknownVariable
--
Simplex Veri Sigillum
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
3:05 p.m.
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
11 Oct
11 Oct
6:43 p.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simplex Veri Sigillum
12 Oct
12 Oct
3:26 p.m.
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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Saludos cordiales,
Guillermo Schwarz
Sun Certified Enterprise Architect
4939
days inactive
4940
days old
7 comments
4 participants
participants (4)
-
Alexandre Bergel -
Guillermo Schwarz -
Simon Denier -
Tudor Girba