About Famix-Core-GuillermoSchwarz.123

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

About Famix-Core-GuillermoSchwarz.123

Simon Denier-3
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
Reply | Threaded
Open this post in threaded view
|

Re: About Famix-Core-GuillermoSchwarz.123

Alexandre Bergel
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
Reply | Threaded
Open this post in threaded view
|

Re: About Famix-Core-GuillermoSchwarz.123

Simon Denier-3
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
Reply | Threaded
Open this post in threaded view
|

Re: About Famix-Core-GuillermoSchwarz.123

Alexandre Bergel
> 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
Reply | Threaded
Open this post in threaded view
|

Re: About Famix-Core-GuillermoSchwarz.123

Guillermo Schwarz
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
Reply | Threaded
Open this post in threaded view
|

Re: About Famix-Core-GuillermoSchwarz.123

Guillermo Schwarz
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
Reply | Threaded
Open this post in threaded view
|

Re: About Famix-Core-GuillermoSchwarz.123

Tudor Girba
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
Reply | Threaded
Open this post in threaded view
|

Re: About Famix-Core-GuillermoSchwarz.123

Guillermo Schwarz
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
Reply | Threaded
Open this post in threaded view
|

Re: About Famix-Core-GuillermoSchwarz.123

Alexandre Bergel
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
Reply | Threaded
Open this post in threaded view
|

Re: About Famix-Core-GuillermoSchwarz.123

Guillermo Schwarz
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" ;-)

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
Reply | Threaded
Open this post in threaded view
|

Re: About Famix-Core-GuillermoSchwarz.123

Simon Denier-3
In reply to this post by Simon Denier-3

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
Reply | Threaded
Open this post in threaded view
|

Re: About Famix-Core-GuillermoSchwarz.123

anquetil.nicolas
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:

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
Reply | Threaded
Open this post in threaded view
|

Re: About Famix-Core-GuillermoSchwarz.123

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: About Famix-Core-GuillermoSchwarz.123

Simon Denier-3
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:

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?

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.



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
Reply | Threaded
Open this post in threaded view
|

Re: About Famix-Core-GuillermoSchwarz.123

Alexandre Bergel
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