zkfcfbzr

joined 2 years ago
sorted by: new top controversial old
How much weight are the 8-10 humans at tier 2.5 carrying? in c/[email protected]
[–] [email protected] 2 points 7 minutes ago

Others have covered that there were internal supports, so they were supporting nothing at all. But let's assume they weren't.

I'm going for an intentional underestimate - so let's say there are 10 people in your layer (I think 8 is more likely), then 24 above them, 18 above them, 18 above them, 25 above them, 14 above them, and 2 above them. I think most people would agree those are underestimates for each ring.

That's 101 people being supported by 10 people. If we take another underestimate that each of those people weighs 100 pounds (45.36 kg) then that's 10,100 pounds (4581.28 kg) - or 1010 pounds (458.13 kg) supported by each of the 10 people in your ring, completely ignoring the weight of the metal rings visible in the picture. So I think it's safe to say it was mostly the internal supports at work.

Dire wolf revived through biotech company's de-extinction process in c/[email protected]
[–] [email protected] 11 points 1 hour ago

Here's a better article that isn't as uncritically sensationalist.

https://arstechnica.com/science/2025/04/de-extinction-company-announces-that-the-dire-wolf-is-back/

tl;dr is that it's basically just a gray wolf with 14 edited genes, most of which are from natural gray wolf populations rather than dire wolf genomes. The result is a gray wolf that's visually similar to a dire wolf, not a dire wolf.

someone teach them LaTeX in c/[email protected]
[–] [email protected] 2 points 2 hours ago* (last edited 2 hours ago)

Honestly the worst thing about this equation isn't the fact that they had poor typesetting, it was that they used decorative constants. The ε and φ values they chose just cancel out. The equation is equivalent to (xᵢ - mᵢ) / mᵢ.

someone teach them LaTeX in c/[email protected]
[–] [email protected] 30 points 6 hours ago* (last edited 6 hours ago) (2 children)

Asterisks for multiplication are fine and normal and common in typed text. Where it's unusual is in text that's been typeset, where using things like asterisks for multiplication defeat the point of typesetting, It would be like going through all the effort to typeset an equation, but still saying sqrt(x) instead of using the square root symbol.

Why is pynput typing incorrect output, but only on Linux? in c/[email protected]
[–] [email protected] 1 points 4 days ago* (last edited 4 days ago)

disregard this comment

Why is pynput typing incorrect output, but only on Linux? in c/[email protected]
[–] [email protected] 1 points 4 days ago* (last edited 4 days ago) (3 children)

Do you follow the reasoning for why they set it up this way? The comments in this function from _xorg in keyboard make it seem like it expects K1 K2 K3 K4.

#: Finds a keycode and index by looking at already used keycodes
        def reuse():
            for _, (keycode, _, _) in self._borrows.items():
                keycodes = mapping[kc2i(keycode)]

                # Only the first four items are addressable by X
                for index in range(4):
                    if not keycodes[index]:
                        return keycode, index

I assume that second comment is the reason the person who wrote your function likes the number 4.

Which way is right/wrong here? It would seem at least part of the issue to me is that they don't make the list be K1 K2 K1 K2 as they say, since the function I quoted above often receives a list formatted like K1 K2 K1 NoSymbol.

Also, if I modify the function you quoted from to remove the duplications, I'm still finding that the first element is always duplicated to the third element anyways - it must be happening elsewhere as well. Actually, even if I modify the entire function to just be something nonsensical and predictable like this:

def keysym_normalize(keysym):
    # Remove trailing NoSymbol
    stripped = list(reversed(list(
        itertools.dropwhile(
            lambda n: n == Xlib.XK.NoSymbol,
            reversed(keysym)))))
    if not stripped:
        return
    else:
        return (keysym_group(stripped[0], stripped[0]), keysym_group(stripped[0], stripped[0]))

then the behavior of the output doesn't change at all from how it behaves when this function is how it normally is... It still messes up every third special character, duplicating the previously encountered special character

