Interfacing Eiffel application to Git?

[Thomas Beale]

I have historically connected our modelling application to Git by running Git commands in a shell using the PROCESS library.

This makes the commands very slow, mainly because I am running the commands like the following in a bash shell, (made even slower under cygwin under Windows, which I use).

c:\cygwin64\bin\bash.exe -c -l "cd `cygpath -u 'C:\dev\openEHR\adl-archetypes'`; git config --get remote.origin.url"

This kind of command line is run by code like this:

do_system_run_command_query (a_cmd_line: STRING; in_directory: detachable STRING)

-- run `a_cmd_line' and return result; run process in specified directory if set

local

pf: PROCESS_FACTORY

proc: PROCESS

do

            last_command_result_cache.put (create {PROCESS_RESULT}.make (a_cmd_line, in_directory))

create pf

proc := pf.process_launcher_with_command_line (a_cmd_line, in_directory)

proc.set_hidden (True)

proc.redirect_input_to_stream

proc.redirect_error_to_agent (agent (s: STRING) do last_command_result.append_stderr (s) end)

proc.redirect_output_to_agent (agent (s: STRING) do last_command_result.append_stdout (s) end)

proc.launch

proc.wait_for_exit

last_command_result.set_exit_code (proc.exit_code)

end

Each command causes a new bash.exe - so every single command is slow. This approach also relies on the git that is installed on the system, probably a good thing.

To do better than this, I can think of a couple of approaches:

1. launch and maintain a single bash instance, and send each new git command to that
2. use a git library that does everything without using a shell; but still on another thread, so that Git commands don't block the UI

I am not sure how to do 1. I can think of ways, e.g. getting the process id, and attaching to its stdin, but I don't know the details of doing this. 

For 2., does anyone have a git interface library?

Any thoughts appreciated.

- thomas

[Larry Rix]

https://github.com/jvelilla?tab=overview&org=libgit2

[Colin Adams]

I interfaced libgit2 to Eiffel. Unfortunately I can't release the source, but it is easy to do.

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/b126f577-0d0a-43ce-a2be-9cfe286593cd%40googlegroups.com.

[Larry Rix]

Sorry, I did not take this far enough.

https://github.com/jvelilla/wrap_libgit2

On Saturday, December 7, 2019 at 8:08:48 AM UTC-5, Larry Rix wrote:

https://github.com/jvelilla?tab=overview&org=libgit2

[javier hector]

Hi Thomas

As Larry said there is a very basic wrapper of libgit2 using WrapC with basic examples. Please check it out at https://github.com/eiffel-wrap-c/wrap_libgit2

At the moment the interface is very low level, but if you want we can collaborate an create a high level interface for it.

-- Javier

[Larry Rix]

I was able to get one of the examples working in about 10 minutes flat! This has the potential for being an excellent library and tool to bring into EiffelStudio so that ES can work directly with Git/GitHub!

[Thomas Beale]

Thanks for the pointers. I'll have a play. The level of abstraction I would like is roughly this class in my library.

- thomas

[javier hector]

Hi Thomas, have you been able to play with the library?

Please let me know if you need some help.

/Javier

[Thomas Beale]

Hi Javier,

I finally got around to trying this.

I have built libgit2 according to the README; it installs a .so and a .a (when I did a static build as well) into /usr/local/lib:

thomas@Meduse-VB:~/Eiffel/eiffel-wrap-c/libgit2/build$ ls /usr/local/lib/*git*
/usr/local/lib/libgit2.a   /usr/local/lib/libgit2.so.0.99
/usr/local/lib/libgit2.so  /usr/local/lib/libgit2.so.0.99.0

Then I tried to build WrapC, but it failed as follows. Looks like something basic to fix.

thomas@Meduse-VB:~/Eiffel/eiffel-wrap-c/WrapC/src/ewg$ ec -config system.ecf -target wrap_c -finalize -c_compile -project_path .
Eiffel Compilation Manager
Version 19.05.10.3187 GPL Edition - linux-x86-64

Degree 6: Examining System
Degree 5: Parsing Classes
Degree 4: Analyzing Inheritance
Degree 3: Checking Types
-------------------------------------------------------------------------------

Warning code: VD81

Non-total order on real numbers specified for the target 'wrap_c' is now obsolete.
Consider changing the setting to "True" and using features with the names starting from "ieee" of the classes REAL_32 and REAL_64 if needed.

How to change the setting?
    1. Open the project settings dialog: Project | Project Settings...
    2. For every affected target, navigate to Target | Advanced.
    3. In the section "Language" in the pane on the right, set the value of the setting "Total Order on REALs" to "True".

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_STRUCT_FEATURE_NAMES
Source class: ANY
Feature: deep_copy
Feature: deep_twin Class: EWG_STRUCT_FEATURE_NAMES Version from: ANY
Not exported to class EWG_STRUCT_FEATURE_NAMES
Line: 258
      do
->      copy (other.deep_twin)
      ensure

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_STRUCT_FEATURE_NAMES
Source class: ANY
Feature: is_deep_equal
Feature: is_deep_equal Class: EWG_STRUCT_FEATURE_NAMES Version from: ANY
Not exported to class EWG_STRUCT_FEATURE_NAMES
Line: 131
        same_type: Result implies same_type (other)
->      symmetric: Result implies other.is_deep_equal (Current)
      end

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_STRUCT_FEATURE_NAMES
Source class: ANY
Feature: standard_is_equal
Feature: standard_is_equal Class: EWG_STRUCT_FEATURE_NAMES Version from: ANY
Not exported to class EWG_STRUCT_FEATURE_NAMES
Line: 84
        same_type: Result implies same_type (other)
->      symmetric: Result implies other.standard_is_equal (Current)
      end

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_ANY_FEATURE_NAMES
Source class: ANY
Feature: deep_copy
Feature: deep_twin Class: EWG_ANY_FEATURE_NAMES Version from: ANY
Not exported to class EWG_ANY_FEATURE_NAMES
Line: 258
      do
->      copy (other.deep_twin)
      ensure

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_ANY_FEATURE_NAMES
Source class: ANY
Feature: is_deep_equal
Feature: is_deep_equal Class: EWG_ANY_FEATURE_NAMES Version from: ANY
Not exported to class EWG_ANY_FEATURE_NAMES
Line: 131
        same_type: Result implies same_type (other)
->      symmetric: Result implies other.is_deep_equal (Current)
      end

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_ANY_FEATURE_NAMES
Source class: ANY
Feature: standard_is_equal
Feature: standard_is_equal Class: EWG_ANY_FEATURE_NAMES Version from: ANY
Not exported to class EWG_ANY_FEATURE_NAMES
Line: 84
        same_type: Result implies same_type (other)
->      symmetric: Result implies other.standard_is_equal (Current)
      end

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_CONFIG_WRAPPER_TYPE_NAMES
Source class: ANY
Feature: deep_copy
Feature: deep_twin Class: EWG_CONFIG_WRAPPER_TYPE_NAMES Version from: ANY
Not exported to class EWG_CONFIG_WRAPPER_TYPE_NAMES
Line: 258
      do
->      copy (other.deep_twin)
      ensure

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_CONFIG_WRAPPER_TYPE_NAMES
Source class: ANY
Feature: is_deep_equal
Feature: is_deep_equal Class: EWG_CONFIG_WRAPPER_TYPE_NAMES Version from: ANY
Not exported to class EWG_CONFIG_WRAPPER_TYPE_NAMES
Line: 131
        same_type: Result implies same_type (other)
->      symmetric: Result implies other.is_deep_equal (Current)
      end

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_CONFIG_WRAPPER_TYPE_NAMES
Source class: ANY
Feature: standard_is_equal
Feature: standard_is_equal Class: EWG_CONFIG_WRAPPER_TYPE_NAMES Version from: ANY
Not exported to class EWG_CONFIG_WRAPPER_TYPE_NAMES
Line: 84
        same_type: Result implies same_type (other)
->      symmetric: Result implies other.standard_is_equal (Current)
      end

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_CONFIG_VALIDATOR
Source class: ANY
Feature: deep_copy
Feature: deep_twin Class: EWG_CONFIG_VALIDATOR Version from: ANY
Not exported to class EWG_CONFIG_VALIDATOR
Line: 258
      do
->      copy (other.deep_twin)
      ensure

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_CONFIG_VALIDATOR
Source class: ANY
Feature: is_deep_equal
Feature: is_deep_equal Class: EWG_CONFIG_VALIDATOR Version from: ANY
Not exported to class EWG_CONFIG_VALIDATOR
Line: 131
        same_type: Result implies same_type (other)
->      symmetric: Result implies other.is_deep_equal (Current)
      end

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_CONFIG_VALIDATOR
Source class: ANY
Feature: standard_is_equal
Feature: standard_is_equal Class: EWG_CONFIG_VALIDATOR Version from: ANY
Not exported to class EWG_CONFIG_VALIDATOR
Line: 84
        same_type: Result implies same_type (other)
->      symmetric: Result implies other.standard_is_equal (Current)
      end

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_CONFIG_SYSTEM
Source class: ANY
Feature: deep_copy
Feature: deep_twin Class: EWG_CONFIG_SYSTEM Version from: ANY
Not exported to class EWG_CONFIG_SYSTEM
Line: 258
      do
->      copy (other.deep_twin)
      ensure

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_CONFIG_SYSTEM
Source class: ANY
Feature: is_deep_equal
Feature: is_deep_equal Class: EWG_CONFIG_SYSTEM Version from: ANY
Not exported to class EWG_CONFIG_SYSTEM
Line: 131
        same_type: Result implies same_type (other)
->      symmetric: Result implies other.is_deep_equal (Current)
      end

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_CONFIG_SYSTEM
Source class: ANY
Feature: standard_is_equal
Feature: standard_is_equal Class: EWG_CONFIG_SYSTEM Version from: ANY
Not exported to class EWG_CONFIG_SYSTEM
Line: 84
        same_type: Result implies same_type (other)
->      symmetric: Result implies other.standard_is_equal (Current)
      end

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_ABSTRACT_WRAPPER
Source class: ANY
Feature: deep_copy
Feature: deep_twin Class: EWG_ABSTRACT_WRAPPER Version from: ANY
Not exported to class EWG_ABSTRACT_WRAPPER
Line: 258
      do
->      copy (other.deep_twin)
      ensure

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_ABSTRACT_WRAPPER
Source class: ANY
Feature: is_deep_equal
Feature: is_deep_equal Class: EWG_ABSTRACT_WRAPPER Version from: ANY
Not exported to class EWG_ABSTRACT_WRAPPER
Line: 131
        same_type: Result implies same_type (other)
->      symmetric: Result implies other.is_deep_equal (Current)
      end

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_ABSTRACT_WRAPPER
Source class: ANY
Feature: standard_is_equal
Feature: standard_is_equal Class: EWG_ABSTRACT_WRAPPER Version from: ANY
Not exported to class EWG_ABSTRACT_WRAPPER
Line: 84
        same_type: Result implies same_type (other)
->      symmetric: Result implies other.standard_is_equal (Current)
      end

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_EIFFEL_WRAPPER_SET
Source class: ANY
Feature: deep_copy
Feature: deep_twin Class: EWG_EIFFEL_WRAPPER_SET Version from: ANY
Not exported to class EWG_EIFFEL_WRAPPER_SET
Line: 258
      do
->      copy (other.deep_twin)
      ensure

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_EIFFEL_WRAPPER_SET
Source class: ANY
Feature: is_deep_equal
Feature: is_deep_equal Class: EWG_EIFFEL_WRAPPER_SET Version from: ANY
Not exported to class EWG_EIFFEL_WRAPPER_SET
Line: 131
        same_type: Result implies same_type (other)
->      symmetric: Result implies other.is_deep_equal (Current)
      end

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_EIFFEL_WRAPPER_SET
Source class: ANY
Feature: standard_is_equal
Feature: standard_is_equal Class: EWG_EIFFEL_WRAPPER_SET Version from: ANY
Not exported to class EWG_EIFFEL_WRAPPER_SET
Line: 84
        same_type: Result implies same_type (other)
->      symmetric: Result implies other.standard_is_equal (Current)
      end

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_GENERATOR
Source class: ANY
Feature: deep_copy
Feature: deep_twin Class: EWG_GENERATOR Version from: ANY
Not exported to class EWG_GENERATOR
Line: 258
      do
->      copy (other.deep_twin)
      ensure

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_GENERATOR
Source class: ANY
Feature: is_deep_equal
Feature: is_deep_equal Class: EWG_GENERATOR Version from: ANY
Not exported to class EWG_GENERATOR
Line: 131
        same_type: Result implies same_type (other)
->      symmetric: Result implies other.is_deep_equal (Current)
      end

-------------------------------------------------------------------------------

Error code: VUEX(2)

Error: feature of qualified call is not available to client class.
What to do: make sure feature after dot is exported to caller.

Class: EWG_GENERATOR
Source class: ANY
Feature: standard_is_equal
Feature: standard_is_equal Class: EWG_GENERATOR Version from: ANY
Not exported to class EWG_GENERATOR
Line: 84
        same_type: Result implies same_type (other)
->      symmetric: Result implies other.standard_is_equal (Current)
      end

-------------------------------------------------------------------------------

Press <Return> to resume compilation or <Q> to quit

[javier hector]

Hi Thomas thanks for reporting the issue, I didn't notice the issue with Eiffel 19.05.

I'will fix it ASAP.

[javier hector]

Hi Thomas, I´ve fixed the issue.

Please check the latest code https://github.com/eiffel-wrap-c/WrapC

Javier

[Thomas Beale]

Getting closer...

now when using wrap_c, according to the wrap_libgit2 README, I get:

thomas@Meduse-VB:~/Eiffel/eiffel-wrap-c/wrap_libgit2$ wrap_c --verbose --output-dir=$LIB_PATH/library/generated_wrapper --full-header=$LIB_PATH/library/C/include/git2.h config.xml
[100%]   phase 1: parsing
  parsed successfuly
  found:
    . 1954 types
    . 948 declarations
[100%]   phase 2: resolving aliases for anonymous types
[100%]   phase 3: wrapping declarations
[100%]   phase 3: selecting types to wrap
[100%]   phase 3: wrapping types
[100%]   phase 3: resolving feature name clashes
  found:
    . 77 enum wrappers
    . 144 struct wrappers
    . 7 union wrappers
    . 1536 function wrappers
    . 66 callback wrappers
[100%]   phase 4: generating enum wrappers
[100%]   phase 4: generating struct wrappers
[100%]   phase 4: generating union wrappers
[100%]   phase 4: generating function wrappers
[100%]   phase 4: generating function callback wrappers
phase 5: generating Makefiles and WrapC header

thomas@Meduse-VB:~/Eiffel/eiffel-wrap-c/wrap_libgit2/library/generated_wrapper/c/src$ ls -lt
total 216
-rw-r--r-- 1 thomas thomas    504 Apr  1 10:41 build.eant
-rw-r--r-- 1 thomas thomas   1090 Apr  1 10:41 Makefile.SH
-rw-r--r-- 1 thomas thomas    898 Apr  1 10:41 Makefile-win.SH
-rw-r--r-- 1 thomas thomas 184216 Apr  1 10:41 ewg_unknown_callback_c_glue_code.c
-rw-r--r-- 1 thomas thomas  22099 Mar 31 20:16 ewg_libgit2_callback_c_glue_code.c

Then when I run the finish_freezing command:

thomas@Meduse-VB:~/Eiffel/eiffel-wrap-c/wrap_libgit2/library/generated_wrapper/c/src$ finish_freezing -library
Eiffel C/C++ Compilation Tool - Version 19.05
Copyright Eiffel Software 1985-2019. All Rights Reserved

Generating C libraries ...
Extracting ./Makefile (with variable substitutions)
Package unknown was not found in the pkg-config search path.
Perhaps you should add the directory containing `unknown.pc'
to the PKG_CONFIG_PATH environment variable
No package 'unknown' found
C compilation completed

