Conversion to UnifiedFFI ?

[jvdsandt]

Hello,

At the PharoDays 2016 conference I learned that the new UnifiedFFI code of Pharo 5 is feature complete and pretty stable.

Are there already any plans to convert LibGit to Pharo 5? Can I help with the effort?

Jan.

[estebanlm]

of course you can help!

I started to work on it: https://github.com/estebanlm/LibGit/tree/pharo50 :) but I still do not have much to show :(

there is the problem with the call: mechanism libgit2 is implementing now (which in fact does not work fine even in NB :P)

Esteban

On 31 Mar 2016, at 14:56, jvdsandt notifications@github.com wrote:

Hello,

At the PharoDays 2016 conference I learned that the new UnifiedFFI code of Pharo 5 is feature complete and pretty stable.

Are there already any plans to convert LibGit to Pharo 5? Can I help with the effort?

Jan.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/theseion/LibGit/issues/41

[theseion]

Yeah, I screwed that up... If you feel up to the challenge, you're welcome to start hacking!

[jvdsandt]

Ok, if I understand it correctly the call functionality of TLGitCalloutTrait offers some extra safe guards before performing the real ffi call. But this does not really work in practice because the bytecodes of the CompiledMethod with the ffi call are replaced by something else. Correct?

I think the safe guards provided are:

• Making sure that the lingit2_init and libgit2_shutdown functions are called (using the process variable LGitActionSequence)
• checking the return value for errors using LGitReturnCodeEnum
• making sure that the handles used are not null

If there is no way to implement these safe guards in the ffi call method itself we could implement them in the method calling the ffi method.

For example, change:

LGitTree>>#size
    ^ self tree_entrycount: self

into:

LGitTree>>#size
    ^ self ffiCheck: [ self tree_entrycount: self ]

What do you think?

[theseion]

Ok, if I understand it correctly the call functionality of TLGitCalloutTrait offers some extra safe guards before performing the real ffi call. But this does not really work in practice because the bytecodes of the CompiledMethod with the ffi call are replaced by something else. Correct?

Yes, exactly.

I think the safe guards provided are:

Making sure that the lingit2_init and libgit2_shutdown functions are called (using the process variable LGitActionSequence)

yes

checking the return value for errors using LGitReturnCodeEnum

