This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

before kawa-1.8


Hi,

>There have beeb lots of improvements in CVS.  I'm trying hard to get 
>Kawa 1.8 finished.

One thing that comes to my mind as a possible improvement is somewhat better integration of Java functions returning java.math.BigInteger.
All Java functions which manipulate large numbers operate on these, and I've been bitten several times by things which display as a large number in Kawa but are not Kawa objects (i.e. Scheme + or -  obviously don't work on them).
But I don't know whether it would be a good idea to automatically transform a java.math.BigInteger into a gnu.math.BigInteger when entering Scheme. They may have different semantics (shared or not, immutable or not byte[]).

I vaguely remember mentioning a biginteger problem with JDBC last year, but I don't have access to an Oracle DB anymore for testing.

You take me a bit early, I wanted to see next week if there are constructors etc. which probably operate on a byte[] representation of java.math.BigInteger and gnu.math.BigInteger, in order to transform one into the other and back.

And I'd welcome the u/sNvector->byte[] access :-)

>> (: 57 :) fn:node-kind(document("5.xml")/*[1]/*[3])
>One of many function I just haven't gotten around to implementing. 
Oh, I had understood the document in the sense that dm:node-kind is the standard, but that qexo provides fn:node-kind instead. I did not understand that the standard provides two ways of expressing the same thing (does it)?

Regards,
	Jorg Hohle


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]