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

Merging #434 into master will decrease coverage by 3.33%.
The diff coverage is 100.00%.

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

Impacted Files	Coverage Δ
src/julia_to_gap.jl	54.05% <ø> (-40.24%)	⬇️
pkg/JuliaInterface/src/convert.c	86.84% <100.00%> (-7.90%)	⬇️
test/help.jl	0.00% <0.00%> (-100.00%)	⬇️
src/constructors.jl	4.00% <0.00%> (-91.84%)	⬇️
src/packages.jl	0.00% <0.00%> (-51.52%)	⬇️
src/gap_to_julia.jl	48.36% <0.00%> (-47.61%)	⬇️
test/conversion.jl	0.00% <0.00%> (-33.34%)	⬇️
src/adapter.jl	68.00% <0.00%> (-28.00%)	⬇️
src/ccalls.jl	83.33% <0.00%> (-15.08%)	⬇️
... and 6 more

[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