this should work (doesn't rely on dynamic behaviour, i.e. can be compiled to bytecode).

making sure that the handles used are not null

this should work (doesn't rely on dynamic behaviour, i.e. can be compiled to bytecode).

If there is no way to implement these safe guards in the ffi call method itself we could implement them in the method calling the ffi method.

For example, change:

LGitTree>>#size ^ self tree_entrycount: self into:

LGitTree>>#size ^ self ffiCheck: [ self tree_entrycount: self ] What do you think?

Yes, we could do that. I have been trying to avoid that because it makes the API more complicated to extend and it introduces implicit conventions for writing binding methods. Also, imagine we'd need to change something in the way we check the calls. It could become a lot of work to perform that change since the libgit2 API is so large.

I'd rather have something like customisable pre and post call hooks, which then work with compilation. Then we could simply change the hook implementation, flush the FFI byte code and we'd be done with a change to all calls.

[jvdsandt]

Yes, that would be a cleaner solution. Perhaps write a custom subclass of FFICalloutMethodBuilder in Pharo 5 that contains the custom pre and post call hooks?

I did a small test in Pharo 5 using this simple libgit2 call:

libgit2_features
    "Query compile time options for libgit2."
    ^self ffiCall: #(int git_libgit2_features())

Using the FFICalloutMethodBuilder class this method gets translated into this:

libgit2_featuresAlt
    "Query compile time options for libgit2."
    | fnc |
    fnc := ExternalLibraryFunction
        name: 'git_libgit2_features'
        module: 'libgit2.0.dylib'
        callType: 0
        returnType: FFIInt32 new externalTypeWithArity
        argumentTypes: {}.
    ^fnc invokeWithArguments: { }

With a custom FFICalloutMethodBuilder we can change the generated method to preform pre- and post checks.

[theseion]

On 05 Apr 2016, at 22:38, jvdsandt notifications@github.com wrote:

Yes, that would be a cleaner solution. Perhaps write a custom subclass of FFICalloutMethodBuilder in Pharo 5 that contains the custom pre and post call hooks?

I did a small test in Pharo 5 using this simple libgit2 call:

libgit2_features "Query compile time options for libgit2." ^self ffiCall: #(int git_libgit2_features()) Using the FFICalloutMethodBuilder class this method gets translated into this:

libgit2_featuresAlt "Query compile time options for libgit2." | fnc | fnc := ExternalLibraryFunction name: 'git_libgit2_features' module: 'libgit2.0.dylib' callType: 0 returnType: FFIInt32 new externalTypeWithArity argumentTypes: {}. ^fnc invokeWithArguments: { } With a custom FFICalloutMethodBuilder we can change the generated method to preform pre- and post checks.

That sounds pretty much perfect! I haven’t had a chance to get familiar with UFFI yet, so I’m relying on your judgement. If you’re game, you could hack on this a bit in a separate branch.

One thing we need to make sure first is that we can use this mechanism to check a global variable and then wrap the call with an init call to libgit2 (what I intended to do with LGitActionSequence), because obviously we don’t want to perform init and shutdown before and after every FFI call.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/theseion/LibGit/issues/41#issuecomment-205978078

[jvdsandt]

Two weeks ago I started on the port of LibGit to Pharo 5. I converted all the structs, callbacks and other external objects to the new UFFI classes. A lot of tests are already green but now I'm facing some technical issue with callbacks:

• the callback arguments are not converted to the corrent Smalltalk externalobject class but are instances of ExternalAddress
• calls which take callbacks as arguments return invalid instances of LGitReturnCodeEnum

Esteban, can you help me with these issues? Maybe it's a bug in the UFFI callback functionality that is the cause.

If you load my pharo50 branch (https://github.com/jvdsandt/LibGit/tree/pharo50) and run the test LGitTreeTest>>#testAllEntriesDo you can see the problem. This test uses LGitTreewalkCallback

[jvdsandt]

In my pharo50 branch I now have most things working in Pharo 5.0. All the tests are green except for the LGitPackTest. I haven't figured yet how this should work. It was quite some work, the libgit2 library is pretty big and there were a lot of small differences between NB and UFFI. And also some UFFI issues and bugs.

I created a custom FFICalloutAPI subclass LGitSafeFFICalloutAPI. This class is used to implement checked/safe ffi calls. Before the actual ffi call the method #signalIfNotReady is called.

Are you interested in merging this work? If so how should I proceed? I'm still pretty inexperienced with git and open source development.

[theseion]

On 01 May 2016, at 21:38, jvdsandt notifications@github.com wrote:

In my pharo50 branch I now have most things working in Pharo 5.0.

That’s awesome! Thanks a lot!

All the tests are green except for the LGitPackTest. I haven't figured yet how this should work.

I included pack creation for some experiments that Martin Dias was doing. So there are no public methods yet for doing this nicely.

packHead is just a method test. The important one #testPackCreation. To create a pack, the loose objects need to first be sorted and then traversed in that order. Every object ist then added to the pack builder. LGitOdbWritepack knows how to write the generic presentation of a package, provided by the pack builder, to the object database (odb). The reason for this separation is that libgit2 supports arbitrary backends.

There are one or two ugly hacks in there, so don’t worry too much about it. I don’t care too much if those tests fail for now.

It was quite some work, the libgit2 library is pretty big and there were a lot of small differences between NB and UFFI. And also some UFFI issues and bugs.

I created a custom FFICalloutAPI subclass LGitSafeFFICalloutAPI. This class is used to implement checked/safe ffi calls. Before the actual ffi call the method #signalIfNotReady is called.

I’m looking forward to seeing how this works.

Are you interested in merging this work?

Yes, very much :)

Do you need LibGit for something right away? I should be working on my thesis every free minute I get until June. I’d therefore rather postpone the merge until I can really take my time and look through all of your changes. But if it’s urgent I’m sure I can make time some how.

If so how should I proceed? I'm still pretty inexperienced with git and open source development.

You should open a pull request from your pharo50 branch to master. You can then even make more changes if you want, the pull request will be updated automatically to include new changes.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/theseion/LibGit/issues/41#issuecomment-216067037

[tinchodias]

Hi, If you want, I can test your changes. Just you tell me how to install them. I have an experimental p roject that makes intensive use of git operations, with many commits with many objects each. It can be a good test.

[jvdsandt]

Ok, I will open a pull request. There is no hurry for me. The API of LibGit hasn't changed and I can continue working using my branch for now.

Good luck with your thesis!

[jvdsandt]

Hi tinchodias,

It would be great if you could have a look at my changes. You can load the code from https://github.com/jvdsandt/LibGit/tree/pharo50 The BaselineOfLibGit should load the correct packages.

Note that I only worked with the packages LibGit-Core and LibGit-Tests. I don;t know if the other packages work in Pharo 5.0

[theseion]

Thanks Martin!

On 02 May 2016, at 10:28, jvdsandt notifications@github.com wrote:

Hi tinchodias,

It would be great if you could have a look at my changes. You can load the code from https://github.com/jvdsandt/LibGit/tree/pharo50 https://github.com/jvdsandt/LibGit/tree/pharo50 The BaselineOfLibGit should load the correct packages.

Note that I only worked with the packages LibGit-Core and LibGit-Tests. I don;t know if the other packages work in Pharo 5.0

Ignore the other packages. They’re mostly experimental.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/theseion/LibGit/issues/41#issuecomment-216138639

[tinchodias]

Hi! a first error :) on installation. Sorry, I may ask silly/lazy questions, but I prefer to ask first. My steps:

1) curl get.pharo.org/50+vm | bash 2) evaluate:

