[kar]

in your google-code you seems final on using phobos, but in todo list i still see a Tango support, so any idea. and i also think phobos may be the best choice so far. im a D 1.0 fan, so hopefully youre not turning into D2.0

lastly, when can we expect at least a glance of the progress or initial codes.
(ops, sorry just found it on googlecode trunk, thanks for sharing)

P/S: this forum seems dead, can we just move to somewhere else.

[dw]

My ideas about Tango amount to this: I will port the code first to D/Phobos, then reevaluate the situation. There is no use case for Tango right now, but support would be desirable in the future. I just think that trying to add support for 2 standard libraries would be stupid, considering the code doesn't even fully build yet.

With regards to forums, yeah, they suck! However I am told that the dsource.org guys are working on a better solution. I tried asking to have the forums disabled, but that is even worse: this project then becomes "nonstandard" on dsource.org. Better to just stick with forums until dsource.org as a whole is migrated to a new system.

If you want to watch the forum, I set up a simple RSS feed for it below. It is suboptimal, but at least you can integrate it with your normal "browse web/mail" workflow.

http://feedrinse.com/services/rinse/?rinsedurl=b2d7fe40abf51a576d717f4a8e2e88a4
(thanks millar[]!)

Thanks,


David.
PS: I *will* be resuming work shortly! Day job is very busy right now.
_________________
-dw

[kar]

im a bit busy working on another project right now (image/motive retrieval database engine for fabric design) and hoping to catch up with you real soon (need to study your codes and stuffs).

i may not be of help right now, but i may be able to write some components/extensions for DLucene (analyzer,parser,..) later on.

thanks for the feed. it really help.

[larsivi]

I guess dw's "problem" on Tango is that we're at least a couple of persons interested in dlucene if it is Tango based

[kar]

[larsivi]

Yes, I have chatted with dw in private - I know his position.

[dw]

Something I don't think has been mentioned: in future, it may turn out that all Tango support needs is a few version{} in only a few files, particularly somewhere in dlucene/analysis (for string functions) and dlucene/store (for Conduit etc).

Once the code is running, and I can see if there are some refactorings/etc. that make sense to enhance cross-library portability, then that would be much more preferable to putting version{} everywhere thoughout the code now.

I've still no idea how much I want to deviate from Lucene. Kar seems interested in implementing a new index format, and I am interested at least in profiling/optimizing the I/O code. So there will be deviations, but if we start making "premature deviations" that result in too much confusion, then the entire project could become so little fun that I'll stop working on it.

Background: I started this project as an excercise in aesthetics and "computer joy" simply to show myself I still enjoyed coding, after leaving a job that made me feel like I hated computers. My opinion of programming in general still very much hangs on this code.

The upshot of this is: please don't pressure me into doing things, or attempt to dictate how the project should proceed. I am simply not interested, or even thinking about most of these issues much right now. The only reason I uploaded it at such an early stage is because people kept asking.

In any case, if the project starts to look like an ugly hack covered in version{} everywhere etc., then I am almost certain to lose interest in working on it. I want, no, I *need* this code to remain clean and simple and fun.

Thanks,


David.
_________________
-dw

[dw]

I keep forgetting things!!

The problem with doing any sort of refactoring now, is then there is no 1:1 mapping between Java, C#, and D code. That is not a problem unless trying to track down a bug - or simply work out where a chunk of code has gone (on some occasions, I have been a little too aggressive pruning code in a few files ).

Another problem with deviating too much, is that it becomes more difficult to inherit new Lucene features. For example, right now it should be fairly trivial to "sync" the D code to the Java code, simply by following Subversion commits/diffs to the Java repository. If I rename/refactor too much now, say, to make supporting multiple libraries easier, then this would be a lot more difficult.

In particular, Java Lucene has a few features of interest, for example, Payloads used for ranking.
_________________
-dw

[kar]

[kar]