[Pharo-project] GitFs / MCGit
Hi Max, I took another effort to work on the git bindings of MC. However I ran into troubles with FSGitFilesystem on commiting. 1. I fail when saving the repos in GitCommit >> parents when it starts to lazily load the object which does not exist yet... 2. GitRespository >> packedObjectWithSignature: aGitObjectSignature does not throw an exception but simply returns nil? does this make sense? maybe you have a clue how to solve this faster than I do :-) camillo
Hi Camillo Which Filesystem version do you use? The reworked versions probably break FSGit. I'll have to take a quick look myself. I'll do that later. Cheers, Max On 27.04.2011, at 16:21, Camillo Bruni wrote:
Hi Max,
I took another effort to work on the git bindings of MC. However I ran into troubles with FSGitFilesystem on commiting.
1. I fail when saving the repos in GitCommit >> parents when it starts to lazily load the object which does not exist yet...
2. GitRespository >> packedObjectWithSignature: aGitObjectSignature does not throw an exception but simply returns nil? does this make sense?
maybe you have a clue how to solve this faster than I do :-)
camillo
Can you send me the stack traces? On 27.04.2011, at 16:21, Camillo Bruni wrote:
Hi Max,
I took another effort to work on the git bindings of MC. However I ran into troubles with FSGitFilesystem on commiting.
1. I fail when saving the repos in GitCommit >> parents when it starts to lazily load the object which does not exist yet...
2. GitRespository >> packedObjectWithSignature: aGitObjectSignature does not throw an exception but simply returns nil? does this make sense?
maybe you have a clue how to solve this faster than I do :-)
camillo
Concerning 2: No, it doesn't make sense at all to return nil. The reason that no exception is signalled is simply that that case should never be possible (not really an argument, I know :D). The method #packedObjectWithSignature is only sent if no loose object could be found. Then the packs are scanned and if the object isn't found in the packs the method returns nil. I think an exception would make a lot of sense but I didn't implement an exception handling mechanism for FSGit so a user will get slapped in the face with a debugger. Better though than having to track down that nil bug... On 27.04.2011, at 16:21, Camillo Bruni wrote:
Hi Max,
I took another effort to work on the git bindings of MC. However I ran into troubles with FSGitFilesystem on commiting.
1. I fail when saving the repos in GitCommit >> parents when it starts to lazily load the object which does not exist yet...
2. GitRespository >> packedObjectWithSignature: aGitObjectSignature does not throw an exception but simply returns nil? does this make sense?
maybe you have a clue how to solve this faster than I do :-)
camillo
Thanks for your help :) So Lukas Git Repository for Monticello works again. ByeBye sqeaksource for me... ;) On 2011-04-27, at 19:14, Max Leske wrote:
Concerning 2: No, it doesn't make sense at all to return nil. The reason that no exception is signalled is simply that that case should never be possible (not really an argument, I know :D). The method #packedObjectWithSignature is only sent if no loose object could be found. Then the packs are scanned and if the object isn't found in the packs the method returns nil.
I think an exception would make a lot of sense but I didn't implement an exception handling mechanism for FSGit so a user will get slapped in the face with a debugger. Better though than having to track down that nil bug...
On 27.04.2011, at 16:21, Camillo Bruni wrote:
Hi Max,
I took another effort to work on the git bindings of MC. However I ran into troubles with FSGitFilesystem on commiting.
1. I fail when saving the repos in GitCommit >> parents when it starts to lazily load the object which does not exist yet...
2. GitRespository >> packedObjectWithSignature: aGitObjectSignature does not throw an exception but simply returns nil? does this make sense?
maybe you have a clue how to solve this faster than I do :-)
camillo
Hi, I am not sure I understand the implication. Could you explain, please? :) Cheers, Doru On 27 Apr 2011, at 21:37, Camillo Bruni wrote:
Thanks for your help :)
So Lukas Git Repository for Monticello works again. ByeBye sqeaksource for me... ;)
On 2011-04-27, at 19:14, Max Leske wrote:
Concerning 2: No, it doesn't make sense at all to return nil. The reason that no exception is signalled is simply that that case should never be possible (not really an argument, I know :D). The method #packedObjectWithSignature is only sent if no loose object could be found. Then the packs are scanned and if the object isn't found in the packs the method returns nil.
I think an exception would make a lot of sense but I didn't implement an exception handling mechanism for FSGit so a user will get slapped in the face with a debugger. Better though than having to track down that nil bug...
On 27.04.2011, at 16:21, Camillo Bruni wrote:
Hi Max,
I took another effort to work on the git bindings of MC. However I ran into troubles with FSGitFilesystem on commiting.
1. I fail when saving the repos in GitCommit >> parents when it starts to lazily load the object which does not exist yet...
2. GitRespository >> packedObjectWithSignature: aGitObjectSignature does not throw an exception but simply returns nil? does this make sense?
maybe you have a clue how to solve this faster than I do :-)
camillo
-- www.tudorgirba.com "There are no old things, there are only old ways of looking at them."
Lukas once implemented a small MC Repository type that simple stores the source.st in a git repository. Due to changes in the recent pharo versions some of the git code didn't work anymore. So that's fixed now and you can use git for storing monticello versions. The following uses a local git repos as a monticello repository: MCGitRepository directory: 'test_git' Of course it is not fully useful since it uses a single file to store everything, rendering normal git tools unusable. Hence I will experiment tomorrow a bit on how to split up methods and classes into something more representable. I guess the trickiest part will be to tell git how methods and classes changed when they are renamed, but even that should not be such a problem.. In short, I will use github and share my code with the rest of the world ;). camillo On 2011-04-27, at 21:50, Tudor Girba wrote:
Hi,
I am not sure I understand the implication. Could you explain, please? :)
Cheers, Doru
On 27 Apr 2011, at 21:37, Camillo Bruni wrote:
Thanks for your help :)
So Lukas Git Repository for Monticello works again. ByeBye sqeaksource for me... ;)
On 2011-04-27, at 19:14, Max Leske wrote:
Concerning 2: No, it doesn't make sense at all to return nil. The reason that no exception is signalled is simply that that case should never be possible (not really an argument, I know :D). The method #packedObjectWithSignature is only sent if no loose object could be found. Then the packs are scanned and if the object isn't found in the packs the method returns nil.
I think an exception would make a lot of sense but I didn't implement an exception handling mechanism for FSGit so a user will get slapped in the face with a debugger. Better though than having to track down that nil bug...
On 27.04.2011, at 16:21, Camillo Bruni wrote:
Hi Max,
I took another effort to work on the git bindings of MC. However I ran into troubles with FSGitFilesystem on commiting.
1. I fail when saving the repos in GitCommit >> parents when it starts to lazily load the object which does not exist yet...
2. GitRespository >> packedObjectWithSignature: aGitObjectSignature does not throw an exception but simply returns nil? does this make sense?
maybe you have a clue how to solve this faster than I do :-)
camillo
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
Hi Camillo: On 27 Apr 2011, at 22:09, Camillo Bruni wrote:
Lukas once implemented a small MC Repository type that simple stores the source.st in a git repository. Due to changes in the recent pharo versions some of the git code didn't work anymore. So that's fixed now and you can use git for storing monticello versions.
The following uses a local git repos as a monticello repository:
MCGitRepository directory: 'test_git' What are the dependencies for that? Would it be likely that it works with a Squeak 3.8/3.9ish image?
Of course it is not fully useful since it uses a single file to store everything, rendering normal git tools unusable. Hence I will experiment tomorrow a bit on how to split up methods and classes into something more representable. I guess the trickiest part will be to tell git how methods and classes changed when they are renamed, but even that should not be such a problem.. If you can handle EPL licensed code, I could make our Transporter scripts available. It is a bit more than just a file out that uses one file per class, and a folder per package. Beyond that, we also have some support for ordering, since often we have dependencies that need to be load first, etc, as well as pre/post scripts.
Unfortunately, it is EPL licensed and not MIT. So, let me know whether that would be useful/acceptable for you. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
On 2011-04-27, at 22:37, Stefan Marr wrote:
Hi Camillo:
On 27 Apr 2011, at 22:09, Camillo Bruni wrote:
Lukas once implemented a small MC Repository type that simple stores the source.st in a git repository. Due to changes in the recent pharo versions some of the git code didn't work anymore. So that's fixed now and you can use git for storing monticello versions.
The following uses a local git repos as a monticello repository:
MCGitRepository directory: 'test_git' What are the dependencies for that? Would it be likely that it works with a Squeak 3.8/3.9ish image?
I have no clue. It was developed in a 1.2 image. But I guess you have to try out ;)
Of course it is not fully useful since it uses a single file to store everything, rendering normal git tools unusable. Hence I will experiment tomorrow a bit on how to split up methods and classes into something more representable. I guess the trickiest part will be to tell git how methods and classes changed when they are renamed, but even that should not be such a problem.. If you can handle EPL licensed code, I could make our Transporter scripts available. It is a bit more than just a file out that uses one file per class, and a folder per package. Beyond that, we also have some support for ordering, since often we have dependencies that need to be load first, etc, as well as pre/post scripts.
I'd certainly be interested in having a look at this. Since I am not yet sure how to split it up. Since I want to make it compatible with Monticello again I will try to keep enough meta data around to reassemble a sources.st file.
Unfortunately, it is EPL licensed and not MIT. So, let me know whether that would be useful/acceptable for you..
Personally this is no problem, and since I am not obliged to commit it to squeaksource this should be not a problem.
Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
Hi, On 27 Apr 2011, at 23:20, Camillo Bruni wrote:
On 2011-04-27, at 22:37, Stefan Marr wrote:
Hi Camillo:
On 27 Apr 2011, at 22:09, Camillo Bruni wrote:
Lukas once implemented a small MC Repository type that simple stores the source.st in a git repository. Due to changes in the recent pharo versions some of the git code didn't work anymore. So that's fixed now and you can use git for storing monticello versions.
The following uses a local git repos as a monticello repository:
MCGitRepository directory: 'test_git' What are the dependencies for that? Would it be likely that it works with a Squeak 3.8/3.9ish image?
I have no clue. It was developed in a 1.2 image. But I guess you have to try out ;)
Of course it is not fully useful since it uses a single file to store everything, rendering normal git tools unusable. Hence I will experiment tomorrow a bit on how to split up methods and classes into something more representable. I guess the trickiest part will be to tell git how methods and classes changed when they are renamed, but even that should not be such a problem.. If you can handle EPL licensed code, I could make our Transporter scripts available. It is a bit more than just a file out that uses one file per class, and a folder per package. Beyond that, we also have some support for ordering, since often we have dependencies that need to be load first, etc, as well as pre/post scripts.
I'd certainly be interested in having a look at this. Since I am not yet sure how to split it up. Since I want to make it compatible with Monticello again I will try to keep enough meta data around to reassemble a sources.st file.
Unfortunately, it is EPL licensed and not MIT. So, let me know whether that would be useful/acceptable for you..
Personally this is no problem, and since I am not obliged to commit it to squeaksource this should be not a problem.
Just a note: If this code is to have the possibility of being used in a Pharo-distribution, it would need to be MIT. Cheers, Doru
Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
-- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."
On Thu, Apr 28, 2011 at 3:37 AM, Stefan Marr <pharo@stefan-marr.de> wrote:
Hi Camillo:
On 27 Apr 2011, at 22:09, Camillo Bruni wrote:
Lukas once implemented a small MC Repository type that simple stores the source.st in a git repository. Due to changes in the recent pharo versions some of the git code didn't work anymore. So that's fixed now and you can use git for storing monticello versions.
The following uses a local git repos as a monticello repository:
   MCGitRepository directory: 'test_git'