Metacello new baseline: #LibGit; repository: 'github://jvdsandt/LibGit:pharo50'; load.

3) get:

MessageNotUnderstood: LGitExternalCommitArray class>>initElementType: LGitExternalCommitArray class(Object)>>doesNotUnderstand: #initElementType: LGitExternalCommitArray class>>initialize

did I do something wrong? I adapted the snippet from the official page

[jvdsandt]

Hi Martin,

No, you did nothing wrong, that should work. I just tried your load script in a clean Pharo 5 image and the load worked for me. It seems that in your case the wrong version is loaded. The class LGitExternalCommitArray doesn't have an initialize class method in my pharo50 branch. What does you transcript show?

[tinchodias]

Hi @jvdsandt,

This time it worked! weird.

I get this DNU on this method of my project:

MessageNotUnderstood: LGitRemote>>registerAsExternalResource
LGitRemote(Object)>>doesNotUnderstand: #registerAsExternalResource
LGitRemote(LGitExternalObject)>>initialize
LGitRemote class(LGitRepositoryObject class)>>of:

This is my code, that creates the LGitRemote:

repository := (LGitRepository on: 'pharo-core' asFileReference) open; yourself.

LGitGlobal runSequence: [ 
    (LGitRemote of: repository named: 'origin') lookup pull ].

Remarks: The DNU happens in the remote's initialization. However, the selector #pull has no implementors. Do you know what happened to it? there is a remote's #pullWithFetchOptions: last-modified by Max. Maybe @theseion renamed it before your migration to UFFI.

Also: I can't remember why I ended using LGitGlobal runSequence: there. I guess that should be done in side pull. Now this mechanism is deprecated, isn't it?

In the case you want to reproduce my error, I think it will work with any repository already cloned as 'pharo-core'. But, in my directory I just did this in comamnd-line:

git clone git@github.com:pharo-project/pharo-core.git

[theseion]

On 05 May 2016, at 06:29, Martín Dias notifications@github.com wrote:

Hi @jvdsandt https://github.com/jvdsandt,

This time it worked! weird.

I get this DNU on this method of my project:

MessageNotUnderstood: LGitRemote>>registerAsExternalResource LGitRemote(Object)>>doesNotUnderstand: #registerAsExternalResource LGitRemote(LGitExternalObject)>>initialize LGitRemote class(LGitRepositoryObject class)>>of: This is my code, that creates the LGitRemote:

repository := (LGitRepository on: 'pharo-core' asFileReference) open; yourself.

LGitGlobal runSequence: [ (LGitRemote of: repository named: 'origin') lookup pull ]. Remarks: The DNU happens in the remote's initialization. However, the selector #pull has no implementors. Do you know what happened to it? there is a remote's #pullWithFetchOptions: last-modified by Max. Maybe @theseion https://github.com/theseion renamed it before your migration to UFFI.

I don’t think I did...

Also: I can't remember why I ended using LGitGlobal runSequence: there. I guess that should be done in side pull. Now this mechanism is deprecated, isn't it?

In the case you want to reproduce my error, I think it will work with any repository already cloned as 'pharo-core'. But, in my directory I just did this in comamnd-line:

git clone git@github.com:pharo-project/pharo-core.git — You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/theseion/LibGit/issues/41#issuecomment-217074592

[jvdsandt]

On Thu, May 5, 2016 at 6:29 AM, Martín Dias notifications@github.com wrote:

Hi @jvdsandt https://github.com/jvdsandt,

