8

I noticed a couple days ago that this project didn't exist yet in the Rust ecosystem, so I created it. If you need to programmatically interact with a mainframe system, you can now do it conveniently with this library.

I've currently provided two levels of abstraction, but a third is on the way (once I've decided on an implementation).

If you have any thoughts or suggestions, I'm open to them.

[-] livingcoder@lemmy.austinwadeheller.com 8 points 1 year ago* (last edited 1 year ago)

What's the harm in doing a rebuild? Serious question. I simply don't understand where the harm comes from. I would appreciate any insight. Thanks.

Edit: I find the answer to my question at the end of this productive conversation.

17
Linux on an OLED laptop? (lemmy.austinwadeheller.com)

I'm seeing a lot of old posts about how Linux has poor support for OLED. Is this still the case? Should I avoid OLED laptops?

That's scary. I think everyone should see this one.

How does this work with the code license? If this is all fine, doesn't this mean that we should be avoiding the kind of license they're using in the future?

You may be able to use something like lazy_static.

https://docs.rs/lazy_static/latest/lazy_static/

8
submitted 1 year ago* (last edited 1 year ago) by livingcoder@lemmy.austinwadeheller.com to c/rust@lemmy.ml

I made a 2D platformer randomization crate called Shiftnanigans (https://github.com/AustinHellerRepo/Shiftnanigans) as part of my work on the open source game Jumpy (https://github.com/fishfolk/jumpy). Within the map editor of Jumpy, the Randomize button will randomize the placement of tiles and elements, maintaining the general structures of the map. I've described the two abstract concepts and sets of structs used to accomplish this functionality below. This is just a general overview, but I am happy to elaborate further if anyone has questions about the algorithms and data structures used.

Web demo (click Map Editor -> Open Map -> Level #12 -> Randomize (in the top right)): https://fishfolk.github.io/jumpy/player/latest/

The PixelBoard and PixelBoardRandomizer

In order to randomize a 2D platformer or tile-based map, the PixelBoardRandomizer takes in a grid of "pixels" as a PixelBoard, detects wall and non-wall pixels, groups them together, and finds locations for those groups such that no two groups overlap while also maintaining contact with adjacent walls (or not, as applicable). Wall chunks that do not make contact with the corners are considered "wall segments" and can shift around along the edge of the map. Each randomized PixelBoard can be repeatedly randomized itself without affecting the size or adjacency of pixel groups, allowing repeated execution of the randomization function on a previously randomized PixelBoard. To optimize this process, shifters (described below) are ultimately used to compare pixel group locations to each other, incrementing to the next randomized location for the specific pixel group. All pixel groups are ultimately compared to each other to ensure that they are all valid together in some combination of locations. Instead of placing all of the pixel groups down randomly one at a time just to find out that the last pixel group won't fit (ultimately because the very first pixel group is in a bad spot), each pixel group is paired up with each other pixel group as a cartesian product and is compared together.

The PixelBoard and PixelBoardRandomizer Continued

This is where it gets a little complex. Each pair of pixel groups iterates over all possible locations for those pixel groups in a round robin cycle, allowing each pair of pixel groups an opportunity to check if their current random locations are valid together. As valid pairs of pixel groups are discovered, a hypergraph is filled with connecting edges between hypergraph node's subnodes where each hypergraph node is conceptually a pixel group, a subnode is a location for that pixel group, and the edge indicates that the two locations of each pixel group are valid together. Once a cliché is discovered between all hypergraph nodes, that indicates that each pixel group location connected together within the cliché are all valid together and would form a valid, randomized PixelBoard.

Shifters and Incrementers

Shifters are just 2-dimensional skewed arrays with a pointer to a current cell where navigation through the array is defined by a few basic operations: forward, backward, and increment. The shifter starts with a column pointer in the 0th row's 0th column. You can imagine that an increment moves the current column pointer down the array, a forward action creates a new active column pointer in the next column at the top row of the array, and a backward action removes the current column pointer and makes the previous column pointer active where it left off. If any action is not possible a None is returned, indicating that a backward action must occur so that the previous column can increment once, and then return forward at the top of the column again with a new column pointer, ultimately iterating over all possible combinations of column cells. An incrementer returns a collection of cells. One of the most useful applications is being basically a wrapper on a shifter that returns, with each iteration of the incrementer, a collection of cells (one per column) as a permutation of the underlying shifter as it moves forward and increments, only moving backward with subsequent iterations of the incrementer that would cause the underlying shifter to increment or move backward and then move forward again with each iteration. With these two data structures understood, it is possible to create many interesting variations of shifters and incrementers that "fail fast" while performing some interesting traversal of a state space. For example, the pair of pixel groups iterate over their possible locations in an expanding square sequence/permutation using the ShiftingSquareBreadthFirstSearchShifter. This could be improved upon by implementing a decrement movement on shifters and utilizing that functionality to search in a triangular shape outward instead of a square.

Efficiencies:

  • Shifters make it very easy to find invalid pairs of column cells and fail fast as opposed to generating a long list of column cells just to discover that the first pair are invalid together.
  • Only pairs of pixel groups that could ever conflict or overlap are compared (so one wall isn't paired with another wall, for example).
  • When a new edge is added to the hypergraph, that edge is the starting point for searching for a cliché within the hypergraph.
  • A cliché search is only performed if each hypergraph node's subnode for the new edge is connected to all other hypergraph nodes at least once.

Next steps:

  • Allow for specifying that "wall segments" should not shift around, greatly improving performance but reducing degree of randomness.
  • Create a few examples in the Github repository based on common uses of this functionality
  • Implement a decrement action for shifters, permitting more efficient state space search algorithms.
  • Create trait implementations that more easily convert existing iterators into variations of shifters or incrementers.

"Returns to normal"... minus one user.

1
Fish Folk - Jumpy (www.kickstarter.com)

This open source game has just a few hours left in its Kickstarter campaign. I've been helping with the map editor over the last few months and it's been a joy. Check it out and hop on the Discord if you want to chat with the developers, artists, etc.

Web demo: https://fishfolk.github.io/jumpy/player/latest/

"then it doesn't deserve to exist"

When I hear that, I hear an implicit value judgement with Meta as the standard. The value of an instance is in if it can survive against a social aggregation to Meta's instance. Only then is it worthy of existing, if it can compete with the degree of funding, advertising, and account creation streamlining that we would expect from a social media platform giant.

When I hear that, I hear that small, self-hosted instances don't deserve to exist.

Helpful Wikipedia link (for those like me who had no idea what XMPP was): https://en.wikipedia.org/wiki/XMPP

Passwords "should" be hashed anyway, so I don't understand why there's a limit. Are they actually being stored as plaintext in a VARCHAR(60) column in the database? Please tell me that's not happening.

So long as it's not resource harvesting robots, ever expanding outward from their host planet...

7

I want to find or contribute to an open source Android app that behaves as a browser so that I can incorporate saving web pages to a specified (self-hosted) wallabag docker instance. Any suggestions?

I used to have a phone with a replaceable battery and it was awesome. I would charge the other battery while using the phone all day, carefree. When it was about to die, I'd swap out the battery. It was basically like I had an instant charge of 100% on my phone. Those were good days.

I've never heard of these before. I'll have to check them out. Thanks for the suggestion.

17

I once bought a router to use for my internet when I moved into my new house just to find out that it "wasn't compatible" with Verizon's service. I still have it (because I'm terrible about returning things). Is there any point in keeping it? Is there anything fun or interesting that I could do with it?

[-] livingcoder@lemmy.austinwadeheller.com 5 points 1 year ago* (last edited 1 year ago)

These things hurt me while setting up my Lemmy instance on my Raspberry Pi 4 via Docker.

  • The instance name must be less than or equal to 20 characters in length (database limit)
  • The lemmy and lemmy-ui docker images must be arm64 (for my Ubuntu 22.04 setup on my RaspberryPi)
  • The certbot image needs to be added to the docker-compose from the docker install instructions and "depend_on" the nginx image
  • I needed to disable the 80->443 redirect in my nginx config in order to get my initial cert (maybe there's another way)
  • The lemmy container needs its own network to allow it to access the internet (permitting searching)
view more: next ›

livingcoder

joined 1 year ago