Colorado
Hi! I'm Alex (a.k.a. nytpu), and I do some programming and electronics projects. I love C, POSIX shell, and assembly (retro game consoles only); I dabble in Scheme, Ada, and whatever tickles my fancy at a given point in time.
From Alex // nytpu to ~nytpu/public-inbox
Hi! Thanks so much for the contributions! Both patches are now applied, although I took the liberty of modifying them to remove the sweeping whitespace changes and to clean up some stuff. First commit: https://git.sr.ht/~nytpu/tlsada/commit/0a63fe01c9ee34495ef9689b0b71a774dd71fc56 - Removed unrelated whitespace changes - Reworded commit message because I'm very particular about them - Forced handshakes for Client_Contexts as well as Server_Contexts, for similar reasons - Factored out duplicate code in exception messages Second commit: https://git.sr.ht/~nytpu/tlsada/commit/134db3791ae3e412d0d4be7ae30b129c5b11d850
From Alex // nytpu to ~nytpu/public-inbox
Fixed in e688c31 (https://git.sr.ht/~nytpu/commons-downloader/commit/e688c306c53fc617a9648b606f6dc9ea2bacf9ac) Thanks! ~nytpu -- Alex // nytpu alex@nytpu.com gpg --locate-external-key alex@nytpu.com
From Alex // nytpu to ~nytpu/public-inbox
Hi! On 2022-09-29 01:39PM, Wyatt Avery wrote: > This project is a huge time saver for me. Simple and effective. So > thanks to any and all who have worked on it thus far. Thanks! > In my use, there is a lot of metadata that's been added to Wikimedia > Commons that is not embedded within the file, such as date, credit, > notes, source, and rights (permission). > > When scraping a collection of images it would be invaluable to have > recorded that information as it came in. >
From Alex // nytpu to ~nytpu/public-inbox
Thanks! ~nytpu -- Alex // nytpu alex@nytpu.com gpg --locate-external-key alex@nytpu.com
From Alex // nytpu to ~nytpu/public-inbox
Thanks! ~nytpu -- Alex // nytpu alex@nytpu.com gpg --locate-external-key alex@nytpu.com
From Alex // nytpu to ~nytpu/public-inbox
I've been meaning to update it myself for some time but knowing how personal projects go it probably would've been far into the future, so this is much appreciated! Thanks so much! ~nytpu -- Alex // nytpu alex@nytpu.com gpg --locate-external-key alex@nytpu.com
From Alex // nytpu to ~adnano/gemini
Luckily it's pretty easy to test this with openssl's s_client, it'll say "closed" at the end if the connection was closed properly: printf "gemini://nytpu.com/about.gmi\r\n" | openssl s_client -ign_eof -connect nytpu.com:1965 outputs: depth=0 O = nytpu, CN = nytpu.com verify error:num=18:self signed certificate [...handshake and cert info...] 20 text/gemini; lang=en-US [...the actual response body (if success response code)...] [...end-of-connection info...]
From Alex // nytpu to ~adnano/gemini
On 2021-11-08 08:07PM, codesoap at mailbox.org wrote: > Hi all, > > =>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>] > From this description I don't know whether <USER-FRIENDLY LINK NAME> > MAY be empty. Which of these regular expressions would be correct to > parse a link line? The user friendly link name is optional, however if it is present then the whitespace after the url is mandatory as well. In other words, the URL is mandatory, and you either have no link name and no space after the URL or a link name and mandatory space(s) after the URL. So you have the following possibilities for link lines: =>url <- no link name, no space between => and url
From Alex // nytpu to ~adnano/gemini
As of late 2019 client-side TLS 1.3 for LibreSSL was implemented, which I can confirm. Server support was completed by mid-to-late 2020 but 1.3 support for their OpenSSL API clone wasn't finished yet. Apparently in the latest LibreSSL release (3.4.1, October 14th) they completed their implementation of the OpenSSL TLS 1.3 API, which means that an up-to-date LibreSSL should have full support for TLS 1.3 through all of their various APIs as of now---although I can't confirm it since I use LibreSSL very intermittently and usually just for testing of cross-compilation to a BSD. I've been using GnuTLS a little bit in Ada and it seems to support 1.3 fine although my testing was at the absolute most basic level. According to various developer's blogs and the changelog GnuTLS got TLS
From nytpu to ~sircmpwn/gmni-devel
This will generate `id` attributes for all heading levels. The labels
are generated using steps 1-4 of the gitlab flavored markdown algorithm
which seems to be pretty standard for generating anchors:
https://docs.gitlab.com/ee/user/markdown.html#header-ids-and-links
A unique ID isn't appended to avoid having to store a list of previous
headers to compare against.
---
This has been tested locally and on my capsule's public kineto proxy.
Would it be good to also add a link enclosing the header to allow for
clicking on the header to get the full url with the fragment? Or do
something like the Sourcehut markdown converter does and add an icon
next to the headers that'll link to the header? I could send a
[message trimmed]