#musicbrainz

and so -lc++ doesn't get added to the link path by default

[Global Notice] Hi all. We'll open things back up presently.

dvtoo: yes, you're right.

But the build system should be taking care of that.

nod

Its builds from the tarball, so I'm suspecting a libtool/automake issue

well, when I build from cvs, it's linking it with gcc also

and no clue why it works

what's really odd is that at one point, it didn't, but now it does, and I don't have any idea why

boon (~boon@eta.cis.ohio-state.edu) has joined #musicbrainz

robla (~robla@209.210.138.240) has joined #musicbrainz

arnowa_ (~chatzilla@pD9E81D21.dip.t-dialin.net) has joined #musicbrainz

brb

yalaforge (~matthias@krl9-d9bb4d9a.pool.mediaWays.net) has joined #musicbrainz

ruaok (~robert@adsl-63-201-0-114.dsl.snlo01.pacbell.net) has joined #musicbrainz

ruaok: is it planned to keep the win32 tagger, or replace it eventually? ie, is there any point in me bothering to hack new stuff into it?

was thinking it'd be nice to at least have various artist rename patterns like tp_tagger has

dvtoo: the plan is to plug lbtp into mb_tagger.

I'm hoping to start work on that this afternoon.

nod, but making other unrelated changes to mb_tagger would be worthwhile?

that is to tide people over until I can hack up a new cross platform tagger

nod =)

I plan to expose all the new features in libtp in mb_tagger

I know a few people that'd use it in a heartbeat if there was a OSX client

ok, great =)

dvtoo: I know more than a few. :-)

An OSX tagger even has a $500 bounty on it. :-)

hah, nice =)

These are all steps towards that.

is the plan to write multiple front ends, or use something like wxwindows that's crossplatform?

the latter.

wxPython to be exact.

nice =)

ah, nod

isn't gtk cross-plattform?

think the win32 port relies on cygwin, no?

I don't know. Didn't use windows recently

no

what a shame :-(

Besides I don't want to write a UI BY HAND in C. Screw that.

I played a bit with it and I liked it

heh, yeah, can't blame you =)

hehe

I'll have to do that sooner or earlier. It's quite a challenge ;-)

real_ (real@h65-222-106-121.fl.shawcable.net) has joined #musicbrainz

eikeon (~eikeon@jungle.ne.client2.attbi.com) has joined #musicbrainz

kyleb|bed (~kyle@dhcp065-024-013-066.columbus.rr.com) has joined #musicbrainz

eikeon (~eikeon@jungle.ne.client2.attbi.com) has joined #musicbrainz

kyleb|bed (~kyle@dhcp065-024-013-066.columbus.rr.com) has joined #musicbrainz

ruaok (~robert@adsl-63-201-0-114.dsl.snlo01.pacbell.net) has joined #musicbrainz

djce: did upgrading libtool/automake help?

still doing it...

I've been out for a couple of hours

and I've just noticed that /usr/bin precedes /usr/local/bin in my PATH, which was unexpected.

oops.

success! I am now the proud owner of an up-to-date copy of libtp.

thanks!

Excellent!

Now does rs_Delete confuse you less??

It seems to not crash anymore. :-)

I'm just checking the diffs now and updating the bindings...

rs_Delete seems happier.

About the change to tr_GetResults (whereby numResults is now an in/out parameter)...

unless you deliberately pass in number-expected + 1, you still can't tell the the difference between returned (because array full) and returned (because no more data).

But that is what the tr_GetNumResults call is for.

Call that and then you know...

Yes, but..

is there 0% chance of the list changing size between the calls?

Yes.

ok

That is if you are calling this function when the file is in a user input state.

If the file is not in a user input state, the caller should not be calling that function

ok, fair enough.

Yes, before you access anything with the tr_* functions you need to lock the track first.

And that actually garantees that the data won't change.

ok. One more thing then...

was the bit about changing tp_ReleaseTrack impractical?

to only require a track_t argument?

nasty circular references, like Perl, I suspect...

because the tunepimp_t object is doing reference counting.

tracks dont get deleted until all references to the track have been released.

And tunepimp is in charge of that, not the track.

Hmm... so is it the case that every tp_GetTrack should be matched by a tp_ReleaseTrack?

Yes, its imperative.

Otherwise tracks will never get deleted from memory.

Sorry to interrupt you, but ...

uh oh....

:-)

I've got 10000 mods!!! :-)

Yeay!

congrats!

thanks. now i can leave town

oh, yalaforge, btw:

off to hotel mom?

yes :-)

"Winter" for the lyrics, but "Leather" for the music.

djce: cool. "Me And A Gun" for lyrics. "Tear In Your Hand" for music

although "me and a gun" is quite shocking, I think

Only listened to it twice so far... a few more times won't hurt.

ruaok: It's about album http://www.musicbrainz.org/showalbum.html?album...

ok, I'll be away for about 3 weeks. But still get my mail, I hope.

see - consistent metadata enabling conversations about music :-)

Hah!

:-)

ruaok: I'll have plenty of time to document and play with tunepimp

crucify is my fave.

Cool!

Yes, I like that one, too.

Though right around the time you get back I will be in the desert..

Wow. That's coming up fast, eh?

I'm thinking about blogging my experiences this year.

23 days.

ruaok: that'll be interesting to read

There are many things left to be done.

Keep your eye peeled on my blog.

I'll take my beater laptop and cruise around the playa with it.

No water. No food. No stores.

Just porta potties and 802.11b with a satellite feed.

sounds interesting

The bare necessities.

except for the 'no water, no food, no stores' part ;-)

And lots of crazy people. With crazy outfits.

And crazy cars. (like ours)

And crazy amounts of fire.

I need streets under my feet

Overcoming adversity in triplicate.

We have street. I'll be camping at Dogma and cross street ridiculous.

Dogma / 7:30.

We have snail mail service.

Wanna send me a postcard? :-)

postcard, why not

is you address published somewhere?

I'll retaliate.

Hmmmm. Lemme look for the proper zip code.