latest scala search version is not available

[Andrey Ilinykh]

I've just noticed that update site for scala search plugin has old version 0.2.3. I have to build  0.2.5 locally and then install it.

This plugin seems to be very useful.

Thank you,

  Andrey 

[Simon Schäfer]

On 11/16/2015 07:53 PM, Andrey Ilinykh wrote:

I've just noticed that update site for scala search plugin has old version 0.2.3. I have to build  0.2.5 locally and then install it.

This plugin seems to be very useful.

Which update site?

Thank you,

  Andrey 

--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/af08074d-72b3-48d6-b73a-45bfe638bd97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrey Ilinykh]

On Monday, November 16, 2015 at 11:18:09 AM UTC-8, Simon Schäfer wrote:

On 11/16/2015 07:53 PM, Andrey Ilinykh wrote:

I've just noticed that update site for scala search plugin has old version 0.2.3. I have to build  0.2.5 locally and then install it.

This plugin seems to be very useful.

Which update site?

http://scala-ide.dreamhosters.com/nightly-update-scala-search-scalaide-master-210/site/

this is what I see on github page 

[Simon Schäfer]

The README was outdated, I updated it. Thanks for reporting.

[iulian dragos]

Hey Andrey,

Yeah, it's super promising, but unfortunately we had to postpone making improvements.

A few things that I think would make the experience way better:

- symbol matching, right now, is based on Symbol Importers... an experimental feature in the Scala compiler that seems to be flaky at best. I think we need to rethink matching (fully qualified name + some logic to distinguish overloads).

- indexing should never interfere with other jobs (truly background). I remember I had to uninstall scala-search because it interfered too much with my typing (or was it building?).

thanks for picking this up!

iulian

--

You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/af08074d-72b3-48d6-b73a-45bfe638bd97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

[Simon Schäfer]

On Tuesday, November 17, 2015 at 8:30:37 AM UTC+1, Iulian Dragos wrote:

Hey Andrey,

Yeah, it's super promising, but unfortunately we had to postpone making improvements.

A few things that I think would make the experience way better:

- symbol matching, right now, is based on Symbol Importers... an experimental feature in the Scala compiler that seems to be flaky at best. I think we need to rethink matching (fully qualified name + some logic to distinguish overloads).

- indexing should never interfere with other jobs (truly background). I remember I had to uninstall scala-search because it interfered too much with my typing (or was it building?).

thanks for picking this up!

iulian

Andrey, in case you are planning to do more work here, it could be useful to check the work and even collaborate with the ensime people. They are rebuilding there own indexer right now and they moved away from Lucene completely. See this ticket: https://github.com/ensime/ensime-server/issues/1133

[Sam Halliday]

Nope, we are moving away from H2 completely :-) We're still using Lucene to build optimised human-searchable indices of the symbol names, but we're going to be storing everything in a graph database. Early tests have been fantastic and we're hoping to get lots of useful features out the other end.

[Andrey Ilinykh]

Sam,

 what do mean by "storing everything in a graph database"? Do you treat symbols as a Lucene documents and store them in database?

By the way, do you have any documentation describing architecture of ensime?

Thank you,

  Andrey

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/28a435e5-5030-40a8-8a0c-333f19932bcd%40googlegroups.com.

[Sam Halliday]

Architecture is it the link Simon posted. ENSIME in general see the Scala days talk.

We use Lucene for what it was designed for: indexing. We don't store documents/data in Lucene because it's a terrible document retrieval system (it is designed for reverse lookup, not document lookup). We only use it to discover primary keys in the DB. The data is stored in orientdb.