The bugs in J64 com are unlikely to be fixed soon (at least months away). You'll need to use a workaround.
Perhaps the simplest would be to use 3!:4 (3 ic 4) to convert the 64 bit ints to bytes, transfer those, and then do a cast on the c# side. Another way would be to pass pointers but this would require extra work on the C# side (C helper dll to convert poiinter/type/count to C# array). On Mon, Aug 18, 2014 at 11:47 AM, bill lam <[email protected]> wrote: > Sorry. You are correct. > > The following comment appears in j engine source. I guess this > was written more than a decade ago when 64-bit COM was uncommon. > But by now, there is not so much incentive to support 64-bit COM. > > //! 64 bit problems - com and dll interface is 32 bit - needs test and thought > > Пн, 18 авг 2014, [email protected] написал(а): >> Thanks for your reply. >> >> >I'm not an expert on C#, but it seems that int is always 4-byte whether on >> >32 or 64 bit, so that you propably need int64[] for J64. >> Yes, that right. Integers like int or Int32 have a size of 32 bit, but that >> is not the problem here. Already the _j.GetB always returns boxed int32 >> values. If I try to cast to Int64, I get an corresponding exception at >> runtime. >> >> >On Aug 18, 2014 8:16 PM, <[email protected]> wrote: >> > >> >> I have an issue with the 64-bit JDLLServer in relation to 64 integers. >> >>It >> >> seems that JDLLServer handles only the lower 32 bits of a 64 bit value. >> >>The >> >> following test demonstrates this issue: >> >> >> >> Test (C#): >> >> var value = 1000 + ((Int64)1 << 32); >> >> _j.Do(String.Format("a =: {0}", value)); >> >> Assert.AreEqual(value, _j.GetB("a")); >> >> >> >> Results: >> >> Assert.AreEqual failed. Expected:<4294968296 (System.Int64)>. >> >>Actual:<1000 >> >> (System.Int32)>. >> >> >> >> >> >> There is a similar problem to getting int arrays. The following test >> >>fails: >> >> >> >> _j.Do("a =: 10 20 30"); >> >> >> >> var a = (int[])_j.GetB("a"); >> >> Assert.AreEqual(10, a[0]); >> >> Assert.AreEqual(20, a[1]); >> >> Assert.AreEqual(30, a[2]); >> >> >> >> The result of 'a' is not '10 20 30', but '10 0 20'. I guess, '0' stands >> >> for the higher 32 bits of the whole value '10 0'. >> >> >> >> What can I do to resolve these issues? >> >> I can not switch to the 32 bit J version, because I work with JD, that >> >> requires a 64 bit J. >> >> My current workaround is avoiding integers and only work with floats, >> >>but >> >> this is not a real solution. >> >> >> >> Any Ideas? >> >> >> >> PS: Sorry for my English :) >> >> >> >>---------------------------------------------------------------------- >> >> For information about J forums see http://www.jsoftware.com/forums.htm >> >> >> >---------------------------------------------------------------------- >> >For information about J forums see http://www.jsoftware.com/forums.htm >> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm > > -- > regards, > ==================================================== > GPG key 1024D/4434BAB3 2008-08-24 > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 > gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
