From phw at rubyforge.org Mon Jun 4 19:00:58 2007 From: phw at rubyforge.org (Philipp Wolfer) Date: Tue, 5 Jun 2007 01:00:58 +0200 Subject: [Rbrainz-users] Ruby bindings for libdiscid In-Reply-To: References: Message-ID: Hello, just wanted to inform you that I released an Update for MB-DiscID after struggling with the MS compiler on Sunday. Still can't believe that the MS compiler is so stupid. However, I released version 0.1.1 which is now available as a pre-compiled library for Win32 as well. So if you like (and not already did) give it a try on Windows. The files are available for download on http://rubyforge.org/frs/?group_id=3677 and via RubyGems. Cheers, Philipp P.S.:It would be great if somebody with some Visual Studio experience could tell me, that the ugly, useless brackets I build into the source for MS compatibility are not really necessary ;-) Perhaps there is a better solution. From nigel at maven-group.org Wed Jun 6 11:33:14 2007 From: nigel at maven-group.org (Nigel Graham) Date: Wed, 06 Jun 2007 17:33:14 +0200 Subject: [Rbrainz-users] Do you need help. Message-ID: <4666D3BA.9070802@maven-group.org> Hej, I just found the project and it does much of the same that I have been working on by my self. So do you want some help?? I have actually allready written an unpublish Ruby port of the MusicBrainz WebService2 Python API and am currently working on ruby bindings for TunePimp. I was thinking of trying to compile a OS-X universal binary of MB-DiscID later tonight. Mvh. Nigel -------------- next part -------------- A non-text attachment was scrubbed... Name: nigel.vcf Type: text/x-vcard Size: 163 bytes Desc: not available Url : http://rubyforge.org/pipermail/rbrainz-users/attachments/20070606/dcfd77e5/attachment.vcf From nigel at maven-group.org Thu Jun 7 05:35:27 2007 From: nigel at maven-group.org (Nigel Graham) Date: Thu, 07 Jun 2007 11:35:27 +0200 Subject: [Rbrainz-users] Do you need help. In-Reply-To: References: <4666D3BA.9070802@maven-group.org> Message-ID: <4667D15F.3030605@maven-group.org> Philipp Wolfer wrote: > Hi Nigel, > > that sounds really interesting. Yes, I sure could use some help. I > think it would be a good idea if we would combine our efforts. > >> I have actually allready written an unpublish Ruby port of the >> MusicBrainz WebService2 Python API and am currently working on ruby >> bindings for TunePimp. > > If you like you could take a look at the current version of RBrainz in > Subversion (see http://rubyforge.org/scm/?group_id=3677) which support > querying collections as well. Maybe we can combine the two projects to > have the best of both. Even though RBrainz generally follows the > Python implementation there are some differences: My implementation follows the python implementation almost to the letter. I looked at yours and it differs alot more from the python one. Thats also why I think it would be easier if we just took your code and worked from that base. I do have some comments to your usage of 'is_a'. I personally prefer using duck typing instead. > 1. There is a own class MBID for MusicBrainz IDs As I mentioned earlier I am not such a big fan of using tests on the class type. I have attached a duck typing edition of MBID for you to look at and comment on. > 2. There is a class IncompleteDate to better support the date format > used by MusicBrainz I like that you have wrapped the incomplete dates. But I do have a suggestion. Based on previous experience with incomplete/partial dates I have found it usefull to consider them as time periods. This way of looking at them considerably lightens the burden of dealing with them with regards to other data types like Time and Date. Another advantage is that periods have a string of well defined operations that makes it so much easier to to do stuff like finding bands that were active from 1979 - 1999. > 3. Search results are returned in a own Collection object and not just > a plain array. This gives access to some additional features like the > result's score. > 4. The class to parse the XML is completely different > >> I was thinking of trying to compile a OS-X universal binary of MB-DiscID >> later tonight. > > Great, let me hear of the result. Currently MB-DiscID lacks a proper > rake task to build binary packages, but there is some rudimentary > support to automate Win32 package creation (take a look at the > Rakefile, you will see it). > By the way: I checked in some changes to MB-DiscID into the SVN the > last days, but there is not that much difference to the current > release (mainly support for the "put" method and a fix for a possible > core dump). The gem compiled and installed fine on my Mac. As for binary package generation it's a bit more challenging since Mac binaries come in 3 variants; PowerPC, Intel and fat universal binaries that contain one or more binaries in a single file. The problem with ruby extensions on mac are that they are of the same binary variant as the ruby version used to run rake and when doing binary distribution it's considered good practice to make universal binaries. Another problem is that Gem::Platform doesn't reflect this 3 binary system. Gem::Platform::DARWIN contains the string 'powerpc-darwin' which is only the right value for PowerPC binaries. > > I won't have much time the next 3 weeks, so don't expect much action > on the project in this time. When I'm back again I will prepare the > next releases of MB-DiscID and RBrainz. > > I would suggest we will talk about details when I'm fully available > again. I will read my mails in the meantime not very frequently, so it > will probably take some time until mails get answered. > > Cheers, > Phil -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mbid.rb Url: http://rubyforge.org/pipermail/rbrainz-users/attachments/20070607/94c1ff11/attachment.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: nigel.vcf Type: text/x-vcard Size: 163 bytes Desc: not available Url : http://rubyforge.org/pipermail/rbrainz-users/attachments/20070607/94c1ff11/attachment.vcf From phw at rubyforge.org Mon Jun 11 15:19:44 2007 From: phw at rubyforge.org (Philipp Wolfer) Date: Mon, 11 Jun 2007 21:19:44 +0200 Subject: [Rbrainz-users] Do you need help. In-Reply-To: <4667D15F.3030605@maven-group.org> References: <4666D3BA.9070802@maven-group.org> <4667D15F.3030605@maven-group.org> Message-ID: 2007/6/7, Nigel Graham : > As I mentioned earlier I am not such a big fan of using tests on the > class type. I have attached a duck typing edition of MBID for you to > look at and comment on. I'm still not completely used to "messing around in foreign namespaces", butI like your implementation very much. It cleanly solves the requirement to allow strings (or other representations of the ID) wherever it is convenient. I have a few comments about the various methods: We won't need "from_string" anymore, it is conceptual the same as "parse", which I like better. And I'm not sure about "from_uuid" and "from_uri" anymore. My original idea was to make it explicit what you are doing. But in many cases you don't know what you have anyway and you end up using "parse". So we could get rid of those two methods as well. Or maybe we could even offer only "new". What do you think? What I liked about the old code was the fact that the two use cases creating a MBID from an URI or a UUID were logical divided, now it's all in one method (initialize). Maybe we could split it up internally (from_uuid, from_uri, but private). One quick note about code style: I don't like long lines (I set the limit to 80 characters per line), so I normally use the post "if" or "unless" only in very short statements, even if the alternative uses 3 lines. > Based on previous experience with incomplete/partial dates I have found > it usefull to consider them as time periods. This way of looking at them > considerably lightens the burden of dealing with them with regards to > other data types like Time and Date. Another advantage is that periods > have a string of well defined operations that makes it so much easier to > to do stuff like finding bands that were active from 1979 - 1999. I'm not sure if I get your point here. Would it mean to store a begin and end date, e.g. "1988-08-01" and "1988-08-31" for the incomplete date "1988-08"? As far as I understand this is mainly a comparison problem. Isn't this basically solved by the current implementation of <=>? > Another problem is that Gem::Platform doesn't reflect this 3 binary > system. Gem::Platform::DARWIN contains the string 'powerpc-darwin' which > is only the right value for PowerPC binaries. That's a problem. Do you know how other projects solve this? If you have a Rubyforge login I would like to give you access to the project's SVN repository. You could checkin your MBID changes and integrate them properly. In the week beginning on June 25th we could then talk about our further project plans in detail and have a little chat about ourselves. Bye, Phil From nigel at maven-group.org Wed Jun 13 05:56:05 2007 From: nigel at maven-group.org (Nigel Graham) Date: Wed, 13 Jun 2007 11:56:05 +0200 Subject: [Rbrainz-users] Do you need help. In-Reply-To: References: <4666D3BA.9070802@maven-group.org> <4667D15F.3030605@maven-group.org> Message-ID: <466FBF35.90009@maven-group.org> Philipp Wolfer wrote: > 2007/6/7, Nigel Graham : > >> As I mentioned earlier I am not such a big fan of using tests on the >> class type. I have attached a duck typing edition of MBID for you to >> look at and comment on. >> > I'm still not completely used to "messing around in foreign > namespaces", butI like your implementation very much. It cleanly > solves the requirement to allow strings (or other representations of > the ID) wherever it is convenient. > > I have a few comments about the various methods: We won't need > "from_string" anymore, it is conceptual the same as "parse", which I > like better. And I'm not sure about "from_uuid" and "from_uri" > anymore. My original idea was to make it explicit what you are doing. > But in many cases you don't know what you have anyway and you end up > using "parse". So we could get rid of those two methods as well. Or > maybe we could even offer only "new". What do you think? > > What I liked about the old code was the fact that the two use cases > creating a MBID from an URI or a UUID were logical divided, now it's > all in one method (initialize). Maybe we could split it up internally > (from_uuid, from_uri, but private). > I have thought about it and I think that we should get rid of from_uri and from_uuid. The justification is that I think it's the most Ruby'esc approach and the one that most follows the paradigm of duck typing. What I mean by that is that it does a best effort to convert any argument into an MB ID. The only counter argument I could come up with was that the differentiation between the two use cases you describe is necessary to make a strict parser of some kind. > One quick note about code style: I don't like long lines (I set the > limit to 80 characters per line), so I normally use the post "if" or > "unless" only in very short statements, even if the alternative uses 3 > lines. > > Good point. I have changed the code I sent you to only use post "if" and "unless" when the line is shorter than 80 characters. >> Based on previous experience with incomplete/partial dates I have found >> it usefull to consider them as time periods. This way of looking at them >> considerably lightens the burden of dealing with them with regards to >> other data types like Time and Date. Another advantage is that periods >> have a string of well defined operations that makes it so much easier to >> to do stuff like finding bands that were active from 1979 - 1999. >> > I'm not sure if I get your point here. Would it mean to store a begin > and end date, e.g. "1988-08-01" and "1988-08-31" for the incomplete > date "1988-08"? > As far as I understand this is mainly a comparison problem. Isn't this > basically solved by the current implementation of <=>? > > I will try and explain it better. The problem is both one of comparison and of associations brought by the name. When you call something an incomplete date the expectation is for it to be a special kind of date. A date that is from a usability perspective a very good idea. The problem from a developer perspective is that you can't get it to act like a date. Mostly when dealing with comparisons. What I will try an convince you of is that an incomplete date is in fact a special kind of time period. Normal dates have the standard 3 comparisons; after / greater than, before / less than and equality. They suit all your needs and follow the rules of transitivity. For time periods and indeed incomplete dates these 3 operations aren't that useful (not if they are transitive). Instead time periods have 4 additional comparisons; starts, ends, overlaps and between. Your current implementation of <=> while not transitive works for a lot of use cases. But it is confusing to be using a <=> comparison to find what would be the following operation were it periods: a between b && b between a A case where it fails is: Given an array of release events, reX, find all release events that did not occur on 1979-03-15. reX.find_all{|e| e != IncompleteDate.new('1979-03-15')} # Wrong! What about incomplete date 1979?? What I am proposing is that we make IncompleteDate act as a period with at least the 7 operations and get rid of the ordering operator (<=>) since periods have no default ordering that makes much sense. That way it is up to the user of the gem to decide which comparison he wants to use. >> Another problem is that Gem::Platform doesn't reflect this 3 binary >> system. Gem::Platform::DARWIN contains the string 'powerpc-darwin' which >> is only the right value for PowerPC binaries. >> > That's a problem. Do you know how other projects solve this? > I think they simply don't distribute binary gems. Another problem with binary gems that depend on 3rd party libraries is that the library contains the path of the 3rd party library it depends on. On a mac this path is different depending on how you installed the 3rd party library. MacPorts install in /opt/local/lib and locally compiled binaries usually get installed in /usr/local/lib. > If you have a Rubyforge login I would like to give you access to the > project's SVN repository. You could checkin your MBID changes and > integrate them properly. In the week beginning on June 25th we could > then talk about our further project plans in detail and have a little > chat about ourselves. > My login is nigel_graham. And I'm looking forward to a more in-depth talk. Mvh. Nigel -------------- next part -------------- A non-text attachment was scrubbed... Name: nigel.vcf Type: text/x-vcard Size: 163 bytes Desc: not available Url : http://rubyforge.org/pipermail/rbrainz-users/attachments/20070613/34a6c59e/attachment.vcf From phw at rubyforge.org Thu Jun 14 14:28:14 2007 From: phw at rubyforge.org (Philipp Wolfer) Date: Thu, 14 Jun 2007 20:28:14 +0200 Subject: [Rbrainz-users] Do you need help. In-Reply-To: <466FBF35.90009@maven-group.org> References: <4666D3BA.9070802@maven-group.org> <4667D15F.3030605@maven-group.org> <466FBF35.90009@maven-group.org> Message-ID: Hi Nigel, I have given you access to the RBrainz project on Rubyforge. It would be great if you would checkin your current MBID implementation. Some notes about the project in Rubyforge: I have set up two additional private mailinglists. All SVN log messages are sent to rbrainz-svncheckins and rbrainz-devel is intended for developer discussions. At the moment I have the feeling the general rbrainz-user list is better suited for this, but maybe there is a need for an extra list in the future. A few notes on you last mail: 2007/6/13, Nigel Graham : > I have thought about it and I think that we should get rid of from_uri > and from_uuid. > The justification is that I think it's the most Ruby'esc approach and > the one that most follows the paradigm of duck typing. > What I mean by that is that it does a best effort to convert any > argument into an MB ID. Yes, that's how I see it as well. > The only counter argument I could come up with was that the > differentiation between the two use cases you describe is necessary to > make a strict parser of some kind. I don't think this will be a problem. As far as I see it your new implementation does a pretty good job in validating the arguments. > What I am proposing is that we make IncompleteDate act as a period with > at least the 7 operations and get rid of the ordering operator (<=>) > since periods have no default ordering that makes much sense. > That way it is up to the user of the gem to decide which comparison he > wants to use. Yes, now I see your point. I had actually thought about handling incomplete dates as periods before I wrote the current implementation. My idea back then was that incomplete days sometimes really are time periods, but often they refer to a specific date which is not exactly known. So you can't really say that 2007-08 starts before 2007-08-14 since 2007-08 could be as well referring to an unknown day after the 14th. That's why I came up with the implementation of <=>. But when I think about it know it really makes more problems than it solves. So I agree to remove <=> from IncompleteDate and instead add those 7 operations: - before? or < - after? or > - = - starts? - ends? - overlaps? - between? I think we should add before? and after? in addition to < and > (as aliases). Could make the code more readable and better suite the programming style of some people. > I think they simply don't distribute binary gems. Another problem with > binary gems that depend on 3rd party libraries is that the library > contains the path of the 3rd party library it depends on. On a mac this > path is different depending on how you installed the 3rd party library. > MacPorts install in /opt/local/lib and locally compiled binaries usually > get installed in /usr/local/lib. I've seen you have started the project OS-X Build. Will this deal with those problems? -- Philipp Wolfer