GitFs / MCGit

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

GitFs / MCGit

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

Re: GitFs / MCGit

Max Leske
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


Reply | Threaded
Open this post in threaded view
|

Re: GitFs / MCGit

Max Leske
In reply to this post by Camillo Bruni
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


Reply | Threaded
Open this post in threaded view
|

Re: GitFs / MCGit

Max Leske
In reply to this post by Camillo Bruni
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


Reply | Threaded
Open this post in threaded view
|

Re: GitFs / MCGit

Camillo Bruni
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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: GitFs / MCGit

Tudor Girba
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."




Reply | Threaded
Open this post in threaded view
|

Re: GitFs / MCGit

Camillo Bruni
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."
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: GitFs / MCGit

Stefan Marr-4
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


Reply | Threaded
Open this post in threaded view
|

Re: GitFs / MCGit

Camillo Bruni

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


Reply | Threaded
Open this post in threaded view
|

Re: GitFs / MCGit

Tudor Girba
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."







Reply | Threaded
Open this post in threaded view
|

Re: GitFs / MCGit

SergeStinckwich
In reply to this post by Stefan Marr-4
On Thu, Apr 28, 2011 at 3:37 AM, Stefan Marr <[hidden email]> 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/

Reply | Threaded
Open this post in threaded view
|

Re: GitFs / MCGit

Mariano Martinez Peck
In reply to this post by Camillo Bruni


On Wed, Apr 27, 2011 at 10:09 PM, Camillo Bruni <[hidden email]> 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