--fetch-context doesn’t go back into archived feeds … 🤦
--fetch-context doesn’t go back into archived feeds … 🤦
@quark This is what I get. 🤔
@quark This is what I get. 🤔
@quark This is what I get. 🤔
@quark This is what I get. 🤔
Jenny has to look for the metadata fields, it must find the
# prev = ... line. To do so, I naively wrote something along these lines:
for line in content.splitlines():
if line.startswith('# prev = '):
...
Problem is, we use \u2028 a lot in twtxt feeds and Python interprets those as line separators as well. That’s not what we want here. Jenny must only split at a
\n.Now @prologic had a quote/copy of some of his metadata fields in a twt. Like so:
# prev = foo bar
Perfectly legitimate, but now jenny found the
# prev = *twice* (once in the actual header, once in a twt), didn’t know what to do, and thus did not fetch the archived feeds. 🤦Should be fixed in this commit: https://www.uninformativ.de/git/jenny/commit/6e8ce5afdabd5eac22eae4275407b3bd2a167daf.html
Jenny has to look for the metadata fields, it must find the
# prev = ... line. To do so, I naively wrote something along these lines:
for line in content.splitlines():
if line.startswith('# prev = '):
...
Problem is, we use \u2028 a lot in twtxt feeds and Python interprets those as line separators as well. That’s not what we want here. Jenny must only split at a
\n.Now @prologic had a quote/copy of some of his metadata fields in a twt. Like so:
# prev = foo bar
Perfectly legitimate, but now jenny found the
# prev = *twice* (once in the actual header, once in a twt), didn’t know what to do, and thus did not fetch the archived feeds. 🤦Should be fixed in this commit: https://www.uninformativ.de/git/jenny/commit/6e8ce5afdabd5eac22eae4275407b3bd2a167daf.html
Jenny has to look for the metadata fields, it must find the
# prev = ... line. To do so, I naively wrote something along these lines:
for line in content.splitlines():
if line.startswith('# prev = '):
...
Problem is, we use \u2028 a lot in twtxt feeds and Python interprets those as line separators as well. That’s not what we want here. Jenny must only split at a
\n.Now @prologic had a quote/copy of some of his metadata fields in a twt. Like so:
# prev = foo bar
Perfectly legitimate, but now jenny found the
# prev = *twice* (once in the actual header, once in a twt), didn’t know what to do, and thus did not fetch the archived feeds. 🤦Should be fixed in this commit: https://www.uninformativ.de/git/jenny/commit/6e8ce5afdabd5eac22eae4275407b3bd2a167daf.html
Jenny has to look for the metadata fields, it must find the
# prev = ... line. To do so, I naively wrote something along these lines:
for line in content.splitlines():
if line.startswith('# prev = '):
...
Problem is, we use \\u2028 a lot in twtxt feeds and Python interprets those as line separators as well. That’s not what we want here. Jenny must only split at a
\\n.Now @prologic had a quote/copy of some of his metadata fields in a twt. Like so:
# prev = foo bar
Perfectly legitimate, but now jenny found the
# prev = *twice* (once in the actual header, once in a twt), didn’t know what to do, and thus did not fetch the archived feeds. 🤦Should be fixed in this commit: https://www.uninformativ.de/git/jenny/commit/6e8ce5afdabd5eac22eae4275407b3bd2a167daf.html
~/.cache/jenny should reset everything, it doesn’t store any other state. 🤔
~/.cache/jenny should reset everything, it doesn’t store any other state. 🤔
~/.cache/jenny should reset everything, it doesn’t store any other state. 🤔
~/.cache/jenny should reset everything, it doesn’t store any other state. 🤔
> 3.
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)I think I like this a lot. 🤔
The problem with using *hashes* always was that they’re “one-directional”: You can construct a hash from URL + timestamp + twt, but you cannot do the inverse. When I see
#weadxga, I have no idea what that could possibly refer to.But of course something like
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) has all the information you need. This could simplify twt/feed discovery quite a bit, couldn’t it? 🤔 That thing that I just implemented – jenny asking some Yarn pod for some twt hash – would not be necessary anymore. Clients could easily and automatically fetch *complete* threads instead of requiring the user to follow all relevant feeds.Only using the timestamp to identify a twt also solves the edit problem.
It even is better for non-Yarn clients, because you now don’t have to read, understand, and implement a “twt hash specification” before you can reply to someone.
The only problem, really, is that
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) is *so long*. Clients would have to try harder to hide this. 😅
> 3.
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)I think I like this a lot. 🤔
The problem with using *hashes* always was that they’re “one-directional”: You can construct a hash from URL + timestamp + twt, but you cannot do the inverse. When I see
#weadxga, I have no idea what that could possibly refer to.But of course something like
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) has all the information you need. This could simplify twt/feed discovery quite a bit, couldn’t it? 🤔 That thing that I just implemented – jenny asking some Yarn pod for some twt hash – would not be necessary anymore. Clients could easily and automatically fetch *complete* threads instead of requiring the user to follow all relevant feeds.Only using the timestamp to identify a twt also solves the edit problem.
It even is better for non-Yarn clients, because you now don’t have to read, understand, and implement a “twt hash specification” before you can reply to someone.
The only problem, really, is that
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) is *so long*. Clients would have to try harder to hide this. 😅
> 3.
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)I think I like this a lot. 🤔
The problem with using *hashes* always was that they’re “one-directional”: You can construct a hash from URL + timestamp + twt, but you cannot do the inverse. When I see
#weadxga, I have no idea what that could possibly refer to.But of course something like
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) has all the information you need. This could simplify twt/feed discovery quite a bit, couldn’t it? 🤔 That thing that I just implemented – jenny asking some Yarn pod for some twt hash – would not be necessary anymore. Clients could easily and automatically fetch *complete* threads instead of requiring the user to follow all relevant feeds.Only using the timestamp to identify a twt also solves the edit problem.
It even is better for non-Yarn clients, because you now don’t have to read, understand, and implement a “twt hash specification” before you can reply to someone.
The only problem, really, is that
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) is *so long*. Clients would have to try harder to hide this. 😅
> 3.
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)I think I like this a lot. 🤔
The problem with using *hashes* always was that they’re “one-directional”: You can construct a hash from URL + timestamp + twt, but you cannot do the inverse. When I see
#weadxga, I have no idea what that could possibly refer to.But of course something like
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) has all the information you need. This could simplify twt/feed discovery quite a bit, couldn’t it? 🤔 That thing that I just implemented – jenny asking some Yarn pod for some twt hash – would not be necessary anymore. Clients could easily and automatically fetch *complete* threads instead of requiring the user to follow all relevant feeds.Only using the timestamp to identify a twt also solves the edit problem.
It even is better for non-Yarn clients, because you now don’t have to read, understand, and implement a “twt hash specification” before you can reply to someone.
The only problem, really, is that
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) is *so long*. Clients would have to try harder to hide this. 😅
@prologic Oh, interesting. It doesn’t serve JSON, though, does it?
curl -s -H 'Accept: application/json' https://search.twtxt.net/twt/j7f652q gets me an HTML page. 🤔
@prologic Oh, interesting. It doesn’t serve JSON, though, does it?
curl -s -H 'Accept: application/json' https://search.twtxt.net/twt/j7f652q gets me an HTML page. 🤔
@prologic Oh, interesting. It doesn’t serve JSON, though, does it?
curl -s -H 'Accept: application/json' https://search.twtxt.net/twt/j7f652q gets me an HTML page. 🤔
@prologic Oh, interesting. It doesn’t serve JSON, though, does it?
curl -s -H 'Accept: application/json' https://search.twtxt.net/twt/j7f652q gets me an HTML page. 🤔
--fetch-context thingy: It can now ask Yarn pods for twt hashes.https://www.uninformativ.de/git/jenny/commit/eefd3fa09083e2206ed0d71887d2ef2884684a71.html
This is only done as a last resort if there’s no other way to find the missing twt. Like, when there’s a twt that begins with just a hash and no user mention, there’s no way for jenny to know on which feed that twt can be found, so it’ll ask some Yarn pod in that case.
--fetch-context thingy: It can now ask Yarn pods for twt hashes.https://www.uninformativ.de/git/jenny/commit/eefd3fa09083e2206ed0d71887d2ef2884684a71.html
This is only done as a last resort if there’s no other way to find the missing twt. Like, when there’s a twt that begins with just a hash and no user mention, there’s no way for jenny to know on which feed that twt can be found, so it’ll ask some Yarn pod in that case.
--fetch-context thingy: It can now ask Yarn pods for twt hashes.https://www.uninformativ.de/git/jenny/commit/eefd3fa09083e2206ed0d71887d2ef2884684a71.html
This is only done as a last resort if there’s no other way to find the missing twt. Like, when there’s a twt that begins with just a hash and no user mention, there’s no way for jenny to know on which feed that twt can be found, so it’ll ask some Yarn pod in that case.
--fetch-context thingy: It can now ask Yarn pods for twt hashes.https://www.uninformativ.de/git/jenny/commit/eefd3fa09083e2206ed0d71887d2ef2884684a71.html
This is only done as a last resort if there’s no other way to find the missing twt. Like, when there’s a twt that begins with just a hash and no user mention, there’s no way for jenny to know on which feed that twt can be found, so it’ll ask some Yarn pod in that case.
That temperature drop was pretty sudden. Boom, cold, no warning. Give me some time to adapt, man! 😂
That temperature drop was pretty sudden. Boom, cold, no warning. Give me some time to adapt, man! 😂
That temperature drop was pretty sudden. Boom, cold, no warning. Give me some time to adapt, man! 😂
That temperature drop was pretty sudden. Boom, cold, no warning. Give me some time to adapt, man! 😂
I recently took the time to find an alternative route to one of my doctors. Hardly any people using that route *and* it’s faster. Absolutely brilliant. It’s like having a chauffeur. 😅
*But* navigating through that system is also a total nightmare. Which bus takes you to which places at which times, getting info about current construction sites, all that stuff. It takes forever.
And it doesn’t help at all that this is what their website looks like:
https://movq.de/v/acb23dc1c2/s.png
You can’t move that window at the bottom. It just sits there and takes up space from the map. It gets even worse: When you ask for a route, you get to see the buses and individual stops and all that – but all in that little window with that large font! Why do we all have widescreen monitors and than stack UI items vertically?
Sure, 30 years ago it was much worse. But it could also be much better today. 😅
I recently took the time to find an alternative route to one of my doctors. Hardly any people using that route *and* it’s faster. Absolutely brilliant. It’s like having a chauffeur. 😅
*But* navigating through that system is also a total nightmare. Which bus takes you to which places at which times, getting info about current construction sites, all that stuff. It takes forever.
And it doesn’t help at all that this is what their website looks like:
https://movq.de/v/acb23dc1c2/s.png
You can’t move that window at the bottom. It just sits there and takes up space from the map. It gets even worse: When you ask for a route, you get to see the buses and individual stops and all that – but all in that little window with that large font! Why do we all have widescreen monitors and than stack UI items vertically?
Sure, 30 years ago it was much worse. But it could also be much better today. 😅
I recently took the time to find an alternative route to one of my doctors. Hardly any people using that route *and* it’s faster. Absolutely brilliant. It’s like having a chauffeur. 😅
*But* navigating through that system is also a total nightmare. Which bus takes you to which places at which times, getting info about current construction sites, all that stuff. It takes forever.
And it doesn’t help at all that this is what their website looks like:
https://movq.de/v/acb23dc1c2/s.png
You can’t move that window at the bottom. It just sits there and takes up space from the map. It gets even worse: When you ask for a route, you get to see the buses and individual stops and all that – but all in that little window with that large font! Why do we all have widescreen monitors and than stack UI items vertically?
Sure, 30 years ago it was much worse. But it could also be much better today. 😅
I recently took the time to find an alternative route to one of my doctors. Hardly any people using that route *and* it’s faster. Absolutely brilliant. It’s like having a chauffeur. 😅
*But* navigating through that system is also a total nightmare. Which bus takes you to which places at which times, getting info about current construction sites, all that stuff. It takes forever.
And it doesn’t help at all that this is what their website looks like:
https://movq.de/v/acb23dc1c2/s.png
You can’t move that window at the bottom. It just sits there and takes up space from the map. It gets even worse: When you ask for a route, you get to see the buses and individual stops and all that – but all in that little window with that large font! Why do we all have widescreen monitors and than stack UI items vertically?
Sure, 30 years ago it was much worse. But it could also be much better today. 😅
OS/2 Warp 4 came with Java and that not only meant a runtime but *a JDK* including *API docs*. So, for AoC, I could try to solve as many puzzles as I can in that environment, directly on my old Pentium. For later puzzles, I’ll definitely want to switch to my normal workstation for faster development cycles – but I can still use Java and try to backport the solutions.
Sounds interesting. 🤔
https://movq.de/v/81ac0142f2/1.ff.jpg
https://movq.de/v/81ac0142f2/2.ff.jpg
OS/2 Warp 4 came with Java and that not only meant a runtime but *a JDK* including *API docs*. So, for AoC, I could try to solve as many puzzles as I can in that environment, directly on my old Pentium. For later puzzles, I’ll definitely want to switch to my normal workstation for faster development cycles – but I can still use Java and try to backport the solutions.
Sounds interesting. 🤔
https://movq.de/v/81ac0142f2/1.ff.jpg
https://movq.de/v/81ac0142f2/2.ff.jpg
OS/2 Warp 4 came with Java and that not only meant a runtime but *a JDK* including *API docs*. So, for AoC, I could try to solve as many puzzles as I can in that environment, directly on my old Pentium. For later puzzles, I’ll definitely want to switch to my normal workstation for faster development cycles – but I can still use Java and try to backport the solutions.
Sounds interesting. 🤔
https://movq.de/v/81ac0142f2/1.ff.jpg
https://movq.de/v/81ac0142f2/2.ff.jpg
OS/2 Warp 4 came with Java and that not only meant a runtime but *a JDK* including *API docs*. So, for AoC, I could try to solve as many puzzles as I can in that environment, directly on my old Pentium. For later puzzles, I’ll definitely want to switch to my normal workstation for faster development cycles – but I can still use Java and try to backport the solutions.
Sounds interesting. 🤔
https://movq.de/v/81ac0142f2/1.ff.jpg
https://movq.de/v/81ac0142f2/2.ff.jpg
@lyse Oof, well, good luck. Those multi-day meetings are usually really exhausting (and mostly pointless) in our company, hopefully it’s different at yours. ✌️
@lyse Oof, well, good luck. Those multi-day meetings are usually really exhausting (and mostly pointless) in our company, hopefully it’s different at yours. ✌️
@lyse Oof, well, good luck. Those multi-day meetings are usually really exhausting (and mostly pointless) in our company, hopefully it’s different at yours. ✌️
@lyse Oof, well, good luck. Those multi-day meetings are usually really exhausting (and mostly pointless) in our company, hopefully it’s different at yours. ✌️