There is a .pc file in /usr/local/pkgconfig:

thomas@Meduse-VB:~/Eiffel/eiffel-wrap-c/wrap_libgit2/library/generated_wrapper/c/src$ ls /usr/local/lib/pkgconfig
libgit2.pc

However, there is only eif_unknown.a in the expected location

thomas@Meduse-VB:~/Eiffel/eiffel-wrap-c/wrap_libgit2/library$ ls C/spec/linux-x86-64/lib/
eif_unknown.a

Whereas the build of a wrap_libgit2 example is expecting eif_libgit2.a

Preparing C compilation
Compiling C code in E1
gcc: error: /home/thomas/Eiffel/eiffel-wrap-c/wrap_libgit2/library/C/spec/linux-x86-64/lib/eif_libgit2.a: No such file or directory
make: *** [Makefile:171: git_status] Error 1

At the moment I don't know what the 'unknown_callback' lib is about, or why the other one is not being built.

- thomas

[javier hector]

Hi Thomas,

On Wednesday, April 1, 2020 at 7:00:25 AM UTC-3, Thomas Beale wrote:

Getting closer...

now when using wrap_c, according to the wrap_libgit2 README, I get:

Ok I see there is an issue in the README file, i've fixed it now

The command line should be 

wrap_c --verbose --output-dir=$LIB_PATH/library/generated_wrapper --full-header=$LIB_PATH/library/C/include/git2.h --config=$LIB_PATH/library/config.xml