Maybe you should document how do that. Some people might be interested in order to mitigate the problems related to SqueakSource unstabilities.
What are the dependencies for that? Would it be likely that it works with a Squeak 3.8/3.9ish image?
Of course it is not fully useful since it uses a single file to store everything, rendering normal git tools unusable. Hence I will experiment tomorrow a bit on how to split up methods and classes into something more representable. I guess the trickiest part will be to tell git how methods and classes changed when they are renamed, but even that should not be such a problem.. If you can handle EPL licensed code, I could make our Transporter scripts available. It is a bit more than just a file out that uses one file per class, and a folder per package. Beyond that, we also have some support for ordering, since often we have dependencies that need to be load first, etc, as well as pre/post scripts.
Unfortunately, it is EPL licensed and not MIT. So, let me know whether that would be useful/acceptable for you.
Eclipse Public Licence (EPL) is a bit strange for Smalltalk code :-) but there is no problem if the code is not integrated in Pharo. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/
On Wed, Apr 27, 2011 at 10:09 PM, Camillo Bruni <camillo.bruni@inria.fr>wrote:
Lukas once implemented a small MC Repository type that simple stores the source.st in a git repository.
And what it does with the rest of the files of the .mcz ? like the snapshot binary ?
Due to changes in the recent pharo versions some of the git code didn't work anymore. So that's fixed now and you can use git for storing monticello versions.
The following uses a local git repos as a monticello repository:
MCGitRepository directory: 'test_git'
Of course it is not fully useful since it uses a single file to store everything, rendering normal git tools unusable. Hence I will experiment tomorrow a bit on how to split up methods and classes into something more representable. I guess the trickiest part will be to tell git how methods and classes changed when they are renamed, but even that should not be such a problem..
In short, I will use github and share my code with the rest of the world ;).
camillo
On 2011-04-27, at 21:50, Tudor Girba wrote:
Hi,
I am not sure I understand the implication. Could you explain, please? :)
Cheers, Doru
On 27 Apr 2011, at 21:37, Camillo Bruni wrote:
Thanks for your help :)
So Lukas Git Repository for Monticello works again. ByeBye sqeaksource for me... ;)
On 2011-04-27, at 19:14, Max Leske wrote:
Concerning 2: No, it doesn't make sense at all to return nil. The reason that no exception is signalled is simply that that case should never be possible (not really an argument, I know :D). The method #packedObjectWithSignature is only sent if no loose object could be found. Then the packs are scanned and if the object isn't found in the packs the method returns nil.
I think an exception would make a lot of sense but I didn't implement an exception handling mechanism for FSGit so a user will get slapped in the face with a debugger. Better though than having to track down that nil bug...
On 27.04.2011, at 16:21, Camillo Bruni wrote:
Hi Max,
I took another effort to work on the git bindings of MC. However I ran into troubles with FSGitFilesystem on commiting.
1. I fail when saving the repos in GitCommit >> parents when it starts to lazily load the object which does not exist yet...
2. GitRespository >> packedObjectWithSignature: aGitObjectSignature does not throw an exception but simply returns nil? does this make sense?
maybe you have a clue how to solve this faster than I do :-)
camillo
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
-- Mariano http://marianopeck.wordpress.com
participants (6)
-
Camillo Bruni -
Mariano Martinez Peck -
Max Leske -
Serge Stinckwich -
Stefan Marr -
Tudor Girba