This time it worked! weird.

I get this DNU on this method of my project:

MessageNotUnderstood: LGitRemote>>registerAsExternalResource LGitRemote(Object)>>doesNotUnderstand: #registerAsExternalResource LGitRemote(LGitExternalObject)>>initialize LGitRemote class(LGitRepositoryObject class)>>of:

This is still weird! In my branch this method does not exist: LGitRemote(LGitExternalObject)>>initialize Can you check that you have the right version of these packages loaded:

Name: LibGit-Core-JanvandeSandt.115 Author: JanvandeSandt Time: 1 May 2016, 9:21:24 pm UUID: 2a7196f4-6a53-5041-8c02-48ff2a0d5097 Ancestors: LibGit-Core-JanvandeSandt.114

Name: LibGit-Tests-JanvandeSandt.66 Author: JanvandeSandt Time: 1 May 2016, 9:23:39 pm UUID: 07075cde-be73-5be6-a7b0-a00c6e96b0d7 Ancestors: LibGit-Tests-JanvandeSandt.65

This is my code, that creates the LGitRemote:

repository := (LGitRepository on: 'pharo-core' asFileReference) open; yourself.

LGitGlobal runSequence: [ (LGitRemote of: repository named: 'origin') lookup pull ].

Remarks: The DNU happens in the remote's initialization. However, the selector #pull has no implementors. Do you know what happened to it? there is a remote's #pullWithFetchOptions: last-modified by Max. Maybe @theseion https://github.com/theseion renamed it before your migration to UFFI.

I haven't seen a #pull method. When I search the repository of Max I find a single implementation in the package LibGit-Patches [1]

Also: I can't remember why I ended using LGitGlobal runSequence: there. I guess that should be done in side pull. Now this mechanism is deprecated, isn't it?

Putting your LibGit code inside a runSequence block is not strictly necessary anymore. The only thing it does is check that the library has been initialised. I put this check also in LGitRepositoty class>>#on. When you start using the library this is normally the first method you come across. Another option would be to perform the check inside TLGitCalloutTrait>>#signalNotReady

In the case you want to reproduce my error, I think it will work with any repository already cloned as 'pharo-core'. But, in my directory I just did this in comamnd-line:

git clone git@github.com:pharo-project/pharo-core.git

Jan.

[1] https://github.com/theseion/LibGit/blob/master/LibGit-Patches.package/MCGitRepository.class/instance/pull.st

[tinchodias]

I'm sorry * 2.

1. I made a mistake updating the Configurations of my projects.
2. Yes, I was using LibGit-Patches package... I should had loaded LibGit's development group.

With this fixed, I just get the #pull's DNU... that has to be some hack that I've lost, but no problem, I'm fixing it, and tell you if I have news.

Now, probably off-topic... a strange fact I noticed looking at my loaded packages.

Name: LibGit-Core-JanVanDeSandt.115 Author: JanVanDeSandt Time: 1 May 2016, 9:21:07.854528 pm UUID: bb8d12ca-3ed4-42f9-bdd7-e6b6608951f6 Ancestors: LibGit-Core-JanvandeSandt.114

Name: LibGit-Tests-JanVanDeSandt.66 Author: JanVanDeSandt Time: 1 May 2016, 9:23:24.975804 pm UUID: 07c8600a-a78c-4bfc-b4be-44f8101b57c5 Ancestors: LibGit-Tests-JanvandeSandt.65

---> They have different UUIDs and slightly different timestamps. For example, 9:21:07.854528 pm instead of 9:21:24 pm.

How did you get that Monticello info? this was my way, World Menu -> Monticello Browser -> Select github//jvdsandt/LibGit.pharo50 repo in right list -> Open -> Select LibGit-Core in left and right lists.

May be a bug from Pharo...?

BTW, I'm on linux (XUbuntu 15.04).

Martin

On Thu, May 5, 2016 at 8:49 AM, jvdsandt notifications@github.com wrote:

On Thu, May 5, 2016 at 6:29 AM, Martín Dias notifications@github.com wrote:

Hi @jvdsandt https://github.com/jvdsandt,

This time it worked! weird.

I get this DNU on this method of my project:

MessageNotUnderstood: LGitRemote>>registerAsExternalResource LGitRemote(Object)>>doesNotUnderstand: #registerAsExternalResource LGitRemote(LGitExternalObject)>>initialize LGitRemote class(LGitRepositoryObject class)>>of:

This is still weird! In my branch this method does not exist: LGitRemote(LGitExternalObject)>>initialize Can you check that you have the right version of these packages loaded:

Name: LibGit-Core-JanvandeSandt.115 Author: JanvandeSandt Time: 1 May 2016, 9:21:24 pm UUID: 2a7196f4-6a53-5041-8c02-48ff2a0d5097 Ancestors: LibGit-Core-JanvandeSandt.114

Name: LibGit-Tests-JanvandeSandt.66 Author: JanvandeSandt Time: 1 May 2016, 9:23:39 pm UUID: 07075cde-be73-5be6-a7b0-a00c6e96b0d7 Ancestors: LibGit-Tests-JanvandeSandt.65

This is my code, that creates the LGitRemote:

repository := (LGitRepository on: 'pharo-core' asFileReference) open; yourself.

LGitGlobal runSequence: [ (LGitRemote of: repository named: 'origin') lookup pull ].

Remarks: The DNU happens in the remote's initialization. However, the selector #pull has no implementors. Do you know what happened to it? there is a remote's #pullWithFetchOptions: last-modified by Max. Maybe @theseion https://github.com/theseion renamed it before your migration to UFFI.

I haven't seen a #pull method. When I search the repository of Max I find a single implementation in the package LibGit-Patches [1]

Also: I can't remember why I ended using LGitGlobal runSequence: there. I guess that should be done in side pull. Now this mechanism is deprecated, isn't it?

Putting your LibGit code inside a runSequence block is not strictly necessary anymore. The only thing it does is check that the library has been initialised. I put this check also in LGitRepositoty class>>#on. When you start using the library this is normally the first method you come across. Another option would be to perform the check inside TLGitCalloutTrait>>#signalNotReady

In the case you want to reproduce my error, I think it will work with any repository already cloned as 'pharo-core'. But, in my directory I just did this in comamnd-line:

git clone git@github.com:pharo-project/pharo-core.git

Jan.

[1]

https://github.com/theseion/LibGit/blob/master/LibGit-Patches.package/MCGitRepository.class/instance/pull.st

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/theseion/LibGit/issues/41#issuecomment-217134881

[tinchodias]

This is getting better, now I have a git error when executing a snippet. It is inspired in MCGitHubRepository >> projectDirectoryFrom:version:. What I'm not sure is if I made some mistake when I created my test_data.json data. Do you use it? I have a template at hand so I paste it below. It's a file in the same directory as the pharo image with this contents:

{
        "credentials" : {
                "keyFilePrivatePath" : "/home/<username>/.ssh/github",
                "keyFilePublicPath" : "/home/<username>/.ssh/github.pub",
                "keyPassPhrase" : “<ssh key password>",
                "password" : “<github account password>",
                "username" : “<github username>",
                "usernameSsh" : "<username>" },
        "urls" : {
                "repositoryUrlHttps" : "https://github.com/tinchodias/filesystem-git-test-repository.git",
                "repositoryUrlLocal" : "file:///home/<username>/dev/git/stuff",
                "repositoryUrlSsh" : "git@github.com:tinchodias/filesystem-git-test-repository.git" }
}

I don't know if I have made some mistake in some parameter, but I suspect there is some error in the bindings because I always get the same error.

Snippet and steps to reproduce:

1. Load

    Metacello new
        baseline: #LibGit;
        repository: 'github://jvdsandt/LibGit:pharo50';
        load: #development.

1. Load credential data from test_data.json

   LGitTestRepository loadTestData.

2. Evaluate

    | pharoGitRepoPath repository |
    pharoGitRepoPath := 'pharo-core' asFileReference.

    LGitGlobal runSequence: [
        repository := LGitRepository on: pharoGitRepoPath.
        (pharoGitRepoPath exists and: [ repository isProperRepository ])
            ifFalse: [ 
                repository
                    cloneHttps: 'https://github.com/pharo-project/pharo-core.git';
                    checkout: 'master' ]
            ifTrue: [ 
                | credentials credentialsCallback |
                repository open.
                credentials := LGitRemote credentialsSsh.
                credentialsCallback := LGitCredAcquireCallback
                    on: [ :cred :url :username_from_url :allowed_types :data | 
                        credentials createWith: cred.
                        0 ].
                (LGitRemote of: repository named: 'origin')
                    lookup;
                    pullWithFetchOptions: (LGitFetchOptions defaults
                        callbacks: (LGitRemoteCallbacks defaults
                            credentials: credentialsCallback;
                            yourself);
                        yourself).
                repository fastForward ] ].