The name of the C glue code library  eif_<library_name>.[a|lib], is created using the name of ewg_config element defined in the config.xml file

<ewg_config name="libgit2">

Since the command point to an not existing config.xml, it uses a default config with unknow name.

 

thomas@Meduse-VB:~/Eiffel/eiffel-wrap-c/wrap_libgit2/library$ ls C/spec/linux-x86-64/lib/
eif_unknown.a

Whereas the build of a wrap_libgit2 example is expecting eif_libgit2.a

Preparing C compilation
Compiling C code in E1
gcc: error: /home/thomas/Eiffel/eiffel-wrap-c/wrap_libgit2/library/C/spec/linux-x86-64/lib/eif_libgit2.a: No such file or directory
make: *** [Makefile:171: git_status] Error 1

At the moment I don't know what the 'unknown_callback' lib is about, or why the other one is not being built.

- thomas

Let me know if now works.

Javier

[Thomas Beale]

I think I am there...

I can compile and finalise the git_status example. However, when I run it from the command line, I get the following

thomas@Meduse-VB:~/Eiffel/eiffel-wrap-c/wrap_libgit2$ git_status
git_status: error while loading shared libraries: libgit2.so.0.99: cannot open shared object file: No such file or directory

thomas@Meduse-VB:~/Eiffel/eiffel-wrap-c/wrap_libgit2$ ls /usr/local/lib
libgit2.a  libgit2.so  libgit2.so.0.99  libgit2.so.0.99.0  pkgconfig  python2.7  python3.7

