#musicbrainz-devel

luks, can i ask u something? the little helper plugins? is it ok if they get included in script.py? :)

NXisGOD: which ones?

I think I'd prefer to not include any plugins by default

or if we include them, not make them enabled by default

alphachar and initials are 2 plugins that add 2 the functions in script.py

ive made my installer changes bundle plugins into installation itself, but it's disabled by default. it's useful for people who have no idea where to place plugins. plus my changes to the plugins page open the plugins folder, and open the web page to download plugins.

luks, hi

ijabz: hi

NXisGOD: I'm not sure what is alphachar, but initials just add a script function

In Search I'd like to replace UnaccentFilter with http://lucene.apache.org/java/2_9_0/api/all/org... it converts more characters and would be easier to manage , what do you think ?

that can be added directly to picard

ijabz: what characters for example?

\u1D0A

a type of J

well, I personally don't mind using anything

but if you want to replace it, be sure to go though old bug reports see if it can handle the characters

Ok, Ill take a look (i passes the existing tests anyway)

heh, I'd be impressed if anyone actually tries to use that particular character

would you be able to take a list of characters and output what it converts them to?

I mean... I can easily generate lists of characters, but I don't know easy it would be to get that to output what it converts it to

Its easily readable in the source code of ASCIIFoldingFilter

anyway, if you switch to ASCIIFoldingFilter I'll update the code to build the unaccent tables, so that we have identical functionality in the internal search

nikki svn checkout http://svn.apache.org/repos/asf/lucene/java/trunk lucene/java/trunk

thanks

direct link - http://svn.apache.org/repos/asf/lucene/java/tru...

I definitely don't know much about the JVM

but it's cool if it can optimize a huge switch like that

I wonder if normalisation stuff is slow...

'cause my first instinct would be to use one of the D forms and then just remove all the combining accents, rather than having so many thingies in the switch

that's what libunac does

I'll run some tests on index building to get a comparison of the two approaches

libunac (and UnaccentFilter) first tries to remove combining accents, then it does some text based replacements, and then has a hard-coded list of a few characters

it should be easy to run a report over the whole unicode, and list codepoints which are handled differently

Could do, I was thinking simple performance test first

I think correctness is more important then performance :)

both ways just replace characters based on a lookup table

you can rewrite them to be equally efficient

Performance was the issue a minute ago ... , could work out differences but doubt Id understand the results ;)

no, I didn't mean it's a problem

I was just wondering if JVM can really optimize stuff like that

I don't know thats why I was just going to run a test.

ijabz: that's why you'd show us the results :P I'm sure one of us would understand them

outsidecontext: ping

ruaok: hey

hi

I just caught up on this ticket: http://bugs.musicbrainz.org/ticket/5289

ok

the argument is that by fixing this bug picard could do better matching, which seems to be a number #1 request on uservoice.

do you agree with that?

mmh

I thought the biggest problem was users attaching puids to non-album tracks.

which then causes those tracks to be preferred.

we could then maybe do a combined PUID / existing metadata search

that makes sense.

I'm trying to figure out if this should happen before NGS.

unless this fix goes into 0.12 it doesn't really make sense.

but I think 0.12 is too far along to get this fix in, no?

it could improve those cases were a PUID is found on the wrong release (e.g. a compilation or different version). but we compare the metadata anyway on the results of the PUID query

i'm not that sure it would improve much

i think we should get a 0.12 soon because 0.11 still has some annoying bugs

I think the logic in picard should ALWAYS prefer album releases UNLESS the metadata matches perfectly for a non-album release.

then we should be prepared to make an update together with the NGS release if something breaks in the webservice

yes, i agree on that

I think that makes tons of sense.

ok, lets make a deal.

you take care of my suggestion for improved matching in picard.

I take care of the PUID filtering for NGS.

sound ok?

ok, deal

:-)

ruaok: will you be at the gsoc summit again this year?

yes

it's soon, right? end of this month?

1.5 weeks.

you should bring some chocolate for leslie and her team :)

I'm bringing Leslie a burrito as usual and I'll certainly pick up chocolate for the rest of the team.

Too bad its so $$$ to ship over. Otherwise it would be nice to have some better choco...

yes. but wou can get some at the summit in november

thats certainly the plan!

i can bring you some more frey supreme if you want

yes please!

just a random collection this time please.

ok. got enough of the vanilla?

yes.

another friend who also visited .ch brought a bunch over. I still have 6 or so...

:)

ok, i need some sleep. work is stealing all my time this week :(

ok, gute nacht!