profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/torque/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

libass/libass 539

libass is a portable subtitle renderer for the ASS/SSA (Advanced Substation Alpha/Substation Alpha) subtitle format.

torque/mpv-progressbar 92

A simple progress bar for mpv.

torque/reki 3

A bittorrent tracker written in C, built on Redis and libuv.

torque/autosort_buffers 2

Weechat ruby script to automatically sort buffers.

torque/CandyCrisis 2

An old Puyo Puyo clone for OS X.

torque/Arduino-101-BLE-Demo 1

Electron + Arduino 101 + Bluetooth LE

torque/CGDraw 1

Adobe Illustrator → Swift/Obj-C CoreGraphics code.

torque/highlight 1

git-svn clone of http://sourceforge.net/projects/syntaxhighlight/

push eventtorque/fpdf2

torque

commit sha 970b2b5cf8b9d78fd6c10bc8d5c15b66cda28896

WIP: goodbye annotations. fpdf ostensibly supports python 3.6 which doesn't have from __future__ import annotations, so it's just easier to not deal with this.

view details

torque

commit sha d1af46f9edbdfd18fa5b0510b3a30f69cb0a6e86

clipping path and transform support. yeah holla. basic feature complete, now docs and tests.

view details

torque

commit sha 5d8af13f389f06d5629245ff08b1a49fc78aeb2b

simplify some edge cases and also fix auto path closing We can divine auto path closing from the path painting mode, which I think is perfectly acceptable. There are some annoying edge cases for handling path closing which are hopefully addressed now. The subpath concept is gone and instead move_to is provided, which should simplify programmatic path creation (e.g. in loops). The clipping path does some weird mojo to attach itself to the base graphics state as a style item. This makes it no longer order sensitive, and via some testing it appears that even in a nested graphics context it will eat any unpainted paths that came before it (this makes sense, since they will be interpreted as part of the clipping path, rather than whatever else).

view details

push time in 2 hours

create barnchtorque/fpdf2

branch : path-drawing

created branch time in 10 hours

fork torque/fpdf2

Simple PDF generation for Python

https://pyfpdf.github.io/fpdf2/

fork in 13 hours

push eventtorque/deqr-docs

torque

commit sha 52804cb26856b1d7dcdb1caf58e7d259cb804221

Commit torque/deqr@fff9cf1cec5a14688800723d0a022e8e6cdf8d86

view details

torque

commit sha 3e6736bb0ebb5aa4ce195980ddd7c738019f8b5a

Commit torque/deqr@0.2.0

view details

torque

commit sha 5011d701722f82a51408bde339954ccac6383e78

Commit torque/deqr@903f96c0a33b4a30e7c0c9965790e0f7aa0af41e

view details

push time in a month

push eventtorque/deqr-docs

torque

commit sha 527c9ebd38b9062fd8d3264987235e257d5a4f4e

Commit torque/deqr@903f96c0a33b4a30e7c0c9965790e0f7aa0af41e

view details

push time in a month

push eventtorque/deqr

torque

commit sha 903f96c0a33b4a30e7c0c9965790e0f7aa0af41e

CI: improvements to doc build. Store different symlinks for the release/dev documentation. `latest` will always point to the latest release version and `latest-dev` points to the latest version generated from the master branch. Since this workflow mucks around with the deqr-doc git repository, also change the concurrency setting so that it will not ever try to run two doc gen workflows in parallel.

view details

push time in a month

push eventtorque/deqr

torque

commit sha b84b371621db3c3f181bf2a0e53d54b93ffee3af

CI: fix use of poetry-dynamic-versioning. If only I had managed to read the documentation correctly before attempting to do a release. Ah, well, that would be boring. I was faked out by the docker environments and my local environment where this setup worked by nature of having poetry coexist next to poetry-dynamic-versioning. However, in the non-containerized CI jobs, poetry creates a venv for its deps. If I had been looking at the CI logs more carefully, I would have noticed something was awry, but who looks at success logs?

view details

torque

commit sha 5e4e9f1e174684f18ea22b871281c5e65dee0481

CI: improvements to doc build. Store different symlinks for the release/dev documentation. `latest` will always point to the latest release version and `latest-dev` points to the latest version generated from the master branch. Since this workflow mucks around with the deqr-doc git repository, also change the concurrency setting so that it will not ever try to run two doc gen workflows in parallel.

view details

push time in a month

push eventtorque/deqr-docs

torque

commit sha fda698a2224d67776bd0524181d158f8892dff20

Commit torque/deqr@${COMMIT_REF}

view details

push time in a month

push eventtorque/deqr

torque

commit sha 7690a24f5683908585aa1d4280981adace886826