Howver, as you can see, the .so libs are in an expected place.

Running sudo ldconfig fixes that, so might be worth mentioning in the README. I now seem to have a working git_status, so I'll play around with the various examples and commands now.

Thanks very much for the quick help.

- thomas

[javier hector]

Great, I will add it ASAP

Thanks very much for the quick help.

You are welcome

- thomas

[Thomas Beale]

Hi Javier,

initial experiments don't get the results I would expect.

First with git_status:

thomas@Meduse-VB:~/openEHR-specifications/specifications-AM$ git_status --porcelain

 Intializing Libgit2
  M docs/ADL2/master04-cadl.adoc
  M docs/ADL2/master04-cadl.adoc
  M docs/ADL2/master04-cadl.adoc
  M docs/ADL2/master04-cadl.adoc
  M docs/ADL2/master04-cadl.adoc
  M docs/ADL2/master04-cadl.adoc
  M docs/ADL2/master04-cadl.adoc
  M docs/ADL2/master04-cadl.adoc
  M docs/ADL2/master04-cadl.adoc thomas@Meduse-VB:~/openEHR-specifications/specifications-AM$

thomas@Meduse-VB:~/openEHR-specifications/specifications-AM$ git status --porcelain
 M docs/ADL2/master04-cadl.adoc
 M docs/AOM2/master04-constraint_model_package.adoc
 M docs/UML/class_index.adoc
 M docs/UML/diagrams/AM-aom2.constraint_model-bottom.svg
 M docs/UML/diagrams/AM-aom2.constraint_model.svg
 M docs/UML/diagrams/AM-aom2.rules.svg
 M docs/UML/diagrams/AM-example-demographics-parties.svg
 M docs/UML/diagrams/AM-p_aom2-lower.svg
 M docs/index.html

