reagent / fleakr

A small, yet powerful, gem to interface with Flickr photostreams — Read more

Sort by: Priority | Votes | Last Updated

Loading…

1.

0 votes

Problems with set titles and other text fields
6 comments Created about 1 month ago by nighthwk1

Title

Body
For instance: >> sets[1] => #<Fleakr::Objects::Set:0x10210d940 @primary_photo_id="3729672314", @description="", @id="12345678901234567890", @count="33", @authentication_options={}, @title="", @document={elem <photoset farm="3" photos="33" videos="0" primary="3729672314" server="2437" id="12345678901234567890" secret="1234567890"> "\n\t\t" {elem <title> "Shake-a-spear" </title>} "\n\t\t" {emptyelem <description>} "\n\t" </photoset>}> As you can see, there is a title associated with the photo, but @title is empty. Maybe Flickr changed their API? I'm seeing similar issues with photo.url and possibly other fields as well.
or cancel
For instance:
```
>> sets[1]
=> #<Fleakr::Objects::Set:0x10210d940 @primary_photo_id="3729672314", @description="", @id="12345678901234567890", @count="33", @authentication_options={}, @title="", @document={elem <photoset farm="3" photos="33" videos="0" primary="3729672314" server="2437" id="12345678901234567890" secret="1234567890"> "\n\t\t" {elem <title> "Shake-a-spear" </title>} "\n\t\t" {emptyelem <description>} "\n\t" </photoset>}>
```
As you can see, there is a title associated with the photo, but @title is empty. Maybe Flickr changed their API? I'm seeing similar issues with photo.url and possibly other fields as well.
Comments
reagent Wed Nov 25 11:34:07 -0800 2009 | link

Can you give me some more context around this error? How did you do the assignment to sets? Is it happening with other sets?

Comment
Can you give me some more context around this error? How did you do the assignment to sets? Is it happening with other sets?
or cancel
nighthwk1 Wed Nov 25 11:57:15 -0800 2009 | link
Ok, here's a more complete example:

require "rubygems" require "fleakr" Fleakr.api_key = '12345678901234567890123456789012' user = Fleakr.user('my_user_name') user.sets.each do |set| puts set.title end

I get nothing. I've tried it with another account as well (and both definitely have sets with titles).
Comment
Ok, here's a more complete example: require "rubygems" require "fleakr" Fleakr.api_key = '12345678901234567890123456789012' user = Fleakr.user('my_user_name') user.sets.each do |set| puts set.title end I get nothing. I've tried it with another account as well (and both definitely have sets with titles).
or cancel
nighthwk1 Wed Nov 25 18:57:46 -0800 2009 | link

I've looked around on some other sites, and hpricot 0.8.2 is broken.
Hpricot 0.8.1 works with Fleakr.

Comment
I've looked around on some other sites, and hpricot 0.8.2 is broken. Hpricot 0.8.1 works with Fleakr.
or cancel

reagent Thu Nov 26 04:07:05 -0800 2009 | link

Thanks for figuring that out - I'd like to get Fleakr working with 0.8.2 since the only thing keeping me in the 0.6.x series is JRuby compatibility (which appears to be fixed in 0.8.2). I'll open a separate issue for this.

Comment
Thanks for figuring that out - I'd like to get Fleakr working with 0.8.2 since the only thing keeping me in the 0.6.x series is JRuby compatibility (which appears to be fixed in 0.8.2). I'll open a separate issue for this.
or cancel

reagent Thu Nov 26 04:36:16 -0800 2009 | link

I added issue #2 to track this - if you have the time and interest in working on this, let me know.

Comment
I added issue #2 to track this - if you have the time and interest in working on this, let me know.
or cancel

reagent Tue Dec 08 05:01:28 -0800 2009 | link

Another github user submitted a patch - the fix is in 0.6.2

Comment
Another github user submitted a patch - the fix is in 0.6.2
or cancel

Parsed with GitHub Flavored Markdown
2.

0 votes

bug
x

compatibility
x

Get Fleakr working with Hpricot 0.8.2
1 comment Created about 1 month ago by reagent

Title

Body
Extraction of set titles and other details fails with the newest version of Hpricot, this should be fixed to be compatible with 0.8.2 (and likely change the dependency in the gemspec). See the discussion in issue #1.
or cancel

Extraction of set titles and other details fails with the newest version of Hpricot, this should be fixed to be compatible with 0.8.2 (and likely change the dependency in the gemspec). See the discussion in issue #1.

Comments