CI: fix use of poetry-dynamic-versioning. If only I had managed to read the documentation correctly before attempting to do a release. Ah, well, that would be boring. I was faked out by the docker environments and my local environment where this setup worked by nature of having poetry coexist next to poetry-dynamic-versioning. However, in the non-containerized CI jobs, poetry creates a venv for its deps. If I had been looking at the CI logs more carefully, I would have noticed something was awry, but who looks at success logs?

view details

torque

commit sha a0bbf6f1662fcab58a8cc5ee605ab47788ed1e34

CI: improvements to doc build. Store different symlinks for the release/dev documentation. `latest` will always point to the latest release version and `latest-dev` points to the latest version generated from the master branch. Since this workflow mucks around with the deqr-doc git repository, also change the concurrency setting so that it will not ever try to run two doc gen workflows in parallel.

view details

push time in a month

push eventtorque/deqr-docs

torque

commit sha 15c3637aec36e4eea00e5a3e1badfad22578651d

Commit torque/deqr@c17daebb483e5405c00c856771e3f933b9e144ed

view details

push time in a month

push eventtorque/deqr

torque

commit sha c17daebb483e5405c00c856771e3f933b9e144ed

package: fix use of poetry-dynamic-versioning. If only I had managed to read the documentation correctly before attempting to do a release. Ah, well, that would be boring. I was faked out by the docker environments and my local environment where this setup worked by nature of having poetry coexist next to poetry-dynamic-versioning. However, in the non-containerized CI jobs, poetry creates a venv for its deps. If I had been looking at the CI logs more carefully, I would have noticed something was awry, but who looks at success logs?

view details

push time in a month

push eventtorque/deqr-docs

torque

commit sha 887b0a42e42e5bc10e7f8a58987a2affcf2e61a4

Commit torque/deqr@051ef702373964baa06870c7585d9abc61718044

view details

push time in a month

push eventtorque/deqr

torque

commit sha 051ef702373964baa06870c7585d9abc61718044

package: fix use of poetry-dynamic-versioning. If only I had managed to read the documentation correctly before attempting to do a release. Ah, well, that would be boring. I was faked out by the docker environments and my local environment where this setup worked by nature of having poetry coexist next to poetry-dynamic-versioning. However, in the non-containerized CI jobs, poetry creates a venv for its deps. If I had been looking at the CI logs more carefully, I would have noticed something was awry, but who looks at success logs?

view details

push time in a month

push eventtorque/deqr-docs

torque

commit sha db0b02f24dc033c13755db181a99dae0fe58d0db

Commit torque/deqr@fff9cf1cec5a14688800723d0a022e8e6cdf8d86

view details

push time in a month

created tagtorque/deqr

tag0.2.0

Simple QR code reader for Python

created time in a month

push eventtorque/deqr-docs

torque

commit sha 399dad6d5d0a3046df01dabf2845a5131bc02249

Commit torque/deqr@fff9cf1cec5a14688800723d0a022e8e6cdf8d86

view details

push time in a month

push eventtorque/deqr

torque

commit sha ea98900ce005b574bf94087f50e930b86802b34a

docs: flesh out the initial documentation. This includes improvements to getting started, including the use of images and example scripts, the API documentation, and

view details

torque

commit sha fff9cf1cec5a14688800723d0a022e8e6cdf8d86

deps: update quirc. This brings in some changes that theoretically improve decoding under certain circumstances.

view details

push time in a month

push eventtorque/deqr-docs

torque

commit sha 6941bd2268c8822d3b28b012d835e2fc3866042a

Commit torque/deqr@fa3f050bfb3568986fd64f5f7d4c3540f592f2e1

view details

push time in a month

push eventtorque/deqr

torque

commit sha a767e1575152224fc36abb7dc471e235fccfad04

docs: flesh out the initial documentation. This includes improvements to getting started, including the use of images and example scripts, the API documentation, and

view details

torque

commit sha fa3f050bfb3568986fd64f5f7d4c3540f592f2e1

deps: update quirc. This brings in some changes that theoretically improve decoding under certain circumstances.

view details

push time in a month

push eventtorque/deqr-docs

torque

commit sha 3b02840ed241ac5b475146910015ab4fdbb2a019

images: add basic demo images.

view details

push time in a month

push eventtorque/deqr-docs

torque

commit sha f538aa39b44af938dbc5dd88dbdb26372d2c7d6a

Commit torque/deqr@3d029c629a676195e890d58664d24e13c7f21eb5

view details

push time in a month

push eventtorque/deqr

torque

commit sha 67e1e966c3101a36022a4ed88de38b47e2fcd4c6

docs: start documenting things. This is an experiment. The published documentation is stored in a separate repository. I want to be able to store binary data in the documentation (e.g. pictures) without junking up the source repository. This makes the ergonomics of publishing the documentation a bit clunkier, but CI automation means it doesn't actually matter. Docs are only generated for master and tags so that poorly named branches can't clobber tag docs.