You can see it produces the same number of lines, but always with the same file name, not the 9 different files from 'git status'. Also an annoying 'Initializing libgit2' at the start, and a missing newline at the end.

Then with ls_remote.

thomas@Meduse-VB:~/openEHR-specifications/specifications-AM$ ls_remote

 Missing command line parameter <remote>

lxs [--git-dir=<directory>]
<remote>thomas@Meduse-VB:~/openEHR-specifications/specifications-AM$ git ls-remote
From https://github.com/openEHR/specifications-AM.git
a61688a4f9dc7039b923be0894ddb72a43668339    HEAD
7060042e0d0d0a42e0850ae99830f5600346f5b7    refs/heads/Release-2.0.6
a61688a4f9dc7039b923be0894ddb72a43668339    refs/heads/master
2769bdeebdca166d4724228e7c180ebc3d6cbe88    refs/tags/Release-2.0.6
1779fa90862c191a25faea59421ef37d446d880d    refs/tags/Release-2.0.6^{}
f589086daf6b20b0e991f829f9b64bc02c3f88aa    refs/tags/Release-2.0.6v1
068533c2fe95ad7ee4cc4e78ae5c673dea4f461a    refs/tags/Release-2.0.6v1^{}
5c644689075e9b86c4c1649c907ff70da8bd27a1    refs/tags/Release-2.0.6v2
7060042e0d0d0a42e0850ae99830f5600346f5b7    refs/tags/Release-2.0.6v2^{}