Later edit: After further investigation, the duplication of the first entry to the third entry seems to happen in the Xlib library, installed with pynput, in the display.py file, in the change_keyboard_mapping function, which only has a single line. Inspecting the output of the get_keyboard_mapping() function both before and after the change_keyboard_mapping function does its thing shows that it jumps right from [0, 0, 0, 0, 0, 0, 0, 0, 0, 0] to [keysym, 0, keysym, 0, 0, 0, 0, 0, 0, 0]. It's still unclear to me if this is truly intended or a bug.

Why is pynput typing incorrect output, but only on Linux? in c/[email protected]
[–] [email protected] 2 points 6 days ago* (last edited 5 days ago)

Gonna make some notes since I made some progress tonight (so far).

Within pynput's keyboard's _xorg.py file, in the Controller class, self._keyboard_mapping maps from each key's unique keysym value, which is an integer, to a 2-tuple of integers. The actual keysym for each key in the mapping appears to be correct, but occasionally the 2-tuple duplicates that of another entry in self._keyboard_mapping - and these duplicates correspond precisely to the errors I see in pynput's outputs.

For example, '𝕥' has keysym = 16897381 and '𝕖' has keysym = 16897366, but both 16897381 and 16897366 map, in self._keyboard_mapping, to the 2-tuple (8, 1) - and '𝕖' is indeed printed as '𝕥' by pynput. (𝕥's keysym appears first in self._keyboard_mapping). (The 2-tuple keysyms map to are not unique or consistent, they vary based on the order they were encountered and reset when X resets)

Through testing, I found that this type of error happens precisely every third time a new keysym is added to self._keyboard_mapping, and that every third such mapping always duplicates the 2-tuple of the previous successful mapping.

From that register function I mentioned, the correct 2-tuple should be, I believe, (keycode, index). This is not happening correctly every 3rd registration, but I'm not yet sure why.

However, I did find a bit more than that: register() gets its keycode and index from one of the three functions above it, reuse() borrow() or overwrite(). The problematic keys always get their keycode and index from reuse - and reuse finds the first unused index 0-3 for a given keycode, then returns that. What I found here is that, for the array keycodes, the first element is always duplicated to the third position as well, so indexes 0 and 2 are identical. As an example, here are two values of keycodes from my testing:

keycodes = array('I', [16897386, 0, 16897386, 0, 0, 0, 0, 0, 0, 0])
keycodes = array('I', [16897384, 16897385, 16897384, 0, 0, 0, 0, 0, 0, 0])

With this in mind, I was actually able to fix the bug by changing the line for index in range(4): in reuse() to for index in range(2):. With that change my script no longer produces any incorrect characters.

However, based on the comments in the function, I believe range(4) is the intended behavior and I'm just avoiding the problem instead of fixing it. I have a rather shallow understanding of what these functions or values are trying to accomplish. I don't know why the first element of the array is duplicated to the third element. There's also a different issue I noticed where even when this function returns an index of 3, that index of 3 is never used in self._keyboard_mapping - it uses 1 instead. I'm thinking these may be two separate bugs. Either way, these two behaviors combined explain why it's every third time a new keysym is added to self._keyboard_mapping that the issue happens: While they in theory support an index of 0 1 2 or 3 for each keycode, in practice only indices 0 1 and 3 work since 2 always copies 0 - and whenever 3 is picked it's improperly saved as 1 somewhere.

I may keep investigating the issues in search of a true fix instead of a cover-my-eyes fix.

Why is pynput typing incorrect output, but only on Linux? in c/[email protected]
[–] [email protected] 1 points 6 days ago (1 children)

I agree and appreciate it. I've been trying to figure it out myself but feel a bit out of my element.

What I've found is that in pynput's keyboard's _xorg.py file, the Controller class's self._keyboard_mapping seems to map some different keycodes to the same value, and that seems to correlate exactly with the errors I'm seeing. I haven't figured out why yet. I got to thinking it had something to do with the register function in the _resolve_borrowing function but I forget why and I'm too tired to continue for now. I'll continue tomorrow though.

Why is pynput typing incorrect output, but only on Linux? in c/[email protected]
[–] [email protected] 2 points 1 week ago (4 children)

Hey! Sorry for the very late reply. I've been checking the thread regularly and I swear just a few hours ago (when I made the cross-posts) it was still at 0 replies. I'm gonna blame federation issues.

The command you provided does indicate I'm on pynput 1.8.1, so I can confirm v1.8.1 has the issue.

6
Why is pynput typing incorrect output, but only on Linux? (lemmy.world)
 

cross-posted from: https://lemmy.world/post/27601594

cross-posted from: https://lemmy.world/post/27385536

I have a rather large Python script that I use as basically a replacement for autohotkey. It uses pynput for keyboard and mouse control - and at least on Windows, it works exactly how I expect.

I recently started dual-booting with Linux and have been trying to get the script to work here as well. It does work but with mixed results - in particular, I found that pynput has bizarrely wrong output for special characters, in a way that's both consistent and inconsistent.

The simplest possible case I found that reproduces the error is this script:

import time
from pynput import keyboard

# Sleep statement is just to give time to move the mouse cursor to a text input field
time.sleep(2)

my_kb = keyboard.Controller()

text = '🍆' # Eggplant emoji
my_kb.type(text)

time.sleep(1)

text = '𝕥𝕖𝕤𝕥' # blackboard bold test
my_kb.type(text)

time.sleep(1)

text = '𝐭𝐞𝐬𝐭' # bold test
my_kb.type(text)

When I run that script right now, it produces the output "🍆𝕥𝕥𝕤𝕥𝐭𝐭𝐬𝐭". And if I run it again, it'll produce the same output. And if I change the eggplant emoji to something else, like the regular character 'A', it will still produce the same output (specifically "A𝕥𝕥𝕤𝕥𝐭𝐭𝐬𝐭"). But... If I log out and log back in, then the output changes to something else that's still wrong, but differently. For example, when I changed the eggplant to a regular 'A', then relogged, the output became "A𝕥𝕖𝕖𝕥𝐭𝐞𝐞𝐭". And then that wrong output will keep being the same wrong output until I log out and back in again. If the test strings don't change, then the incorrect outputs don't change on relog - but if they do, then they do.

In the larger script, errors seemed to chain together somehow - like if I produced an eggplant emoji, then tried to write blackboard bold test, I would get "🍆𝕖𝕤🍆". This is despite verifying just before running the pynput.keyboard.Controller.type function that what it was about to type was correct. The issue also happens if I type it character-by-character with press and release functions.

I am very new to Linux. I'm on Linux Mint. I'm running this in a python3 venv that just has pynput and two other external libraries installed. ChatGPT thinks the issue might be related to X11. The issue does not occur at all on Windows, using the exact same code. On Linux there seems to be no issues with typing regular text, just special characters.

12
Why is pynput typing incorrect output, but only on Linux? (lemmy.world)
 

cross-posted from: https://lemmy.world/post/27385536

I have a rather large Python script that I use as basically a replacement for autohotkey. It uses pynput for keyboard and mouse control - and at least on Windows, it works exactly how I expect.

I recently started dual-booting with Linux and have been trying to get the script to work here as well. It does work but with mixed results - in particular, I found that pynput has bizarrely wrong output for special characters, in a way that's both consistent and inconsistent.

The simplest possible case I found that reproduces the error is this script:

import time
from pynput import keyboard

# Sleep statement is just to give time to move the mouse cursor to a text input field
time.sleep(2)

my_kb = keyboard.Controller()

text = '🍆' # Eggplant emoji
my_kb.type(text)

time.sleep(1)

text = '𝕥𝕖𝕤𝕥' # blackboard bold test
my_kb.type(text)

time.sleep(1)

text = '𝐭𝐞𝐬𝐭' # bold test
my_kb.type(text)

When I run that script right now, it produces the output "🍆𝕥𝕥𝕤𝕥𝐭𝐭𝐬𝐭". And if I run it again, it'll produce the same output. And if I change the eggplant emoji to something else, like the regular character 'A', it will still produce the same output (specifically "A𝕥𝕥𝕤𝕥𝐭𝐭𝐬𝐭"). But... If I log out and log back in, then the output changes to something else that's still wrong, but differently. For example, when I changed the eggplant to a regular 'A', then relogged, the output became "A𝕥𝕖𝕖𝕥𝐭𝐞𝐞𝐭". And then that wrong output will keep being the same wrong output until I log out and back in again. If the test strings don't change, then the incorrect outputs don't change on relog - but if they do, then they do.

In the larger script, errors seemed to chain together somehow - like if I produced an eggplant emoji, then tried to write blackboard bold test, I would get "🍆𝕖𝕤🍆". This is despite verifying just before running the pynput.keyboard.Controller.type function that what it was about to type was correct. The issue also happens if I type it character-by-character with press and release functions.

I am very new to Linux. I'm on Linux Mint. I'm running this in a python3 venv that just has pynput and two other external libraries installed. ChatGPT thinks the issue might be related to X11. The issue does not occur at all on Windows, using the exact same code. On Linux there seems to be no issues with typing regular text, just special characters.

Arrest Of Elon Musk For Felony Vote Buying Demanded In Wisconsin in c/[email protected]
[–] [email protected] 40 points 1 week ago

I absolutely hate this title. The first 70% gets you so excited.

I don't understand. He literally does this twice on tv, but he wants it removed from social media? in c/[email protected]
[–] [email protected] 1 points 1 week ago (1 children)

I'm a little out of the loop on how reddit's been. Is blocking links to X officially no longer allowed there?

I don't understand. He literally does this twice on tv, but he wants it removed from social media? in c/[email protected]
[–] [email protected] 22 points 1 week ago (3 children)

Is there confirmation that he actually specifically wanted that image off reddit? Or is this just someone making assumptions after the recent story about him interfering with moderation at reddit?

9
Why is pynput typing incorrect output, but only on Linux? (lemmy.world)
submitted 1 week ago* (last edited 1 week ago) by [email protected] to c/[email protected]
14 comments fedilink
 

I have a rather large Python script that I use as basically a replacement for autohotkey. It uses pynput for keyboard and mouse control - and at least on Windows, it works exactly how I expect.

I recently started dual-booting with Linux and have been trying to get the script to work here as well. It does work but with mixed results - in particular, I found that pynput has bizarrely wrong output for special characters, in a way that's both consistent and inconsistent.

The simplest possible case I found that reproduces the error is this script:

import time
from pynput import keyboard

# Sleep statement is just to give time to move the mouse cursor to a text input field
time.sleep(2)

my_kb = keyboard.Controller()

text = '🍆' # Eggplant emoji
my_kb.type(text)

time.sleep(1)

text = '𝕥𝕖𝕤𝕥' # blackboard bold test
my_kb.type(text)

time.sleep(1)

text = '𝐭𝐞𝐬𝐭' # bold test
my_kb.type(text)

When I run that script right now, it produces the output "🍆𝕥𝕥𝕤𝕥𝐭𝐭𝐬𝐭". And if I run it again, it'll produce the same output. And if I change the eggplant emoji to something else, like the regular character 'A', it will still produce the same output (specifically "A𝕥𝕥𝕤𝕥𝐭𝐭𝐬𝐭"). But... If I log out and log back in, then the output changes to something else that's still wrong, but differently. For example, when I changed the eggplant to a regular 'A', then relogged, the output became "A𝕥𝕖𝕖𝕥𝐭𝐞𝐞𝐭". And then that wrong output will keep being the same wrong output until I log out and back in again. If the test strings don't change, then the incorrect outputs don't change on relog - but if they do, then they do.

In the larger script, errors seemed to chain together somehow - like if I produced an eggplant emoji, then tried to write blackboard bold test, I would get "🍆𝕖𝕤🍆". This is despite verifying just before running the pynput.keyboard.Controller.type function that what it was about to type was correct. The issue also happens if I type it character-by-character with press and release functions.

I am very new to Linux. I'm on Linux Mint. I'm running this in a python3 venv that just has pynput and two other external libraries installed. ChatGPT thinks the issue might be related to X11. The issue does not occur at all on Windows, using the exact same code. On Linux there seems to be no issues with typing regular text, just special characters.

61
What happens when I ignore the cookie preference dialogue on websites? (lemmy.world)
 

Does the GDPR define what the default behavior should be when the user refuses to specify? Does it vary by site? Is it like clicking either "Accept all" or "Reject all"?

215
YSK you can use uBlock Origin to block Lemmy posts containing certain words (lemmy.world)
submitted 2 months ago* (last edited 2 months ago) by [email protected] to c/[email protected]
43 comments fedilink
 

Why YSK: Certain topics are stressful and tend to spread all over the site, including to unrelated communities. Blocking communities can be overkill and ineffective, and likewise for blocking individual users.

To do so, open up the uBlock Origin dashboard, go to the 'My filters' tab, and add this filter:

lemmy.world##article.row:has-text(/word1|word2|word3|word4/i)

For example:

lemmy.world##article.row:has-text(/Trump|Elon|Musk|nazi/i)

Then apply the changes and reload any open tabs, and all posts which contain any of your filtered words will simply not show up.

You'll have to change "lemmy.world" at the start to whatever your actual instance is. You can filter as many or as few words as you want, just keep the / at the start, the /i at the end, and separate words with | pipes. What's actually being filtered is a case-insensitive regex, if you want to get fancy with it.

Here are equivalent filters for reddit and Ars Technica:

reddit.com##div.thing[data-context="listing"]:has-text(/word1|word2|word3|word4/i)
arstechnica.com##:not(:not(head>title:has-text(/^Ars Technica/))) article:has-text(/word1|word2|word3|word4/i)

As a disclaimer, I made these myself, and I'm not particularly familiar with creating uBlock Origin filters. There may be better ways to do this. Also the reddit one is specific to old.reddit.com, and the lemmy filter is made to work with the default lemmy.world web UI and may not work on other UIs without tinkering.

Yes, I know I'm just hiding my head in the sand.

1
What're these bugs? (Southwest Florida) (lemmy.world)
submitted 2 years ago* (last edited 2 years ago) by [email protected] to c/[email protected]
0 comments fedilink
 

Imgur album: https://imgur.com/a/ikTA97e

Those photos were taken under extreme magnification and bright light - the actual size is about the size of an uncooked grain of rice. Maybe smaller. This one was killed by freezing to preserve its form.

In the last few days I've started to see a lot of these - I can find one crawling across my desk every 5 or 10 minutes if I remember to look (Though I can't find where they're coming from at all). They don't move all that fast - they're frankly pretty easy to capture or squash.

In person I don't think they look very much like ants but in the closeup I think they kind of do. Also hoping they aren't termites.

Thanks for any help.

Edit: Here's a video of one scurrying across my desk too: https://imgur.com/a/ZC15gNZ

0
Where do you think Nintendo will take Zelda from here? (lemmy.world)
 

Breath of the Wild and Tears of the Kingdom are both fantastic games - and Tears of the Kingdom really does feel (to me) like they just took Breath of the Wild, and added a few more years of dev time to it.

Where do you think Nintendo will take Zelda from here though? Can they keep with the same new formula? Should they? Will a more traditional game feel disappointing after this?

I don't really know what I want myself. I think they should try something different though. At the same time, I can't help but think I'd be disappointed if the next game was more similar to something like Twilight Princess. Have they boxed themselves in?

view more: next ›