1. Get error ("a LGitReturnCodeEnum(#git_error [-1])")

    LGit_GIT_ERROR: no error message set by libgit2
    LGitReturnCodeEnum>>handleLGitReturnCode
    LGitRemote(LGitExternalObject)>>withReturnHandlerDo:
    LGitRemote>>pullWithFetchOptions:

and

LGitError lastMessage 
 "'no error message set by libgit2'"

[theseion]

There is a bug in libssh2 on Linux (https://github.com/libgit2/libgit2/issues/3382) which may prevent SSH from working. Can you try this on OS X?

Another thing I noticed: you’re cloning via https but provide SSH credentials instead of https credentials (although that should raise an authentication error, not -1).

On 06 May 2016, at 01:07, Martín Dias notifications@github.com wrote:

This is getting better, now I have a git error when executing a snippet. It is inspired in MCGitHubRepository >> projectDirectoryFrom:version:. What I'm not sure is if I made some mistake when I created my test_data.json data. Do you use it? I have a template at hand so I paste it below. It's a file in the same directory as the pharo image with this contents:

{ "credentials" : { "keyFilePrivatePath" : "/home//.ssh/github", "keyFilePublicPath" : "/home//.ssh/github.pub", "keyPassPhrase" : “", "password" : “", "username" : “", "usernameSsh" : "" }, "urls" : { "repositoryUrlHttps" : "https://github.com/tinchodias/filesystem-git-test-repository.git", "repositoryUrlLocal" : "file:///home//dev/git/stuff", "repositoryUrlSsh" : "git@github.com:tinchodias/filesystem-git-test-repository.git" } } I don't know if I have made some mistake in some parameter, but I suspect there is some error in the bindings because I always get the same error.

Snippet and steps to reproduce:

Load Metacello new baseline: #LibGit; repository: 'github://jvdsandt/LibGit:pharo50'; load: #development. Load credential data from test_data.json

LGitTestRepository loadTestData.

Evaluate

| pharoGitRepoPath repository |
pharoGitRepoPath := 'pharo-core' asFileReference.

LGitGlobal runSequence: [
    repository := LGitRepository on: pharoGitRepoPath.
    (pharoGitRepoPath exists and: [ repository isProperRepository ])
        ifFalse: [ 
            repository
                cloneHttps: 'https://github.com/pharo-project/pharo-core.git';
                checkout: 'master' ]
        ifTrue: [ 
            | credentials credentialsCallback |
            repository open.
            credentials := LGitRemote credentialsSsh.
            credentialsCallback := LGitCredAcquireCallback
                on: [ :cred :url :username_from_url :allowed_types :data | 
                    credentials createWith: cred.
                    0 ].
            (LGitRemote of: repository named: 'origin')
                lookup;
                pullWithFetchOptions: (LGitFetchOptions defaults
                    callbacks: (LGitRemoteCallbacks defaults
                        credentials: credentialsCallback;
                        yourself);
                    yourself).
            repository fastForward ] ].

Get error ("a LGitReturnCodeEnum(#git_error [-1])") LGit_GIT_ERROR: no error message set by libgit2 LGitReturnCodeEnum>>handleLGitReturnCode LGitRemote(LGitExternalObject)>>withReturnHandlerDo: LGitRemote>>pullWithFetchOptions: and

LGitError lastMessage "'no error message set by libgit2'" — You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/theseion/LibGit/issues/41#issuecomment-217305483

[jvdsandt]

Hi Martin,

In the coming week I have time to look at these issues. During the port I didn't focus on the LGitManual tests so there is probably still some work to do there.

Jan.

On Fri, May 6, 2016 at 1:07 AM, Martín Dias notifications@github.com wrote:

This is getting better, now I have a git error when executing a snippet. It is inspired in MCGitHubRepository >> projectDirectoryFrom:version:. What I'm not sure is if I made some mistake when I created my test_data.json data. Do you use it? I have a template at hand so I paste it below. It's a file in the same directory as the pharo image with this contents:

{ "credentials" : { "keyFilePrivatePath" : "/home//.ssh/github", "keyFilePublicPath" : "/home//.ssh/github.pub", "keyPassPhrase" : “", "password" : “", "username" : “", "usernameSsh" : "" }, "urls" : { "repositoryUrlHttps" : "https://github.com/tinchodias/filesystem-git-test-repository.git", "repositoryUrlLocal" : "file:///home//dev/git/stuff", "repositoryUrlSsh" : "git@github.com:tinchodias/filesystem-git-test-repository.git" } }

I don't know if I have made some mistake in some parameter, but I suspect there is some error in the bindings because I always get the same error.

Snippet and steps to reproduce:

1. Load

   Metacello new baseline: #LibGit; repository: 'github://jvdsandt/LibGit:pharo50'; load: #development.

   1.

   Load credential data from test_data.json

   LGitTestRepository loadTestData. 2.

   Evaluate

   | pharoGitRepoPath repository | pharoGitRepoPath := 'pharo-core' asFileReference.

   LGitGlobal runSequence: [ repository := LGitRepository on: pharoGitRepoPath. (pharoGitRepoPath exists and: [ repository isProperRepository ]) ifFalse: [ repository cloneHttps: 'https://github.com/pharo-project/pharo-core.git'; checkout: 'master' ] ifTrue: [ | credentials credentialsCallback | repository open. credentials := LGitRemote credentialsSsh. credentialsCallback := LGitCredAcquireCallback on: [ :cred :url :username_from_url :allowed_types :data | credentials createWith: cred. 0 ]. (LGitRemote of: repository named: 'origin') lookup; pullWithFetchOptions: (LGitFetchOptions defaults callbacks: (LGitRemoteCallbacks defaults credentials: credentialsCallback; yourself); yourself). repository fastForward ] ].

2. Get error ("a LGitReturnCodeEnum(#git_error [-1])")

   LGit_GIT_ERROR: no error message set by libgit2 LGitReturnCodeEnum>>handleLGitReturnCode LGitRemote(LGitExternalObject)>>withReturnHandlerDo: LGitRemote>>pullWithFetchOptions:

and

LGitError lastMessage "'no error message set by libgit2'"

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/theseion/LibGit/issues/41#issuecomment-217305483

[jvdsandt]

Hi,

On Fri, May 6, 2016 at 1:07 AM, Martín Dias notifications@github.com wrote:

This is getting better, now I have a git error when executing a snippet. It is inspired in MCGitHubRepository >> projectDirectoryFrom:version:. What I'm not sure is if I made some mistake when I created my test_data.json data. Do you use it? I have a template at hand so I paste it below. It's a file in the same directory as the pharo image with this contents:

{ "credentials" : { "keyFilePrivatePath" : "/home//.ssh/github", "keyFilePublicPath" : "/home//.ssh/github.pub", "keyPassPhrase" : “", "password" : “", "username" : “", "usernameSsh" : "" }, "urls" : { "repositoryUrlHttps" : "https://github.com/tinchodias/filesystem-git-test-repository.git", "repositoryUrlLocal" : "file:///home//dev/git/stuff", "repositoryUrlSsh" : "git@github.com:tinchodias/filesystem-git-test-repository.git" } }

I don't know if I have made some mistake in some parameter, but I suspect there is some error in the bindings because I always get the same error.

Snippet and steps to reproduce:

1. Load

   Metacello new baseline: #LibGit; repository: 'github://jvdsandt/LibGit:pharo50'; load: #development.

   1.

   Load credential data from test_data.json

   LGitTestRepository loadTestData. 2.

   Evaluate

   | pharoGitRepoPath repository | pharoGitRepoPath := 'pharo-core' asFileReference.

   LGitGlobal runSequence: [ repository := LGitRepository on: pharoGitRepoPath. (pharoGitRepoPath exists and: [ repository isProperRepository ]) ifFalse: [ repository cloneHttps: 'https://github.com/pharo-project/pharo-core.git'; checkout: 'master' ] ifTrue: [ | credentials credentialsCallback | repository open. credentials := LGitRemote credentialsSsh. credentialsCallback := LGitCredAcquireCallback on: [ :cred :url :username_from_url :allowed_types :data | credentials createWith: cred. 0 ]. (LGitRemote of: repository named: 'origin') lookup; pullWithFetchOptions: (LGitFetchOptions defaults callbacks: (LGitRemoteCallbacks defaults credentials: credentialsCallback; yourself); yourself). repository fastForward ] ].

2. Get error ("a LGitReturnCodeEnum(#git_error [-1])")

   LGit_GIT_ERROR: no error message set by libgit2 LGitReturnCodeEnum>>handleLGitReturnCode LGitRemote(LGitExternalObject)>>withReturnHandlerDo: LGitRemote>>pullWithFetchOptions:

and

LGitError lastMessage "'no error message set by libgit2'"

Yes, I can reproduce this problem on my linux machine (Ubuntu 14.04). When I try the manual test cases I notice that the tests that use https work and most ssh based tests fail. They fail with the 'no error message set by libgit2' message. As Max said, I don't think this is related to the Pharo5 port.

When I run the manual tests on OS X I get different errors and the tests that use https also fail :-( Tests that use the network fail with LGit_GIT_ERROR: Failed to connect to github.com: Interrupted system call. I think this error is related to some kind of issue with UFFI or with the VM. I will ask about this on the Pharo mailing list.

On Windows all the https manual tests work and most of thee ssh test work as well. Strange!

Jan.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/theseion/LibGit/issues/41#issuecomment-217305483

[theseion]

On 17 May 2016, at 21:11, jvdsandt notifications@github.com wrote:

Hi,

On Fri, May 6, 2016 at 1:07 AM, Martín Dias notifications@github.com wrote:

This is getting better, now I have a git error when executing a snippet. It is inspired in MCGitHubRepository >> projectDirectoryFrom:version:. What I'm not sure is if I made some mistake when I created my test_data.json data. Do you use it? I have a template at hand so I paste it below. It's a file in the same directory as the pharo image with this contents:

{ "credentials" : { "keyFilePrivatePath" : "/home//.ssh/github", "keyFilePublicPath" : "/home//.ssh/github.pub", "keyPassPhrase" : “", "password" : “", "username" : “", "usernameSsh" : "" }, "urls" : { "repositoryUrlHttps" : "https://github.com/tinchodias/filesystem-git-test-repository.git", "repositoryUrlLocal" : "file:///home//dev/git/stuff", "repositoryUrlSsh" : "git@github.com:tinchodias/filesystem-git-test-repository.git" } }

I don't know if I have made some mistake in some parameter, but I suspect there is some error in the bindings because I always get the same error.

Snippet and steps to reproduce:

1. Load

Metacello new baseline: #LibGit; repository: 'github://jvdsandt/LibGit:pharo50'; load: #development.

1.

Load credential data from test_data.json

LGitTestRepository loadTestData. 2.

Evaluate

| pharoGitRepoPath repository | pharoGitRepoPath := 'pharo-core' asFileReference.

LGitGlobal runSequence: [ repository := LGitRepository on: pharoGitRepoPath. (pharoGitRepoPath exists and: [ repository isProperRepository ]) ifFalse: [ repository cloneHttps: 'https://github.com/pharo-project/pharo-core.git'; checkout: 'master' ] ifTrue: [ | credentials credentialsCallback | repository open. credentials := LGitRemote credentialsSsh. credentialsCallback := LGitCredAcquireCallback on: [ :cred :url :username_from_url :allowed_types :data | credentials createWith: cred. 0 ]. (LGitRemote of: repository named: 'origin') lookup; pullWithFetchOptions: (LGitFetchOptions defaults callbacks: (LGitRemoteCallbacks defaults credentials: credentialsCallback; yourself); yourself). repository fastForward ] ].

1. Get error ("a LGitReturnCodeEnum(#git_error [-1])")

LGit_GIT_ERROR: no error message set by libgit2 LGitReturnCodeEnum>>handleLGitReturnCode LGitRemote(LGitExternalObject)>>withReturnHandlerDo: LGitRemote>>pullWithFetchOptions:

and

LGitError lastMessage "'no error message set by libgit2'"

Yes, I can reproduce this problem on my linux machine (Ubuntu 14.04). When I try the manual test cases I notice that the tests that use https work and most ssh based tests fail. They fail with the 'no error message set by libgit2' message. As Max said, I don't think this is related to the Pharo5 port.

When I run the manual tests on OS X I get different errors and the tests that use https also fail :-( Tests that use the network fail with LGit_GIT_ERROR: Failed to connect to github.com: Interrupted system call. I think this error is related to some kind of issue with UFFI or with the VM. I will ask about this on the Pharo mailing list.

On Windows all the https manual tests work and most of thee ssh test work as well. Strange!

That’s good news (kind of :) ). On OS X however everything should work. That’s my dev platform. Maybe there is an issue with UFFI. There have been a couple which we only discovered because of libgit2.

Jan.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/theseion/LibGit/issues/41#issuecomment-217305483

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/theseion/LibGit/issues/41#issuecomment-219822602

[tinchodias]

I forgot to tell you that I tested again without using credentials (but still in linux) and it worked very good! I cloned a repository and commited a lot of files.