view details

torque

commit sha 43b269315fe98edf3dc4922752467274d7c239b0

package: use poetry-dynamic-versioning for versioning. This also lets us easily add a __version__ attribute to the package itself, which is good. Even though it seemed to work well, I always felt a bit nervous about the importlib approach. Well, we still use it for development installs, but packaged versions will have a hardcoded value.

view details

torque

commit sha a5f9797a31c6c547b4f8bff6768c3a53c5d511fb

docs: add a hack for absolute image URI production. Sphinx rewrites all image URIs to be relative to the _static directory which is bundled with the build. However, I absolutely do not want to store images in this repository, and pulling them in during the build process would just result in them being copied into the output directory. Since the goal is to have many copies of the documentation stored int the same repository (one for each version plus master branch), I don't want each published version to This could theoretically be solved using symlinks to a shared image directory from each published version, but that complicates the publishing process. I may try to take that approach later, but at some point this simply became a challenge to see if I could make this approach work. It's very convenient that the Sphinx configuration is just an evaluated python script that allows this sort of degenerate monkey patching to occur. This is tucked behind a new image directive, gimage, so as to be opt-in. Since using this expects the documentation to be compiled without actual access to the images, it will only be able to produce images for a very specific html layout. Other output formats, such as PDF, won't build properly, but I don't care much about that.

view details

torque

commit sha 07e7003b15a4c4778fbbef79b74898a38e98ae50

binarize: allow calling binarize from python code. There's not much of a reason to do this, and the API makes no effort not to be clunky, but there's also not really a reason to prevent it.

view details

torque

commit sha 7cdeccc44fb92c28ef977082ab364620c9aa3ccc

decoders.quirc: handle decoding errors correctly. If something that looks like a QR code is detected but it cannot actually be decoded, then quirc_decode returns an error code. In that case, data.data_type and data.payload contain meaningless values. Theoretically, we could still produce the bounding box, but that adds weird edge cases to the client handling (it would require the user to check each returned QRCode to make sure it had been decoded correctly), which seems like a suboptimal API. This may be worth revisiting in the future, however.

view details

torque

commit sha 06477ea88f58724b09f406a8451d099be0699783

decoders: use sane data conversion defaults. In the general case, returning data as bytes isn't particularly helpful. While it's true that in some advanced cases, converting data requires additional information that the library doesn't have access to, I think it's better for the basic case to work out of the box while providing enough customization capability for more advanced use cases to still be practical. This change is straining against the load-bearing copy-paste technique, which I don't like, but I'll save an attempt to extract the common functionality until later.

view details

torque

commit sha 68d9441b539488c8b89eba454e354d022ff09118

docs.theme: configure things that weren't meant to be configured. I thought about it and realized, while I'm on the monkey patching hell train, I can abuse the theme implementation to get it to do some stuff I'd like, but that isn't exposed as configurable for one reason or another. This is: making the left sidebar the only persistent TOC that includes subsections as well as pages, rather than having the subsections for the current page show up on the right. Also, while the right-side section listing can be disabled without monkey patching, it can only be done on a per-page basis as far as I can tell, which is cumbersome at best.

view details

torque

commit sha 0c8128646328ef1669d99dcdbc80d81995ec32ff

deps: add sphinx-inline-tabs. It is pretty nice.

view details

torque

commit sha 3d029c629a676195e890d58664d24e13c7f21eb5

docs: flesh out the getting started section.

view details

push time in a month

push eventtorque/deqr-docs

torque

commit sha 18b59816cacfd6fc57b2c477ba2d5e018c5f8190

images: add basic demo images.

view details

push time in a month

push eventtorque/deqr-docs

torque

commit sha ea39e806d98d78dfb9d3fa069bf02385f03bbf6a

torque/deqr@a55cd68fb3f388f2b8bf443e7189cfc7161c6725

view details

push time in a month

push eventtorque/deqr

torque

commit sha a55cd68fb3f388f2b8bf443e7189cfc7161c6725

docs: flesh out the getting started section.

view details

push time in a month

push eventtorque/deqr-docs

torque

commit sha 776db1a942e143b87c0e644cd0439fe596b7f542

images: add basic demo images.

view details

push time in a month

push eventtorque/deqr-docs

torque

commit sha 4c805960beea7c5a0fff50c56045d0163b47e4aa

torque/deqr@77d88acc7775de29a01a28c81f0e89d93f7bfba3

view details

push time in a month

push eventtorque/deqr

torque

commit sha c4c72ac49587a24044a0e616e574cbb671393e3b

