1,734,576 events, 916,137 push events, 1,359,479 commit messages, 77,688,746 characters
so that stop working so we're gonna have to undo
note to self: for the love of god make another branch before doing garbage like this
Revert "fuck you"
This reverts commit 6fdfb156c8ff5922c8ce8e32cc7222bb0ece631b.
I fucking hate half-baked AWS bullshit so goddamn much.
Add Programming Discord
- PR Reviewed: 1, 2, 3
- The list over 30-days old, has over 150 stars
- I explained here why I'd used
Notable Channelsand badges instead a description for each entry. - Only table-pipe-alignment markdown lint rule was ignored because as the rule has mentioned, it was impossible to adapt the cell with variable number of images without making the code too messy.
- I added this under Gaming since Discord is more known for that.
https://github.com/mhxion/awesome-programming-discord#readme
Over the years hundreds of developer communities have made Discord their home for helping newcomers in tech, collaborating with open-source project users, and actively contributing by creating occasional programming challenges; this list aggregates the best of them. While existing helper-platforms like Stack Overflow, forums do their job well, they cannot be used for interacting live (debugging), Discord communities fill this major gap. The developer-friendlier the communities, the more productive collaboration is. As of now this list holds over 200 of them (and growing), each of them had gone through proper review policy, and other safety requirements, each carrying useful links; no other awesome Discord list exists to this extend until now. Also the list is relative to awesome-slack.
Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.
- Don't waste my time. Do a good job, adhere to all the guidelines, and be responsive.
- You have to review at least 2 other open pull requests. Try to prioritize unreviewed PRs, but you can also add more comments to reviewed PRs. Go through the below list when reviewing. This requirement is meant to help make the Awesome project self-sustaining. Comment here which PRs you reviewed. You're expected to put a good effort into this and to be thorough. Look at previous PR reviews for inspiration. Just commenting “looks good” or simply marking the pull request as approved does not count! You have to actually point out mistakes or improvement suggestions.
- You have read and understood the instructions for creating a list.
- This pull request has a title in the format
Add Name of List.- ✅
Add Swift - ✅
Add Software Architecture - ❌
Update readme.md - ❌
Add Awesome Swift - ❌
Add swift - ❌
Adding Swift - ❌
Added Swift
- ✅
- Your entry here should include a short description about the project/theme of the list. It should not describe the list itself. The first character should be uppercase and the description should end in a dot. It should be an objective description and not a tagline or marketing blurb.
- ✅
- [iOS](…) - Mobile operating system for Apple phones and tablets. - ✅
- [Framer](…) - Prototyping interactive UI designs. - ❌
- [iOS](…) - Resources and tools for iOS development. - ❌
- [Framer](…) - ❌
- [Framer](…) - prototyping interactive UI designs
- ✅
- Your entry should be added at the bottom of the appropriate category.
- The suggested Awesome list complies with the below requirements.
- Has been around for at least 30 days.
That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent. - Don't open a Draft / WIP pull request while you work on the guidelines. A pull request should be 100% ready and should adhere to all the guidelines when you open it.
- Run
awesome-linton your list and fix the reported issues. If there are false-positives or things that cannot/shouldn't be fixed, please report it. - The default branch should be named
main, notmaster. - Includes a succinct description of the project/theme at the top of the readme. (Example)
- ✅
Mobile operating system for Apple phones and tablets. - ✅
Prototyping interactive UI designs. - ❌
Resources and tools for iOS development. - ❌
Awesome Framer packages and tools.
- ✅
- It's the result of hard work and the best I could possibly produce. If you have not put in considerable effort into your list, your pull request will be immediately closed.
- The repo name of your list should be in lowercase slug format:
awesome-name-of-list.- ✅
awesome-swift - ✅
awesome-web-typography - ❌
awesome-Swift - ❌
AwesomeWebTypography
- ✅
- The heading title of your list should be in title case format:
# Awesome Name of List.- ✅
# Awesome Swift - ✅
# Awesome Web Typography - ❌
# awesome-swift - ❌
# AwesomeSwift
- ✅
- Non-generated Markdown file in a GitHub repo.
- The repo should have
awesome-list&awesomeas GitHub topics. I encourage you to add more relevant topics. - Not a duplicate. Please search for existing submissions.
- Only has awesome items. Awesome lists are curations of the best, not everything.
- Does not contain items that are unmaintained, has archived repo, deprecated, or missing docs. If you really need to include such items, they should be in a separate Markdown file.
- Includes a project logo/illustration whenever possible.
- Either centered, fullwidth, or placed at the top-right of the readme. (Example)
- The image should link to the project website or any relevant website.
- The image should be high-DPI. Set it to maximum half the width of the original image.
- Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
- Includes the Awesome badge.
- Should be placed on the right side of the readme heading.
- Can be placed centered if the list has a centered graphics header.
- Should link back to this list.
- Should be placed on the right side of the readme heading.
- Has a Table of Contents section.
- Should be named
Contents, notTable of Contents. - Should be the first section in the list.
- Should only have one level of nested lists, preferably none.
- Should be named
- Has an appropriate license.
- We strongly recommend the CC0 license, but any Creative Commons license will work.
- Tip: You can quickly add it to your repo by going to this URL:
https://github.com/<user>/<repo>/community/license/new?branch=master&template=cc0-1.0(replace<user>and<repo>accordingly).
- Tip: You can quickly add it to your repo by going to this URL:
- A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. Neither are WTFPL and Unlicense.
- Place a file named
licenseorLICENSEin the repo root with the license text. - Do not add the license name or text to the readme. GitHub already shows the license name at the top of the repo.
- To verify that you've read all the guidelines, please comment on your pull request with just the word
unicorn.
- We strongly recommend the CC0 license, but any Creative Commons license will work.
- Has contribution guidelines.
- The file should be named
contributing.md. Casing is up to you.
- The file should be named
- Has consistent formatting and proper spelling/grammar.
- The link and description are separated by a dash.
Example:- [AVA](…) - JavaScript test runner. - The description starts with an uppercase character and ends with a period.
- Consistent and correct naming. For example,
Node.js, notNodeJSornode.js.
- The link and description are separated by a dash.
- Doesn't include a Travis badge.
You can still use Travis for list linting, but the badge has no value in the readme. - Doesn't include an
Inspired by awesome-fooorInspired by the Awesome projectkinda link at the top of the readme. The Awesome badge is enough.
Go to the top and read it again.
Allow installation of unstable, forked, versions
Add head and devel specs to the homebrew formula to allow installation from the master and develop branches respectively of whichever repo is the source of the homebrew tap. This is fugly, but it seems a necessary evil to allow us to maintain a usable fork including new features not yet merged upstream, without breaking upstream compatibility.
Yeah, I know, it's a horrible hack, I hate it too, but it does the job.
P.S. Yes, this will prevent the formula being accepted to Homebrew core, but that's not going to happen anytime soon, so not worth worrying about
"10:50am. I guess I should move the config server in front. I'll also rename it just to server.
10:55am.
| File of {|spiPath : string; spiText : string; spiChanges : Changes []|}Ok, let me change this so lines and their changes are put here.
10:55am.
| File of {|spiPath : string; spiChangedLines : (int * string) []|}Yeah, this should go nicely. I am going to leave the plugin until I am done with everything on this side.
/// Parses a number as a sequence of digits and optionally underscores. Filters out the underscores from the result.
let number (s : Tokenizer) =Let me just add this comment.
11am. Ok, focus me. I want to take a break here, but I should at least plan out the next step before that.
11:05am. Mhhhhhh...
Right now the big problem for me is not necessarily how to make the server, but how to combine it with NetMQ.
11:10am. Ok, I'll do it in a naive way and then ask about it. The specifics of how I integrate do not matter too much at the moment. Just using run should do the trick. I'll ask on SO and in the Hopac repo after I am done.
11:15am. Actually, if it is just tokenization, how about I do not bring in Hopac just yet. A dictionary mapping a file path to a resizeable array of tokenized lines is all I need right now.
There is one change I should make to the server. I want the high water mark to be unbounded.
sock.Options.ReceiveHighWatermark <- -1Negative values should mean infinite I think...
Let me check it out in source...no forget this. Let me just set it to max value. What am I doing?
sock.Options.ReceiveHighWatermark <- Int32.MaxValueThere, now it is as close to unbounded as it can get. It would really be bad if the server dropped any receive messages.
11:25am.
type Error = string * Config.Range option
type ClientRes =
| ProjectFileRes of Result<Schema, Error []>
| FileRes of (int * Result<(Range * SpiralToken) [], (Range * TokenizerError) list>)Actually, since I am still messing around, I do not even need the dictionary. I can just map the array I receive straightforwardly.
Let me do that. I want to take a break here.
11:35am.
let server () =
use sock = new RouterSocket()
sock.Options.ReceiveHighWatermark <- Int32.MaxValue
sock.Bind(uri)
printfn "Server bound to: %s" uri
while true do
let msg = sock.ReceiveMultipartMessage(3)
let address = msg.Pop()
msg.Pop() |> ignore
match Json.deserialize(Text.Encoding.Default.GetString(msg.Pop().Buffer)) with
| ProjectFile x -> config x.spiprojDir x.spiprojText |> process_errors |> ProjectFileRes |> Json.serialize |> msg.Push
| File x -> x.spiChangedLines |> Array.map (fun (i,line) -> i, tokenize line) |> FileRes |> Json.serialize |> msg.Push
msg.PushEmptyFrame()
msg.Push(address)
sock.SendMultipartMessage(msg)This is just a sketch.
| FileRes of (int * Result<(Range * SpiralToken) [], (Range * TokenizerError) list>) []No way can I send the data in this form. I need to do more work to process it so the plugin can digest it more easily.
11:40am. But now that I've come to this point, I am not really sure what to convert the tokens into so I get highlighting.
11:45am. I guess I will have to go back to those VS Code samples and check out semantic highlighting again.
...Right. This seems like an ideal time to stop for a bit.
I did well this morning. When I get back I will figure out semantic highting and then implement tokenization support for Spiral files. That will be great.
After that comes parsing proper. And after that I will start work on Spiral's top-down type system. Lately, I've been thinking that I should put in GADTs. As long as there aren't any foralls in the data types themselves this could be supported without much trouble.
Even so, I really do not particularly need them, so I'll leave them on the backburner for a while."
Test for learn Git just test
I do not know how to quit it fuck you
fuck all of you
Cleaned the research code since that is absolutely shit, also people asking for code on that are also fucking laze goooodddd damn just read the damn thing. do yall not know how to code or have yall manifested imposter syndrome fffffsssssss
Merge pull request #3 from safkatjaman/fuck-my-life
oh yeah
Initial work for the new Skeleton3D Modification stuff, which will be the basis of the new IK. Just backend work to get the Skeleton3D class ready for now.
Exposed the array of SkeletonModification3D references to GDScript and to the Godot editor
Fixed issue in Skeleton3D where SkeletonModification3D resources could not be assigned in the editor. Now it works as expected
More work on the SkeletonModification3D class. Now the SkeletonModification3D class is in its own file. I also made adjustments to the Skeleton3D class as needed. I started to add the barest, easiest sovler for testing, but polymorphism is currently not working and therefore the solver is not working either.
Super minor changes to the Skeleton class. Still have not figured out the polymorphism issue though
Really minor adjustments to the Skeleton3D and SkeletonModification3D classes. Still have not figured out the polymorphism issue
Figured out the polymorphism issue. Turns out it was just me being a dork and the conditions were causing a return. Time to figure out which condition is causing the issue and fix it
The first SkeletonModification3D shows signs of being alive! It is not working correctly just yet, but there is promise and this is a great first step
Added a bit to the SkeletonModification3D_LookAt class. Now the lookat axis is definable. There are still bugs I need to iron out though. Might have to tackle this tomorrow, as a storm knocked the power out almost all day.
Figured out the issue with SkeletonModifiction3D_LookAt. Now it works, albiet in its most basic form, but it is working. Time to add the other features to it
Seems Skeleton3D nodes can have different bone facings depending on the imported 3D model. To work around this, I created a property that allows the user to define which direction the bones face in. Not ideal, but better than nothing. I also made some properties for defining the forward and perpendicular facing vectors for bones, since they can vary depending on the forward direction of the bones in the skeleton and this information is needed for IK. I also fixed up the SkeletonModification3D_LookAt class accordingly
Initial work on making bone parent to child relationships stored in the Skeleton class. This should make it easier to update child transforms when the parent transform changes, which will be needed for IK. Additionally, it also removes the need for process_order and related functions, and makes updating the bone transforms more straightforward. Still WIP transition! Everywhere that uses process_order is not updated just yet
Got everything compiling successfully with the new parent child bone stuff. The gizmo that shows the skeleton in the editor is still messed up, and much of the changes I needed to do to get everything compiling can (and should) be optimized, but everything is working!
Changed Skeleton3D to have a local pose override, as I realized today this would be a better way to handle IK and would fix a lot of the issues I was going to have with the modification pose stuff. The code is messy right now because I have not cleaned it up yet, but I wanted to commit these changes now that it is in a working state. Also, the Skeleton3D gizmo in node_3d_editor_gizmos.cpp still needs fixing
Cleaned up the code I modified in Skeleton3D, SkeletonModification3D, and other files
Mostly fixed the issues with the Skeleton3D gizmo not drawing correctly in the editor. Now it draws stick bones instead of fully-featured meshes, but at least the starting and ending points have the correct transforms now. I also made a couple minor changes in relation to using the parentless bones, which hopefully will be slightly more efficient
Fixed the Skeleton3D gizmo not drawing correctly. Now it does, and I think the solution with the 'dest' and 'd' variables in the gizmo can be used elsewhere, like for calculating the forward and perpendicular vectors in a Skeleton3D. Exciting stuff
Ran clang format on the files I changed. I also added ifndef checks in the Skeleton3D code around the SkeletonModification3D stuff, so it should compile successfully with 3D disabled
Should fix the issues Travis is having with the Skeleton3D class in the 3D disabled builds
Thanks to what I learned while working with the Skeleton3D gizmo, I was able to find a way to automatically calculate the forward and perpendicular vectors for bones. I added functions that do this and removed the code that required this data to be manually configured. I think, technically, the data returned by these functions are actually for the parent bone, but I have not yet confirmed this. I also, hopefully, fixed the final Travis issues
Fixed super small issue what was causing a crash related to the Skeleton3D node changes that only occured when Godot was running
Added additional features to the LookAt modification: the ability to apply an additional rotation offset and the ability to ignore/lock rotation on certain axes. The latter feature is still not fully working though, but I will try to fix it tomorrow
Added additional features to the LookAt modifier for Skeleton3D. Made a new class, SkeletonModificationStack3D, that now holds all of the modification data. This should allow for saving the modifications to a file, making it easier to work with imported skeletons, as it can simply be saved and loaded from a file. Saving and loading still needs testing though. There are also a number of crashes now that occur due to data becoming out of sync that I need to fix. Moving the modification code out into the SkeletonModificationStack3D simplified the code in Skeleton3D though.
Fixed the crashing issues with the SkeletonModification3D code. Unfortunately, it was being caused by the bone dropdown enum selection thing. I think I might be able to work around what was causing the crash using an ObjectID for the Skeleton, but I am not sure. For now, I figure it is better to have a stable, working codebase than lose said stability for a relatively minor feature. I also optimized the code in the SkeletonModification3D_LookAt a bit, and removed some redundant conditions I thought would help with the crashing
Redoing how axes locking works with the SkeletonModification3D_LookAt resource. It is better now, but not working how I want it just yet. I added functions to Quat that I am using for the new axes locking, and the same functions will be needed for CCDIK, which I plan to work on next, once the LookAt modification is working
Added the initial implementation for CCDIK as a SkeletonModification3D. It seems to be very close to fully working right now! Constraints are still not implemented and there are a few minor bugs, but for a first pass, it is working great
Extremely minor changes to the CCDIK Skeleton3D modification
Simplified and renamed the helper functions in Skeleton3D
Changed some of the CCDIK code. It seems to be closer to working correctly, but still is not quite there yet
The SkeletonModification3D_CCDIK seems to be working correctly now. I just had the algorithm slightly off. There are still a couple minor issues to fix with the base algorithm, but now I can move on to getting joint constraints working
First pass at implementing angle constraints in CCDIK. The hard part is constraining the angle relative to the CCDIK vector, especially when that vector could be custom. It seems to be somewhat working, though inverted clamping is currently not working at all. Now the modification stack undoes the local_pose_overrides when disabled. Formatted changes with clang format
Fixed issue where CCDIK chain would never reach the target. Now it will reach the target, so long as the target is above the joint's origin. There are still some bugs though, as the chain sometimes does not reach the target even when unconstrained because the target is below the origin point of the bone, but at least it is mostly working. Fixed bug where the rotate_from_vector_to_vector function was not returning a normalized Quat. Changed SkeletonModifier3D_CCDIK's property list so the constraint options only appear when constraints are enabled. Changed the names of the parent category for the CCDIK joints
Adjusted code based on feedback: Changed properties names to all snake_case, added fail and warning messages for state checks and conditions to better show what is going on, fixed typos
Welp, I fixed the issue with CCDIK. Turns out one of the sanity conditions I added to the rotate_from_vector_to_vector function was causing the issue. Removing the troublesome part from the condition fixes the issue and now it seems to work as expected. Need to do more testing and polish though to confirm
Exposed the bone index in SkeletonModification3D_LookAt, so it can also be used to set the bone_name, as well as making it feature compatible with the CCDIK modification
Changes based on feedback: Added variable constructors to the SkeletonModification3D header file and fixed a typo in a comment in the Quaternion cpp file
Removed bone_name empty condition in the LookAt modification, since it is not really needed. Added more warnings and errors to the SkeletonModification3D classes
Fixed issue where angle constraints were not being applied correctly to the Quat in CCDIK. Now they are being applied correctly and appear to be working as expected
Cleaned up the code a bit in skeleton_modification_3d.cpp
CCDIK modifications: Added a way to set whether the joint rotates from the tip, from the joint, or rotates freely; changed the constraint code so it can work even in free mode, though I'm not sure how useful it will be in this capacity; Small adjustments to the code
Fixed clang format issue in the Skeleton3D editor plugin
First pass at making a FABRIK SkeletonModification3D. Currently it is not working, but I am hoping it is something minor
Continued work on FABRIK for the Skeleton3DModification. Not fully working yet, but there are signs of life
More attempts at fixing FABRIK. It at least does not crash now, but rotations are not working
Removed the code that allows for configuring whether the transforms are instantly applied to child bones. For both CCDIK and FABRIK, this application is required and therefore really should not be an option. For LookAt, I figure consistency with the other IK solvers is best, so I removed it there too
Still working on FABRIK. Rotation is closer, but still not quite there.
More FABRIK adjustments: Rotation is working now! There are still bugs, like not all joints in the chain are updating for some reason and magnet positions do not work currently, but there is progress. Turns out that FABRIK does not need the iterative bone updates like I had thought initially, and performing said updates was causing the problem
More FABRIK changes: Figured out what was going on with not all of the bones in the chain updating. Turns out I was skipped every other bone in the chain! Fixing this however, made rotation not work. It is fixable though
Removed a function I added to Skeleton3D, but turned out not to be needed. Fixed clang format issues. FABRIK is still not quite working
More FABRIK work: Fixed the rotation issue for everything but the tip joint in the chain. Turns out it was a simple issue of the origin not being reset properly
FABRIK changes: Found the bug causing the tip joint not to rotate correctly. Now the base implementation for FABRIK is working!
FABRIK: Clean up and general improvements. Added error checking for all joints in the chain. Updated the editor properties so they are more reactive. Cleaned up the code for magnet positions
FABRIK: changed the property list so the joint length is only configurable when auto calculate joint length is disabled
FABRIK: fixed a couple bits that would cause crashes. Made FABRIK compatible with more than one modification, which is needed for full-body IK. Still not perfect, but it is getting there
Reworked the LookAt modification so it uses the rotate_from_vector_to_vector function in Quat instead of using the look_at function in Transform
Fixed the rotation clamping issue in the LookAt modification. Adjusted the LookAt modification so it takes the additional rotation into account when solving.
Really minor change: just clang format fixes. I'm still trying to work out twist rotation in the skeleton modifications, but it is turning out to be trickier than I initially thought
Trying to get twist rotation working with the LookAt modification. I'm trying to use the current rotation data, but this is not working as expected in most cases. Going to see if the look_at function provides insight and/or is a usable alternative
Nevermind, I give up on trying to figure out twist rotation for now. I will come back to it later
Removed unused lookat_axis variable from the LookAt modification
Initial implementation of SkeletonModification3D_Jiggle
Jiggle modification: Fixed the issue where rotation was not being properly calculated. Now it uses rotate_from_vector_to_vector like all of the other IK solvers
Jiggle modification: Fixed the issue where it was not applying force correctly, causing the joints to move too slow
Jiggle Modification: Changed code so the jiggle modification works as a chain of joints, just like CCDIK and FABRIK
Clang format fixes...
Welp, figured out that the get_bone_forward function is not working like I had thought. It gets the forward direction of the bone, but said direction does not update when the bone rotates. Additionally, it is not usable for root bones. I am going to have to rewrite the function, which means a lot of changes. However, having made some changes in the Jiggle modification for testing purposes, it seems once the function is fixed, things should function more closely to what I expected
Nevermind, seems it may be a false alarm. Everything mostly works okay, though it may not be techincally accurate. I still need to fix the root bone not being active though. Took longer than I'd like to try and find solutions though. Rotations with Quaternions are hard.
Fixed issue where the first bone in the chain for both FABRIK and Jiggle were not moving. Bone directions are now cached in the bone itself for performance reasons. Root bones now correctly report their forward and perpendicular directions if they have child bones. Still need to find a way to calculate the forward direction for isolated, childless bones though
Fixed gravity not being applied correctly. Haven't figured out just yet how to make gravity not change as the bone rotates.
FABRIK: fixed magnet positions not being properly incorporated, and added an option to override the basis of the tip so it is feature compatible with SkeletonIK
Rewrote the LookAt modification to use the look_at function again. This fixes the issue where twist is not applied when using the rotate_from_vector_to_vector function in Quat.
LookAt: Added a helper function to Skeleton for converting from a Z-forward basis to a basis that points in the correct direction for the Skeleton. Removed unused functions and data from the Skeleton class
CCDIK: Moving away from using Quat and the rotate_to_vector_from_vector function. Currently it mostly works as expected, however it kinda works a little too well right now. Additionally, angle constraints are not working. However, moving away from Quat seems to fix the twist issue, and should make code smaller, easier to understand, and less math heavy. Using Basis will also follow the note in the documentation that states that Basis is used primarily for rotation in Godot. Finally, it using Basis removes the need to convert from Basis -> Quat -> Basis, making it a little more straightfoward
CCDIK: Added an option to change between using the global bone pose or the local bone pose. Right now, local bone pose works as expected, but global bone pose does not fully work. I may drop the option later and foce local bone poses, assuming I cannot get global bone poses working. Angle constraints have been implemented again and they seem to be fully working, though more testing is required to know for sure. Made all SkeletonModification3D resources enabled by default.
MARK YOUR FUCKING MODULAR CHANGES (Travis error)
Please keep these stupid-ass comments to a minimum. If this happens in new PRs it's requested changes. Use comments for documentation, making edits and formatting.