lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Paldino <>
Subject Re: Windows RT / WP8 Version
Date Wed, 21 Aug 2013 15:33:49 GMT
Apologies if this has been brought up, but I don't seem to see it.

Regarding windows RT: all synchronous calls that are IO blocking are not available on windows

Last I checked, Lucene.NET used synchronous calls to access streams.

If you were going yo convert this to windows RT you'd have to change the sync calls to async
and propagate them all the way up through all the method calls which will most definitely
have a drastic effect on the results (you also can't block waiting for a result anywhere,
everything is a continuation).

That said, how exactly are you going to convert this for windows RT?  Granted, I'd love to
see the entire code base take async into account, as there's no good reason to block waiting
on IO anymore, but it doesn't seem feasible given the groups dependency on line for line translations
of the java code.

- Nick

On Aug 21, 2013, at 10:33 AM, "Paul Irwin" <> wrote:

> FWIW, Here are the results of the Xamarin Mobility Scanner of the
> 4.3.1 code in my fork.
> While it says 90-99% compatibility, there are some very difficult
> refactorings to make it support Windows Phone and Windows 8/RT. As for iOS
> and Android, it looks pretty easy -- we just need to remove the references
> to ConfigurationManager.AppSettings and it should work (according to the
> Xamarin scanner) without making it a PCL.
> On Wed, Aug 21, 2013 at 10:13 AM, Itamar Syn-Hershko <>wrote:
>> I'm with Paul on this
>> On Wed, Aug 21, 2013 at 10:11 AM, Paul Irwin <> wrote:
>>> I appreciate the idea of having it portable, but after going through most
>>> of the code myself with catching it up to 4.3 (still much work to be
>> done),
>>> I can attest that it would be exceptionally difficult if not impossible
>> to
>>> maintain an even partial port to PCL in the same codebase. Take a look at
>>> the Util.FST classes, or the Util.Packed classes, or any of the Codecs in
>>> 4.x to see what I'm talking about. I do not want to see get
>>> stuck in the dark ages due to trying to achieve PCL compatibility.
>>> If anyone is passionate about having a partial port of Lucene core to PCL
>>> (because I do not believe you can achieve a full port), I suggest
>> spinning
>>> off a new project or keeping the source completely separate rather than
>>> filling the code with a bunch of #if statements and thus
>> making
>>> it much more difficult for us to do line-by-line updates of the Java code
>>> in the future.
>>> On Wed, Aug 21, 2013 at 3:45 AM, Christopher Currens <
>>>> wrote:
>>>> Prescott,
>>>> You're right in regards to PCL and MonoTouch.  I have no idea what I
>> was
>>>> thinking.  I seem to recall a year or so ago when you ran into that
>>> issue.
>>>> I believe WP8 supports unsigned value types, so it may not be an issue
>>> if
>>>> WP7 isn't explicitly supported.
>>>> Stefan,
>>>> I'm prepared for it being an arduous task.  Most of the challenges
>> you've
>>>> listed are addressed by using PCL, except for legacy technologies.
>> When
>>> it
>>>> comes to unsupported platforms, I think often times the only options is
>>> to
>>>> drop support for them when it comes to new code.  Like you mentioned,
>> we
>>>> don't really hit the support level that log4net does, we've already
>> made
>>>> the decision to not support .NET 3.5 in the 4.x versions of Lucene.
>>>> I still think my biggest blocker against PCL is that it's not in
>>>> Express....I'd like to keep support for Express editions instead of
>>>> potentially blocking people from contributing.
>>>> Thanks,
>>>> Christopher
>>>> On Tue, Aug 20, 2013 at 11:41 PM, Stefan Bodewig <>
>>>> wrote:
>>>>> On 2013-08-21, Christopher Currens wrote:
>>>>>> I've been thinking lately of doing a real push to have Lucene.Net
>>>> support
>>>>>> more platforms, specifically Windows RT and Windows Phone 8.  There
>>> are
>>>>> two
>>>>>> ways I can think of doing it, and each has its own specific
>>> advantages
>>>>> and
>>>>>> disadvantages.
>>>>> One thing I can tell you is that the release process can easily
>> become
>>> a
>>>>> PITA either way.  At least if you want to extend it to platforms VS
>>>>> cannot cross-compile to OOTB.
>>>>> I've been the release manager of the last log4net release and am
>>>>> preparing to cut a new one, so memory is fresh.  log4net uses NAnt to
>>>>> build and builds for several platforms from the same codebase with
>>>>> defines (NET_4_0 and so on) controlling code-paths that need specific
>>>>> platform or language features.
>>>>> For each additional platform you add the release manager must be able
>>> to
>>>>> build for it - no matter which approach you take.  This might be
>>> trivial
>>>>> for some platforms as VS supports them today but not for others (say
>>>>> MonoTouch) or no longer tomorrow (say you still want to support .NET
>>> 2.0
>>>>> when VS 2015 drops support for it).
>>>>> In log4net's case keeping around a virtual machine running XP that
>> can
>>>>> still build .NET 1.0 is the biggest hurdle.  As Lucene.NET doesn't
>>>>> strive to support old platforms as long as log4net does, this may not
>>> be
>>>>> as big of an issue.
>>>>> Of course we release sources, not binaries.  So you could say the RM
>>>>> only builds the stock .NET stuff and people who want to have a
>> version
>>>>> for MonoTouch should build them from source - or you have different
>>> team
>>>>> members contribute binaries for different platforms much like the
>> HTTPd
>>>>> project does.
>>>>> Stefan

View raw message