docs: add a hack for absolute image URI production. Sphinx rewrites all image URIs to be relative to the _static directory which is bundled with the build. However, I absolutely do not want to store images in this repository, and pulling them in during the build process would just result in them being copied into the output directory. Since the goal is to have many copies of the documentation stored int the same repository (one for each version plus master branch), I don't want each published version to This could theoretically be solved using symlinks to a shared image directory from each published version, but that complicates the publishing process. I may try to take that approach later, but at some point this simply became a challenge to see if I could make this approach work. It's very convenient that the Sphinx configuration is just an evaluated python script that allows this sort of degenerate monkey patching to occur. This is tucked behind a new image directive, gimage, so as to be opt-in. Since using this expects the documentation to be compiled without actual access to the images, it will only be able to produce images for a very specific html layout. Other output formats, such as PDF, won't build properly, but I don't care much about that.

view details

torque

commit sha d26a4fe9b50b411f36147e552e46825db27511dc

binarize: allow calling binarize from python code. There's not much of a reason to do this, and the API makes no effort not to be clunky, but there's also not really a reason to prevent it.

view details

torque

commit sha a4cacb35db408eb58bace2c563e5bdc4b5f86c4f

decoders.quirc: handle decoding errors correctly. If something that looks like a QR code is detected but it cannot actually be decoded, then quirc_decode returns an error code. In that case, data.data_type and data.payload contain meaningless values. Theoretically, we could still produce the bounding box, but that adds weird edge cases to the client handling (it would require the user to check each returned QRCode to make sure it had been decoded correctly), which seems like a suboptimal API. This may be worth revisiting in the future, however.

view details

torque

commit sha c430a2a1d5ae13ceb40d1ed7ff90287317db192d

decoders: use sane data conversion defaults. In the general case, returning data as bytes isn't particularly helpful. While it's true that in some advanced cases, converting data requires additional information that the library doesn't have access to, I think it's better for the basic case to work out of the box while providing enough customization capability for more advanced use cases to still be practical. This change is straining against the load-bearing copy-paste technique, which I don't like, but I'll save an attempt to extract the common functionality until later.

view details

torque

commit sha 1d0b7fa536fc64120d227fa09837908892079cc4

docs.theme: configure things that weren't meant to be configured. I thought about it and realized, while I'm on the monkey patching hell train, I can abuse the theme implementation to get it to do some stuff I'd like, but that isn't exposed as configurable for one reason or another. This is: making the left sidebar the only persistent TOC that includes subsections as well as pages, rather than having the subsections for the current page show up on the right. Also, while the right-side section listing can be disabled without monkey patching, it can only be done on a per-page basis as far as I can tell, which is cumbersome at best.

view details

torque

commit sha c46554070b2074039c8dc76f235ccfe0e05daa5b

deps: add sphinx-inline-tabs. It is pretty nice.

view details

torque

commit sha 77d88acc7775de29a01a28c81f0e89d93f7bfba3

docs: flesh out the getting started section.

view details

push time in a month

push eventtorque/deqr-docs

torque

commit sha bfb22ca615015906282d57b3615607ac9e9a19bb

torque/deqr@31caa99ac48a78c9287dec1c35731ff88acae309

view details

push time in a month

push eventtorque/deqr

torque

commit sha 06e812e1a4c0d92fbed82649aadf130801e7b566

docs: start documenting things. This is an experiment. The published documentation is stored in a separate repository. I want to be able to store binary data in the documentation (e.g. pictures) without junking up the source repository. This makes the ergonomics of publishing the documentation a bit clunkier, but CI automation means it doesn't actually matter. Docs are only generated for master and tags so that poorly named branches can't clobber tag docs.

view details

torque

commit sha 190ebfab2cddedf973a46425be009af6c808dcf2

package: use poetry-dynamic-versioning for versioning. This also lets us easily add a __version__ attribute to the package itself, which is good. Even though it seemed to work well, I always felt a bit nervous about the importlib approach. Well, we still use it for development installs, but packaged versions will have a hardcoded value.

view details

torque

commit sha 31caa99ac48a78c9287dec1c35731ff88acae309

docs: add a hack for absolute image URI production. Sphinx rewrites all image URIs to be relative to the _static directory which is bundled with the build. However, I absolutely do not want to store images in this repository, and pulling them in during the build process would just result in them being copied into the output directory. Since the goal is to have many copies of the documentation stored int the same repository (one for each version plus master branch), I don't want each published version to This could theoretically be solved using symlinks to a shared image directory from each published version, but that complicates the publishing process. I may try to take that approach later, but at some point this simply became a challenge to see if I could make this approach work. It's very convenient that the Sphinx configuration is just an evaluated python script that allows this sort of degenerate monkey patching to occur. This is tucked behind a new image directive, gimage, so as to be opt-in. Since using this expects the documentation to be compiled without actual access to the images, it will only be able to produce images for a very specific html layout. Other output formats, such as PDF, won't build properly, but I don't care much about that.

view details

push time in a month