#musicbrainz

/

      • nikki
        much better than my 4-nested-subqueries monstrosity :D
      • luks
        max(id) is cheating, technically
      • aCiD2 was going to say that :P
      • but we don't reuse ids, so it should work
      • nikki
        I was already trying to use max(id) anyway :)
      • mezood
        mezood is now known as mezod
      • intgr
        Does anyone know if what I want is doable with Lucene?
      • luks
        intgr: yes, it's definitely doable
      • probably a little too expensive with the current design of the search server
      • intgr
        Do you need to add new indexes for that though?
      • luks
        no
      • intgr
        Ah ok
      • ./c
      • luks
        you can search on multiple fields
      • intgr
        Or go a step further and implement "free form search" that can search for any object.
      • luks
        even give them different weights
      • yeah, that's what I intend to do eventually
      • intgr
        I might have the time to hack on MB now; dunno if I can overcome my "inertia" though. :)
      • Cool
      • aCiD2
        intgr: get over it!
      • we need more hackers :D
      • luks
        the search server design right now is not exactly "scalable"
      • we use different index for every search type
      • intgr
        Well, you just pop up more boxes if you want to scale, no?
      • luks
        yes, but to add a new search you have to add a new index
      • intgr
        Ah
      • luks
        much of the data could be shared between indexes
      • I'm sure lucene takes that into account
      • but when they are on different indexes, it can't do anything
      • intgr
        Ah ok
      • luks
        so the "free form search" could be technically faster
      • intgr
        Another question I have; what does the Qt threadpool stuff do in Picard's OFA scan code? It sure as hell isn't parallelizing fingerprinting.
      • luks
        there is only one fingerprinting thread
      • that's a limitation of libofa
      • intgr
        I was thinking of parallelizing it (as I bought a new shiny computer recently ;) but didn't dare to touch it.
      • Screw threads, use processes.
      • subprocess is portable enough
      • Probably more portable than libofa anyway.
      • aCiD2
        pronik`: let me know when you get back
      • luks
        I have some code written for using processes
      • never finished it though
      • intgr
        Ok
      • So it's fine if I rip out the threadpool code?
      • luks
        well, it's used for other things too
      • intgr
        Hmm
      • Ah I see.
      • luks
        moving all of to a subprocess would be much better
      • and having configurable number of fingeprinting processes
      • intgr
        Yeah
      • So I would start with botching picard.util.queue.Queue?
      • Or do you want to have the other queues as threads?
      • luks
        you still need queues
      • I'm not sure if picard.util.queue.Queue does something special right now though
      • intgr
        By "botching" I meant "changing"
      • Looks like a wrapper to me
      • luks
        well, I'd start by writing the subprocess
      • intgr
        Scratch everything; where's your subprocess code?
      • I'll see what you did there
      • luks
        one moment, I'll try to find it
      • intgr
        Just wondering, how do you feel about hg given that Picard uses bzr?
      • luks
        I've never used it much
      • aCiD2
        Nice, Wall Street Journal want to do an article including MusicBrainz :)
      • intgr
        :)
      • aCiD2
        I think I'll leave that phone call to rob though :)
      • luks
        if you want my general opinion on DVCS then: bzr ~ git > hg
      • I don't see any advantage of using hg
      • (over bzr)
      • intgr
        What advantage do you see in bzr over hg?
      • aCiD2
        I like Mercurial, that was my first DVCS
      • but now I wouldn't use anything but Git, heh
      • luks
        well, first of all I have my tools for bzr
      • intgr
        Fair enough
      • luks
        hg seems like a mix of different ideas to me
      • I've started using bzr when it was the only dvcs usable on windows
      • intgr
        How do you mean "a mix"?
      • luks
        the definition of branch and repository in hg is very weird
      • aCiD2
        Huh, I just realised I can write our merge functions with less duplication by making use of the fact that aliases/annotations are roles
      • before 'merge' => sub { $self->merge_aliases() } seems good
      • cyberpear joined the channel
      • intgr
        luks: Never really used named branches in hg; I'm afraid of branching in git as I was with svn ;)
      • aCiD2
        I couldn't live without local branches anymore
      • intgr
        But I haven't used git much tbh.
      • aCiD2
        Especially not now we do code reviews at musicbrainz
      • luks
        I'm using bzr the git way
      • intgr
        I use mq for most of my still-in-churn development.
      • luks
        so I have a number of branches without trees (since branches are directories in bzr)
      • aCiD2 never liked that
      • use a single working tree, and switch between those branches
      • aCiD2: I can use tab completion for branch names, can you? :)
      • aCiD2
        Yup :)
      • luks
        cool
      • aCiD2
        git-bash.sh :D
      • it shows which branch i'm on in PS1 too, which is handy
      • intgr
        Anyway enough about version control masturbation. :)
      • aCiD2
        it's been discussed to death here :P
      • but I'm glad we finally have a system that lets anyone use what they want
      • intgr
        Heh, it's the hot topic these days.
      • luks
        intgr: well, I can't find the code
      • intgr
        hg-git <3
      • luks
        but there wasn't much anyway
      • intgr
        luks: What's the right approach to this?
      • Do something like pp does -- send pickled input to subprocess and get pickled results?
      • luks
        yes
      • intgr
        Do you want to keep the HTTP queues as threads? (which makes more sense to me)
      • luks
        the transport layer should be QProcess, ideally
      • cyberpear has quit
      • because it allows async calls
      • HTTP queues are not threads, are they?
      • but HTTP should be rewritten in QNetworkAccessManager anyway
      • intgr
        Ah they aren't?
      • I see
      • luks
        the way I personally see it working is that the fingerprinting subprocess will respont to two requests
      • hm
      • actually only one
      • you give it a file name, it decodes it, calculates the fingerprint and returns the result
      • intgr
        Right.
      • luks
        once you have the fingerprint, you will do HTTP lookups
      • nothing changes there
      • intgr
        Yeah
      • What's load_queue, save_queue and other_queue?
      • Reading/writing files?
      • cyberpear joined the channel
      • luks
        yep
      • other_queue is for CD lookups and directory listing
      • intgr
        Right, that shouldn't be parallelized I guess.
      • luks
        yes
      • cyberpea1 has quit
      • nikki has quit
      • intgr
        luks: Any source code hosts besides Sourceforge and Launchpad that support bzr?
      • luks
        Savannah, and standard web hosting
      • *any
      • google code is a huge plus for hg
      • but then, hosting bzr on a svn server is trivial :)
      • intgr
        Google Code is pretty pale compared to Bitbucket IMO
      • aCiD2
        luks: I thought about the work we're doing merging edit_* tables
      • luks
        I don't know, I somehow never liked Bitbucket and Github
      • aCiD2
        surely that's not quite enough, wouldn't we need to actually update the entity ids in the edit as well?
      • intgr
        I don't like Github either.
      • Nor Launchpad
      • luks
        aCiD2: well, that's questionable
      • aCiD2
        Ie, I enter an edit artist edit for artist id = 5, then merge artist 5 into artist 4. Now artist 4 has an edit_artist pointing to an edit on artist 5, which no longer exists
      • luks
        aCiD2: but I'd consider it historical information
      • aCiD2
        so it doesn't really make any sense
      • intgr
        The other day I just spent 10 minutes figuring out how can I list the bugs I've opened on launchpad. Then spent 10 minutes figuring out how to navigate back to the place where I can report a bug :(
      • luks
        that's what the current code does
      • and it's really confusing
      • aCiD2
        lol
      • hrm
      • luks
        I don't know
      • but "Merge artist: A and A" seem strange to me