
I guess 4k on Linux might cause some problems when you do fractional scaling

Sam and Paulo seem to have had good experience so I’ll take the plunge next payday.

I’d be interested in what make/model/os distribution when you get it all up and running.

This is one of several reasons why I don’t like Slack…

Good people of Slack: anyone here use the github API much? The v7.9 release is currently blocked on a really silly issue.

Specifically, the script that gathers our list of contributors is failing on repositories with more than 250 commits between two releases.

Specifically, it looks like the “compare” endpoint that we use, as in

<https://api.github.com/repos/racket/slideshow/compare/v7.8...cd03c785d740ce69991df7465f3caf861e712fd5?per_page=250;page=1>

… doesn’t actually support pagination. In fact, the docs more or less specify this:


… which contains this text: “The response will include a comparison of up to 250 commits. If you are working with a larger commit range, you can use the <https://developer.github.com/v3/repos/commits/#list-commits|List commits> to enumerate all commits in the range.”

I should specify that if you just change “page=1” to “page=2” in the query above… you appear to get the same 250 commits. Ah well.

Unfortunately, the “commits” endpoint that the documentation refers to … doesn’t seem to actually include the parameters necessary. It has a “sha” tag which is apparently used to specify the start of the … oh, that’s interesting. It says

“SHA or branch to start listing commits from. Default: the repository’s default branch (usually master
).”

The question is whether it lists forwards or backward from this point… Hmm… may have answered my own question, but not necessarily in a helpful way.

Anyhow, if anyone is in the “oh yeah, I use the GitHub API to fetch commit ranges all the time”, please let me know.

I have not used the GitHUB API to fetch commit ranges, but I do used to fetch multi-page pull requests. You cannot just append "?page=2" to the request for the second page, instead you need to look for the “Links” response header which will contain the links for the previous and next pages. For example, to fetch open pull requests on a repository, the endpoint is:
<http://github/api/v3/repos/USER/REPO/pulls>
but the pages endpoints are:
<http://github/api/v3/repositories/111/pulls?state=open&page=1>

I suspect pagination is done at a lower level, where the repository ID, 111 in my case, is used

Also note that the example above is from an internal Github installation, I don’t know what the endpoints look like for http://github.com\|github.com

hi, i need a package for parsing html, is there any available ?

@jbclements I think you can do this by making multiple queries
The first query is to obtain the sha
for the starting commit (newer). In your example, you have the sha already, so you don’t need this query
sha = cd03c785d740ce69991df7465f3caf861e712fd5
The second query is to obtain the sha
for the ending commit (older). E.g.,
https://api.github.com/repos/racket/slideshow/commits/v7.8
sha = f8eca38a2241f9895845ab4a2254aa5ba4d60343
The last query is to list commits starting from the starting sha:
https://api.github.com/repos/racket/slideshow/commits?sha=cd03c785d740ce69991df7465f3caf861e712fd5
And while you have not found the ending sha, keep looking for the link
field in the response header as @alexharsanyi said to obtain a new link to query for more.


ok, thanks, let me look into it

i’m trying to work on an html template where i can obtain some node elements, apply some placeholders,

https://docs.racket-lang.org/browser/index.html does it allow Js rendering ?

I don’t know but as far as I know it’s severely outdated, so I would guess no.

i’m looking for an ability to interact with the Js engine as well,

No, it doesn’t do js

Basically, I know of no useful things you can do with that library

Couldn’t you just use selenium or something similar?

If you have Firefox, https://docs.racket-lang.org/marionette/ is another possibility. See https://github.com/Bogdanp/marionette for examples.

ok thanks

Thanks @alexharsanyi… I’m now down the rabbit hole and I have a reasonable solution, but I’m probably doing much more than I should be; the bad moment was when I realized that of course commits could have more than one parent, and I should be following all paths back to the tagged commit. I think I have a fairly complete implementation of this tracing code, now, including 250-at-a-time buffering, but it’s really more code than this problem deserves.

Yep, that’s pretty much what I wound up doing, with the additional complication that commits may not be strictly linear. And also, github may not present them in an order that’s useful. Oog.