- thomas

[javier hector]

Hi Thomas,

I've reproduced the issue, I've fixed the code, removed the `'Initializing libgit2 ` message, I've tested it with the following options  git_status --porcelain or git_status --long

 

Then with ls_remote.

thomas@Meduse-VB:~/openEHR-specifications/specifications-AM$ ls_remote

 Missing command line parameter <remote>

lxs [--git-dir=<directory>]
<remote>thomas@Meduse-VB:~/openEHR-specifications/specifications-AM$ git ls-remote
From https://github.com/openEHR/specifications-AM.git
a61688a4f9dc7039b923be0894ddb72a43668339    HEAD
7060042e0d0d0a42e0850ae99830f5600346f5b7    refs/heads/Release-2.0.6
a61688a4f9dc7039b923be0894ddb72a43668339    refs/heads/master
2769bdeebdca166d4724228e7c180ebc3d6cbe88    refs/tags/Release-2.0.6
1779fa90862c191a25faea59421ef37d446d880d    refs/tags/Release-2.0.6^{}
f589086daf6b20b0e991f829f9b64bc02c3f88aa    refs/tags/Release-2.0.6v1
068533c2fe95ad7ee4cc4e78ae5c673dea4f461a    refs/tags/Release-2.0.6v1^{}
5c644689075e9b86c4c1649c907ff70da8bd27a1    refs/tags/Release-2.0.6v2
7060042e0d0d0a42e0850ae99830f5600346f5b7    refs/tags/Release-2.0.6v2^{}

For ls_remote in our case we need to call it with the remote ( I need to check the API to figure out how to get that info from .git) In your case you will need to do

ls_remote https://github.com/openEHR/specifications-AM.git


Javier

- thomas

[Thomas Beale]

Hi Javier,

the behaviour of git_status changes depending on how I build it.

