proposed fix for a conversion inconsistency

[ThomasBreuer]

Currently the following happens.

gap> x:= JuliaEvalString( "2^60" );
1152921504606846976
gap> GAPToJulia( 2^60 );
<Julia: 1152921504606846976>

The number x is not an immediate integer, and Julia.Base.sqrt( x ) yields an error.
The result of GAPToJulia (computed using gap_to_julia) looks correct.
JuliaEvalString calls gap_julia, which calls ObjInt_Int8 in this case;
I propose to use NewJuliaObj instead.

After this change, the tests exhibit a problem with the method

julia_to_gap(x::Int64)  = x

which is simply wrong.

Perhaps this proposal is not a good idea.
Converting Int64 to GAP becomes more expensive because the argument has to be checked.
For the moment, I have no good idea to improve this.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.18%. Comparing base (40eb6b5) to head (100adb8).
⚠️ Report is 769 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #434      +/-   ##
==========================================
- Coverage   73.51%   70.18%   -3.34%     
==========================================
  Files          65       63       -2     
  Lines        5067     5074       +7     
==========================================
- Hits         3725     3561     -164     
- Misses       1342     1513     +171     

Files with missing lines	Coverage Δ
pkg/JuliaInterface/src/convert.c	86.84% <100.00%> (-7.90%)	⬇️
src/julia_to_gap.jl	54.05% <ø> (-40.24%)	⬇️

... and 12 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[fingolfin]

This reverts parts of PR #357. As such, I think it will just replace one set of problems with another; there is simply no good solution here.

[ThomasBreuer]

@fingolfin Thanks.
I think JuliaEvalString must return objects that are valid arguments for Julia functions,
in the same way as GAP.EvalString must return valid GAP objects;
GAP.EvalString( "2^60" ) yields a GapObj.

In the case of "2^60", Julia itself creates an object of type Int64.
(GAPToJulia( 2^60 ) yields a BigInt, but this is another question.)

I see that the current proposal causes efficiency problems, but which logical problems had been addressed by #357?

(By the way, the test failure is due to an explicit test for GAP's opinion about the type of 2^60.)

[fingolfin]

@ThomasBreuer see issue #332