reagent Sun Dec 06 18:03:12 -0800 2009 | link

This commit fixes the compatibility issue. Official release is version 0.6.2 and will be available from gemcutter shortly.

Comment
[This commit](http://github.com/reagent/fleakr/commit/6a47b51376cb982b939b43246d8e2ea0d5022cb6) fixes the compatibility issue. Official release is version 0.6.2 and will be available from gemcutter shortly.
or cancel

Parsed with GitHub Flavored Markdown
6.

0 votes

fleakr <= 0.6.2 and ActiveSupport 2.3.5 incompatible
7 comments Created 27 days ago by base10

Title

Body
With fleakr 0.5.1 and 0.6.2, I run into the following error trying to require fleakr in a script: /Library/Ruby/Gems/1.8/gems/activesupport-2.3.5/lib/active_support/core_ext/blank.rb:2: uninitialized constant ActiveSupport::Deprecation (NameError) It appears that in ActiveSupport 2.3.5, active_support/core_ext/blank was deprecated for active_support/core_ext/object/blank. active_support/core_ext/blank requires active_support/core_ext/object/blank, but without including active_support/deprecation and its dependencies, no dice. I created a diff ( http://gist.github.com/250636 ), but this would raise your dependencies from ActiveSupport 2.0 to 2.3.5 specifically. Thank you, Nathan nwalls <at> ismedia -dot- org
or cancel

With fleakr 0.5.1 and 0.6.2, I run into the following error trying to require fleakr in a script:

/Library/Ruby/Gems/1.8/gems/activesupport-2.3.5/lib/active_support/core_ext/blank.rb:2: uninitialized constant ActiveSupport::Deprecation (NameError)

It appears that in ActiveSupport 2.3.5, active_support/core_ext/blank was deprecated for active_support/core_ext/object/blank. active_support/core_ext/blank requires active_support/core_ext/object/blank, but without including active_support/deprecation and its dependencies, no dice.

I created a diff ( http://gist.github.com/250636 ), but this would raise your dependencies from ActiveSupport 2.0 to 2.3.5 specifically.

Thank you,

Nathan
nwalls ismedia -dot- org

Comments

reagent Mon Dec 07 05:34:17 -0800 2009 | link

I think the real solution here is to get rid of the dependency on ActiveSupport entirely. There are only a couple places that I'm using it, and even then, it was just used as a quick addition to get the features I wanted.

In the meantime, it might be possible to wrap the requre in a begin ... rescue block to handle both 2.0.x and 2.3.5

Comment
I think the real solution here is to get rid of the dependency on ActiveSupport entirely. There are only a couple places that I'm using it, and even then, it was just used as a quick addition to get the features I wanted. In the meantime, it might be possible to wrap the requre in a begin ... rescue block to handle both 2.0.x and 2.3.5
or cancel

base10 Mon Dec 07 19:03:43 -0800 2009 | link

That's certainly a lot more flexible than my "found after midnight" suggestion. Cheers.

Comment
That's certainly a lot more flexible than my "found after midnight" suggestion. Cheers.
or cancel

reagent Thu Dec 10 09:21:28 -0800 2009 | link

I have yet to do this, but I would need you to test it for me anyway. Would you be able to fork, commit, and test? Then I can pull your change and push out 0.6.3

let me know.

Comment
I have yet to do this, but I would need you to test it for me anyway. Would you be able to fork, commit, and test? Then I can pull your change and push out 0.6.3 let me know.
or cancel

base10 Thu Dec 17 06:15:02 -0800 2009 | link

Sorry for the long delay, but I've pushed e77b4e0 in my fork to add a begin/rescue block. However, I'm currently unable to get the tests to run since it seems Test::Unit isn't thrilled with NameError. I spotted that last night and haven't had time to dig into it much.

Comment
Sorry for the long delay, but I've pushed e77b4e0ffce85d374f97e71cdbe3d451ded93e6e in my fork to add a begin/rescue block. However, I'm currently unable to get the tests to run since it seems Test::Unit isn't thrilled with NameError. I spotted that last night and haven't had time to dig into it much.
or cancel

reagent Fri Dec 18 08:02:20 -0800 2009 | link

Thanks for doing this - I'll pull it in tonight / tomorrow and get out a new version. I'm not too concerned with tests for this since I'm planning to rip out AS entirely.

Comment
Thanks for doing this - I'll pull it in tonight / tomorrow and get out a new version. I'm not too concerned with tests for this since I'm planning to rip out AS entirely.
or cancel

base10 Fri Dec 18 08:56:10 -0800 2009 | link

Glad to do it. I greatly appreciate having fleakr available. Cheers.

Comment
Glad to do it. I greatly appreciate having fleakr available. Cheers.
or cancel

reagent Mon Dec 28 04:39:43 -0800 2009 | link

Applied (finally) and released as 0.6.3 - thanks!

Comment
Applied (finally) and released as 0.6.3 - thanks!
or cancel

Parsed with GitHub Flavored Markdown
3.

0 votes

performance
x

Pass extra options through when getting public photos for a user
0 comments Created about 1 month ago by reagent

Title

Body
When calling people.getPublicPhotos, there are some additional options that can be passed (namely the URLs to the images). The call to getting these photos should always use the relevant extra parameters as documented in the [API documentation](http://www.flickr.com/services/api/flickr.people.getPublicPhotos.html) Related: Issue #4
or cancel

When calling people.getPublicPhotos, there are some additional options that can be passed (namely the URLs to the images). The call to getting these photos should always use the relevant extra parameters as documented in the API documentation

Related: Issue #4

Comments

Parsed with GitHub Flavored Markdown
4.

0 votes

performance
x

Pass extra options when searching photos
0 comments Created about 1 month ago by reagent

Title

Body
Photo search has options similar to those when getting public photos for a user (see the [documentation](http://www.flickr.com/services/api/flickr.photos.search.html)). The library should pass the relevant options (e.g. image URLs) through instead of making separate API calls to find this information. Related: Issue #3
or cancel

Photo search has options similar to those when getting public photos for a user (see the documentation). The library should pass the relevant options (e.g. image URLs) through instead of making separate API calls to find this information.

Related: Issue #3

Comments

Parsed with GitHub Flavored Markdown
5.

0 votes

performance
x

Image URLs should be constructed by their attributes when possible
0 comments Created about 1 month ago by reagent

Title

Body
When there is information available for a photo, this should be used to construct the image URL instead of making an API call. See the [URL documentation](http://www.flickr.com/services/api/misc.urls.html) for examples on how to construct the Photo Source URLs. This is related to issues #3 and #4 - this might make sense to tackle first.
or cancel

When there is information available for a photo, this should be used to construct the image URL instead of making an API call. See the URL documentation for examples on how to construct the Photo Source URLs.

This is related to issues #3 and #4 - this might make sense to tackle first.

Comments

Parsed with GitHub Flavored Markdown
7.

0 votes

Support favorites
0 comments Created 1 day ago by stilist

Title

Body
* `favorites.getPublicList` [(docs)](http://www.flickr.com/services/api/flickr.favorites.getPublicList.html): User’s publicly-accessible favorites. * `favorites.getList` [(docs)](http://www.flickr.com/services/api/flickr.favorites.getList.html): Full list of a user’s favorites, including non-public ones. `r` * `favorites.add` [(docs)](http://www.flickr.com/services/api/flickr.favorites.add.html): Add a photo to user’s favorites. `w+` * `favorites.remove` [(docs)](http://www.flickr.com/services/api/flickr.favorites.remove.html): Remove photo from user’s favorites. `w+` * * * `getList` and `getPublicList` accept `per_page` (`0..500`; default `100`) and `page` (*n*; default `1`) parameters for use with large collections of favorites. The `<photos>` element of the XML response includes a `pages` attribute indicating how many calls are needed to collect all the favorites for the given `per_page`, as well as a `total` attribute that states how many favorites the user has. For the user’s convenience, I suggest an optional argument along the lines of `n_favorites` that will automatically make the required number of calls and assemble a unified list. (A more complicated but full-featured alternative would be `start` and `end` arguments.)
or cancel
- favorites.getPublicList (docs): User’s publicly-accessible favorites.
- favorites.getList (docs): Full list of a user’s favorites, including non-public ones. r
- favorites.add (docs): Add a photo to user’s favorites. w+
- favorites.remove (docs): Remove photo from user’s favorites. w+
getList and getPublicList accept per_page (0..500; default 100) and page (n; default 1) parameters for use with large collections of favorites. The <photos> element of the XML response includes a pages attribute indicating how many calls are needed to collect all the favorites for the given per_page, as well as a total attribute that states how many favorites the user has.

For the user’s convenience, I suggest an optional argument along the lines of n_favorites that will automatically make the required number of calls and assemble a unified list. (A more complicated but full-featured alternative would be start and end arguments.)
Comments

Parsed with GitHub Flavored Markdown