If a do a build from scratch and then finalise (from inside Estudio) WITH assertions (whatever is enabled in the .ecf, I didn't change anything), I get a binary that works (except the final line is still missing an LF):

thomas@Meduse-VB:~/openEHR-specifications/specifications-AM$ git_status

  M docs/ADL2/master04-cadl.adoc
  M docs/AOM2/master04-constraint_model_package.adoc
  M docs/UML/class_index.adoc
  M docs/UML/diagrams/AM-aom2.constraint_model-bottom.svg
  M docs/UML/diagrams/AM-aom2.constraint_model.svg
  M docs/UML/diagrams/AM-aom2.rules.svg
  M docs/UML/diagrams/AM-example-demographics-parties.svg
  M docs/UML/diagrams/AM-p_aom2-lower.svg
  M docs/index.html

If I do a clean build and finalise WITHOUT assertions, I get (as usual) a much small binary, that now doesn't work:

thomas@Meduse-VB:~/openEHR-specifications/specifications-AM$ git_status

Could not get status /home/thomas/openEHR-specifications/specifications-AM/.git/

I tried a similar finalised build of ls_remote, and it crashed (APPLICATION root creation failed).

I suspect that the removal of assertions is removing some unreferenced code that is needed in a callback, and/or only referenced in some pre- or post-condition. I don't have time to figure out what is going wrong, but if you do these two finalise variants you should be able to reproduce the problem. I would expect similar problems with the other tools as well. Most likely easy to fix, but much easier if one knows the architecture of the code!

Since ultimately most users will want to use the wrapper from their own code, they need to know what the general rule/approach is in order to prevent loss of code due to finalisation (assuming that is indeed the problem).

hope this gets us a bit further.

- thomas

[javier hector]

Hi Thomas,

On Thursday, April 2, 2020 at 8:13:27 AM UTC-3, Thomas Beale wrote:

Hi Javier,

the behaviour of git_status changes depending on how I build it.

If a do a build from scratch and then finalise (from inside Estudio) WITH assertions (whatever is enabled in the .ecf, I didn't change anything), I get a binary that works (except the final line is still missing an LF):

thomas@Meduse-VB:~/openEHR-specifications/specifications-AM$ git_status

  M docs/ADL2/master04-cadl.adoc
  M docs/AOM2/master04-constraint_model_package.adoc
  M docs/UML/class_index.adoc
  M docs/UML/diagrams/AM-aom2.constraint_model-bottom.svg
  M docs/UML/diagrams/AM-aom2.constraint_model.svg
  M docs/UML/diagrams/AM-aom2.rules.svg
  M docs/UML/diagrams/AM-example-demographics-parties.svg
  M docs/UML/diagrams/AM-p_aom2-lower.svg
  M docs/index.html

If I do a clean build and finalise WITHOUT assertions, I get (as usual) a much small binary, that now doesn't work:

I've fixed the issue with `git_status`, I will review the other in the comming days.

thomas@Meduse-VB:~/openEHR-specifications/specifications-AM$ git_status

Could not get status /home/thomas/openEHR-specifications/specifications-AM/.git/

I tried a similar finalised build of ls_remote, and it crashed (APPLICATION root creation failed).

I suspect that the removal of assertions is removing some unreferenced code that is needed in a callback, and/or only referenced in some pre- or post-condition. I don't have time to figure out what is going wrong, but if you do these two finalise variants you should be able to reproduce the problem. I would expect similar problems with the other tools as well. Most likely easy to fix, but much easier if one knows the architecture of the code!

I've reproduced the issue with ls_remote on Linux but works fine on Windows, I will check and let you know ASAP.

Since ultimately most users will want to use the wrapper from their own code, they need to know what the general rule/approach is in order to prevent loss of code due to finalisation (assuming that is indeed the problem).

hope this gets us a bit further.

Javier

 

- thomas

[javier hector]

Hi Thomas

On Thursday, April 2, 2020 at 11:35:55 AM UTC-3, javier hector wrote:

Hi Thomas,
On Thursday, April 2, 2020 at 8:13:27 AM UTC-3, Thomas Beale wrote:

Hi Javier,

the behaviour of git_status changes depending on how I build it.

If a do a build from scratch and then finalise (from inside Estudio) WITH assertions (whatever is enabled in the .ecf, I didn't change anything), I get a binary that works (except the final line is still missing an LF):

thomas@Meduse-VB:~/openEHR-specifications/specifications-AM$ git_status

  M docs/ADL2/master04-cadl.adoc
  M docs/AOM2/master04-constraint_model_package.adoc
  M docs/UML/class_index.adoc
  M docs/UML/diagrams/AM-aom2.constraint_model-bottom.svg
  M docs/UML/diagrams/AM-aom2.constraint_model.svg
  M docs/UML/diagrams/AM-aom2.rules.svg
  M docs/UML/diagrams/AM-example-demographics-parties.svg
  M docs/UML/diagrams/AM-p_aom2-lower.svg
  M docs/index.html

If I do a clean build and finalise WITHOUT assertions, I get (as usual) a much small binary, that now doesn't work:

I've fixed the issue with `git_status`, I will review the other in the comming days.

thomas@Meduse-VB:~/openEHR-specifications/specifications-AM$ git_status

Could not get status /home/thomas/openEHR-specifications/specifications-AM/.git/

I tried a similar finalised build of ls_remote, and it crashed (APPLICATION root creation failed).

I suspect that the removal of assertions is removing some unreferenced code that is needed in a callback, and/or only referenced in some pre- or post-condition. I don't have time to figure out what is going wrong, but if you do these two finalise variants you should be able to reproduce the problem. I would expect similar problems with the other tools as well. Most likely easy to fix, but much easier if one knows the architecture of the code!

I've reproduced the issue with ls_remote on Linux but works fine on Windows, I will check and let you know ASAP.

I've fixed the issues with finalized code with and without assertions.

On the other hand, to get the ls_remote from the local repository the commad is:

ls_remote .  

Since ultimately most users will want to use the wrapper from their own code, they need to know what the general rule/approach is in order to prevent loss of code due to finalisation (assuming that is indeed the problem).

hope this gets us a bit further.

Javier

Just for info I didn't check the other examples, I will do ASAP.

Javier

 

- thomas

[javier hector]

Hi Thomas, just for info,  all the examples were updated except `describe`, I will finish it soon.

A few days ago libgit2 release 1.0.0, so I will udpate wrap_ligbit2 to use it in the next days.

Javier