lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Irwin <pir...@feature23.com>
Subject Re: Paul: why are we using sbyte?
Date Mon, 07 Apr 2014 22:03:56 GMT
There were a few spots where I added a byte[] version as well for
convenience, but not everywhere. And you have to use BlockCopy... you get
an exception if you try to Array.Copy a sbyte[] to byte[] or vice versa,
even though the storage in memory is virtually identical.

And feel free to use my code here for your project for porting Java to C#,
it does pascal casing and .NET naming conventions (I for interfaces, etc).
Uses Roslyn for C# generation. https://github.com/paulirwin/javatocsharp


On Mon, Apr 7, 2014 at 5:04 PM, Itamar Syn-Hershko <itamar@code972.com>wrote:

> I'm pretty sure there's no need to BlockCopy as the underlying binary
> representation is the same. I'm just wondering whether we should change
> this internally or find the places where it aches and provide a byte[] API
> as well
>
> I'm working on porting the tests now - I think we better have all tests
> ported and running (and passing) and then make this kind of decisions
>
> BTW it is now much easier to port tests, you basically copy-paste and
> almost everything works. I'm also working with a friend to do some Java to
> C# auto conversion, including camelCase to PascalCase by using Reflection.
>
> --
>
> Itamar Syn-Hershko
> http://code972.com | @synhershko <https://twitter.com/synhershko>
> Freelance Developer & Consultant
> Author of RavenDB in Action <http://manning.com/synhershko/>
>
>
> On Mon, Apr 7, 2014 at 11:49 PM, Paul Irwin <pirwin@feature23.com> wrote:
>
> > Hey Itamar,
> >
> > There was existing Lucene.net code that used sbyte, but one of the
> things I
> > ran into while porting is that Java was heavily using negative constants
> > for bytes since their bytes were signed. Also IIRC there were some
> > greater-than/less-than comparisons that would break if wrapped around to
> be
> > between 128 and 255. I tried going down the route of making everything
> byte
> > instead of sbyte but kept running into incompatibilities. It was easier
> --
> > and arguably more true to the Java code -- to keep it sbyte. Using
> > Buffer.BlockCopy instead of the Java-equivalent Array.Copy works to
> > transform the sbyte arrays to byte arrays.
> >
> > I'm open to any suggestions, and please by all means have at trying to
> > change it, but it became a royal pain and I got it to work with sbyte so
> I
> > didn't pursue the matter further.
> >
> > Paul
> >
> >
> > On Mon, Apr 7, 2014 at 4:41 PM, Itamar Syn-Hershko <itamar@code972.com
> > >wrote:
> >
> > > Hi Paul,
> > >
> > > Please refer to this commit:
> > >
> > >
> >
> https://github.com/apache/lucene.net/commit/8c23317c905d79823fd168ede778820439c8b163
> > >
> > > Why have you moved to using sbyte?
> > >
> > > I know this is one of the differences between Java and .NET, but we are
> > on
> > > .NET and should allow using byte.
> > >
> > > Having Field implementation to expect sbyte[] is almost useless as
> > > Encoding.GetEncoding(encoding).GetBytes(str); for example returns
> byte[].
> > >
> > > Can we change it back please so it uses byte everywhere, especially on
> > the
> > > public facing API?
> > >
> > > --
> > >
> > > Itamar Syn-Hershko
> > > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > > Freelance Developer & Consultant
> > > Author of RavenDB in Action <http://manning.com/synhershko/>
> > >
> >
> >
> >
> > --
> >
> > Paul Irwin
> > Lead Software Engineer
> > feature[23]
> >
> > Email: pirwin@feature23.com
> > Cell: 863-698-9294
> >
>



-- 

Paul Irwin
Lead Software Engineer
feature[23]

Email: pirwin@feature23.com
Cell: 863-698-9294

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message